Redis切片集群

Posted 2021-05-16 爱若信若盼若

Redis切片集群

当Redis实例保存的键值对数量过大时，使用一次RDB进行持久化时，Redis会fork子进程来完成该操作，fork操作的时间开销与实例数据量大小呈正相关关系，fork操作会阻塞主进程。数据量越大，fork操作造成的主线程阻塞时间越长，Redis相应因此变慢

考虑更为合理的方案解决Redis存储大容量数据

切片集群，也称分片集群，启动多个Redis实例组成一个集群，将受到的数据划分成多份，每一份都用一个实例存储

数据切片何实例的对应分布关系

Redis Cluster方案采用哈希槽（Hash Slot）来处理数据和实例之间的映射关系。

Redis Cluster中，一个切片集群共有16384（2048*8）个哈希槽，每个键值都会根据它的key，被映射到一个哈希槽中

映射过程：根据键值对的key，按照CRC16算法计算一个16bit的值，该值对16384取模，得到16384范围内的模数，该模数对应哈希槽的编号

哈希槽映射到具体的Redis实例上

• 部署Redis Cluster方案时，使用cluster create命令创造集群，Redis自动把这些槽平均分布在集群实例上。
  
• cluster meet命令手动建立实例间的连接，使用cluster addslot命令，指定每个实例上的哈希槽个数

redis-cli -h 172.16.19.3 –p 6379 cluster addslots 0,1
redis-cli -h 172.16.19.4 –p 6379 cluster addslots 2,3
redis-cli -h 172.16.19.5 –p 6379 cluster addslots 4
// 与上图分配结果相同

注意点

• Redis集群中不同实例的内存大小配置不一，此时如果采用均分哈希槽的方法，内存小的实例会有更大的容量压力。应当根据不同实例的资源配置情况，使用cluster addslots命令手动分配哈希槽
• 手动分配哈希槽时，需要把16384个槽都分配完，否则Redis集群无法正常工作

客户端定位数据

Redis实例将自己的哈希槽信息发给和它相连的其他实例，完成哈希槽配置信息的扩散。当完成实例之间相互连接后，每个实例都有所有哈希槽的映射关系。

这样能保证客户端在访问任意一个实例时，获取所有的哈希槽信息

客户端收到哈希槽信息时，会把哈希槽信息缓存在本地。

实例和哈希槽的对应关系并不是恒定不变的，

• 集群中，实例有新增或删除，Redis需要重新分配哈希槽
• 为了负载均衡，Redis需要把哈希槽在所有实例上重新分布一遍

实例之间关系发生变化时，客户端时无法主动获取这些变化信息

Redis Cluster方案提供了一种重定向机制

客户端给一个实例发送数据读写操作时，若实例上并没有该键值对映射的哈希槽，实例会返回MOVED命令返回结果，该结果包含了新实例的访问地址

GET hello:key
(error) MOVED 13320 172.16.19.5:6379
// MOVED命令表示，客戶端请求的键值对所在的哈希槽13320，实际是在172.16.19.5这个实例上

客户端通过返回的MOVED命令，直接和新实例连接，发送操作请求，并更新本地缓存，将新实例和对应的slot映射关系更新

为什么不使用表将键值对和实例的对应关系记录下来？

考虑修改表的开销，键值对和实例对应关系发生变化需要修改表时，单线程操作表，所有操作都需要串行执行，性能慢；多线程操作表，涉及额外加锁开销

数据量较大时，需要额外存储空间增加

基于哈希槽计算的情况下，虽然需要增加记录哈希槽与实例映射关系的开销，但哈希槽数量较少（比键值对少）且有上限，因此开销较小