一、集群模式概述
Redis 中哨兵模式虽然提高了系统的可用性,但是真正存储数据的还是主节点和从节点,并且每个节点都存储了全量的数据,此时,如果数据量过大,接近或超出了 主节点 / 从节点机器的物理内存,就会出现严重的问题;
集群模式就是为了解决这个问题的,它通过引入更多的主节点和从节点,每一组主节点及其所对应的从节点存储了数据全集的一部分,多组这个的结构构成了一个更大的整体,这就是集群;
如下图所示,假定引入了三组主从节点来存储全量数据,那么每组机器只需要存储全集的 1/3 即可,其中每组机器中的每个节点保存的数据内容是一样的,这样的一组机器(包含一个主节点和多个从节点)也称为一个分片;
此时,如果全量数据继续增加,就只需引入更多的分片即可;
二、数据分片算法
1. 哈希求余
设有 N 个分片,使用 [0,N-1] 来编号;
哈希求余就是针对给定的 key,先根据一个 hash 函数计算出 hash 值(例如使用 MD5 算法计算 hash 值),再把得到的结果进行 % N,得到的结果就是其所对应的分片编号;
优点:简单高效,数据分配均匀;
缺点:一旦需要进行扩容,N 就会改变,导致原有的映射规则被破坏(hash(key) % N),就需要让节点之间的数据相互传输,重新排列,以满足新的映射规则,此时需要搬运的数据量非常多,开销很大;
2. 一致性哈希算法
首先,把 [0,2^32-1] 这个数据空间,映射到一个圆环上,数据按照顺时针方向增长;
假设存在三个分片,如下图所示
假设有一个 key,通过 hash 函数计算得到 hash 值 H,那么这个 key 对应的分片就是从 H 所在位置,顺时针往下找,找到的第一个分片;
这就相当于,N 个分片的位置,把整个圆环分成了 N 个区间,key 的 hash 值落在某个区间内,就归对应区间管理;
当需要扩容时,原有分片在环上的位置不动,只需要在环上新安排一个分片位置即可;
优点:大大降低了扩容时数据搬运的规模,提高了扩容操作的效率;
缺点:数据分配不均匀(有的分片数据多,有的少,数据倾斜);
3. 哈希槽分区算法(Redis 采用)
为了解决上述搬运成本高 和 数据分配不均匀的问题,Redis cluster 引入了哈希槽 (hash slots) 算法;
hash_slot = crc16(key) % 16384
16384 = 16 * 1024 = 2 ^ 14,这就相当于把整个 hash 值,映射到 16384 个槽位上,即[0,16383]然后再把这些槽位比较均匀的分配给每个分片,同时每个分片的节点都要记录自己持有哪些分片;
比如有三个分片,则槽位的分配方式可能为:
- 0 号分片:[0,5461],共 5462 个槽位
- 1 号分片:[5462,10923],共 5462 个槽位
- 2 号分片:[10924,16383],共 5460 个槽位
每个分片的节点使用 位图来表示自己持有哪些槽位,对于 16384 个槽位来说,需要 2048 个字节即 2 KB 大小的内存空间来表示;
当需要进行扩容时,比如新加一个 3 号分片,就可以针对原有的槽位进行重新分配,分配的结果可能为:
- 0 号分片:[0,4095],共 4096 个槽位
- 1 号分片:[5462,9557],共 4096 个槽位
- 2 号分片:[10924,15019],共 4096 个槽位
- 3 号分片:[4096,5461],[9558,10923],[15020,16383],共 4096 个槽位
在实际使用 Redis 集群分片的时候,不需要手动指定哪些槽位分配给某个分片,只需要告诉某个分片应该持有多少个槽位即可,Redis 会自动完成后续的槽位分配,以及对应的 key 搬运的工作;
为什么是 16384 个槽位呢?
Redis 官方的解释是:节点之间通过心跳包通信,心跳包中包含了该节点持有哪些 slots,这个是使用位图这样的数据结构表示的,表示 16384 (16k) 个 slots,需要的位图大小是 2KB,如果给定的 slots 数更多了,比如 65536 个了,此时就需要消耗更多的空间,8 KB 位图表示了,8 KB,对于内存来说不算什么,但是在频繁的网络心跳包中,还是⼀个不小的开销的;
另一方面,Redis 集群一般不建议超过 1000 个分片,所以 16k 对于最大 1000 个分片来说是足够用的,同时也会使对应的槽位配置位图体积不至于很大;
三、集群故障处理
1. 故障判定
集群中的所有节点,都会周期性的使用心跳包进行通信;
- 当节点 A 给节点 B 发送 ping 包,B 就会给 A 返回一个 pang 包;每个节点,每秒钟,都会给一些随机的节点发起 ping 包,这样设定是为了避免在节点很多的时候,心跳包也非常多;
- 若节点 A 给节点 B 发起 ping 包,B 不能如期回应时,此时 A 就会尝试重置和 B 的 tcp 连接,看能否连接成功,如果仍然连接失败,A 就会把 B 设为 PFAIL 状态(相当于主观下线);
- 当A 判定 B 为 PFAIL 之后,会通过 redis 内置的 Gossip 协议,和其他节点进行沟通,向其他节点确认 B 的状态,(每个节点都会维护一个自己的 "下线列表",由于视角不同,每个节点的下线列表也不⼀定相同);
- 此时 A 发现其他很多节点,也认为 B 为 PFAIL,并且数目超过总集群个数的一半,那么 A 就会把 B 标记成 FAIL (相当于客观下线),并且把这个消息同步给其他节点 (其他节点收到之后,也会把 B 标记成 FAIL)
至此 B 就被彻底判定为故障节点了;
若某部分节点宕机,有可能会引起整个集群宕机 (整个集群处于 fail 状态),主要有以下三种情况:
- 某个分片上的主节点和所有从节点都挂了
- 某个分片上的主节点挂了,并且没有从节点(可归纳为第一种)
- 超过半数的主节点挂了(此时就无法完成投票选举主节点的工作了)
2. 故障迁移
在上述故障判定中,若 B 是从节点,则不需要进行故障迁移,若 B 是主节点,并假设 B 有两个从节点 C 和 D,此时就会由 从节点 C D 触发故障迁移(把从节点提拔为主节点);
故障迁移的具体步骤为:
- 从节点判定自己是否具有参选资格: 如果从节点和主节点已经太久没通信(此时认为从节点的数据和主节点差异太大了), 时间超过阈值, 就失去竞选资格;
- 具有资格的节点,比如 C 和 D,会先休眠一定时间,休眠时间 = 500ms 基础时间 + [0, 500ms] 随机时间 + 排名 * 1000ms,offset 的值越大,则排名会越靠前(越小);
- 比如 C 的休眠时间到了,C 就会给其他所有集群中的节点,进行拉票操作,但是只有主节点才有投票资格;
- 主节点就会把自己的票投给 C (每个主节点只有 1 票); 当 C 收到的票数超过主节点数目的一半, C 就会晋升成主节点; (C 自己负责执行 slaveof no one, 并且让 D 执行 slaveof C);
- 同时,C 还会把自己成为主节点的消息,同步给其他集群的节点;大家也都会更新自己保存的集群结构信息;
四、集群扩容
-
把新的主节点加入到集群
redis-cli --cluster add-node (新的主节点的ip地址和端口号) (集群中任意节点的ip地址和端口号)
-
重新分配 slots
redis-cli --cluster reshard (集群中任意节点的ip地址和端口号)
-
给新的主节点添加从节点
redis-cli --cluster add-node (新的从节点的ip地址和端口号) (集群中任意节点的ip地址和端口号) --cluster-slave --cluster-master-id (新的主节点的 nodeId)