Redis集群

目录

一, 集群及分片算法

1.1 什么是集群

1.2 数据分片算法

1. 哈希求余

 2. 一致性哈希算

3. 哈希槽分区算法(Redis使用)

二, 集群的故障处理

2.1 故障判定

2.2 故障迁移

三, 集群扩容

四, 集群缩容

---

一, 集群及分片算法

1.1 什么是集群

我们在Redis哨兵中学习了,哨兵+主从复制是为了提高系统的可用性,当主节点发生宕机了,可以自动进行恢复,但是并不能解决"数据极端情况下丢失"的问题,不能提高数据的存储容量,当我们存储的数据接近或者超过机器的无礼内存,这样的结构就难以胜任了,所以引入了集群的概念.

Redis集群就是在上述的思路之下,引入多组Master/Slave,每一组Master/Slave存储数据全集的一部分,从而构成一个更大的整体,称为Redis集群.

假如整个数据全集是1TB,引入三组Master/Slave来存储,那么每一组机器只需要存储整个数据全集的1/3即可.

在上述图中:

• Master1 和 Slave11 和 Slave12  保存的数据是同样的数据,占总数据的1/3
• Master2 和 Slave21 和 Slave22  保存的数据是同样的数据,占总数据的1/3
• Master3 和 Slave31 和 Slave32  保存的数据是同样的数据,占总数据的1/3

这三组机器存储的数据是不同的;每个Slave都是对应Master的备份(当Master挂了,对应的Slave会补位成Master),每个红框部分都可以称为是一个分片(Sharding),如果数量进一步增加,只要增加更多的分片,即可解决.

1.2 数据分片算法

Redis集群的核心思路是用多组机器来存数据的每个部分,那么接下来的核心问题就是,给定一个数据(一个具体的key),那么这个数据应该存储在哪个分片上?读取的时候又应该去哪个分片读取?围绕这个问题,业界有三种比较主流的实现方式.

1. 哈希求余

设有N个分片,使用[0,N-1]这样序号进行编号

针对某个给定的key,先计算hash值,再把得到的结果%N,得到的结果即为分片编号.

例如,N为3.给定key为hello,对hello计算hash值(比如使用md5算法),得到的结果为"bc4b2a76b9719d91",再把这个结果%3,结果为0,那么就把hello这个key放到0号分片上;实际工作涉及到的系统,计算hash的方式不一定是md5,但是思想是一致的.

后续如果要取某个key的记录,也是针对key计算hash,再对N求余,就可以找到对应的分片编号了.

优点:简单高效,数据分配均匀

缺点:一旦需要进行扩容,N就改变了,原有的映射规则被破坏,就需要让节点之间的数据相互传输,重新排列以满足昕的映射规则,此时需要搬运的数据量是比较多的,开销较大

N为3的时候,[100,120]这21个hash值的分布(此处假定计算出的hash值是一个简单的整数,方便肉眼观察),当引入一个新的分片,N从3->4时,大量的key都需要重新映射(某个key%3和%4的结果不一样,就映射到不同机器上了)

如上图可以看出,整个扩容一共21个key,只有3个key没有经过搬运,其他的key都是搬过的.

 2. 一致性哈希算

为了降低上述的搬运开销,能够更高效扩容,业界提出了"一致性哈希算法",key映射到分片序号的过程不再是简单求余了,而是改成以下过程:

第一步,把 0->2^32-1 这个数据空间,映射到一个圆环上,数据按照顺时针方向增长

第二步,假设当前存在三个分片,就把分片放到圆环的某个位置上

第三步,假定有一个key,计算得到hash值H,那么这个key映射到哪个分片上呢?规则很简单,就是从H所在位置,顺时针往下找,找到的第一个分片,即为该key所从属的分片 

这就相当于,N个分片的位置,把整个圆环分成了N个管辖区间,key的hash值落在某个区间内,就归对应区间管理.

在这个情况下,如果扩容一个分片,如何处理呢?

原有分片在环上位置不动,只要在环上新安排一个分片位置即可.

此时只需要把0号分片上的部分数据,搬运给3号分片即可,1号分片和2号分片管理的区间都是不变的 

优点:大大降低了扩容时对数据搬运的规模,提高了扩容操作的效率

缺点:数据分配不均匀(有的多有的少,数据倾斜)

3. 哈希槽分区算法(Redis使用)

为了解决上述问题(搬运成本高和数据分配不均匀),Redis集群引入了哈希槽(hash slots)算法

hash_slot = crc16(key) % 16384

其中crc16也是一种hash算法,通过key计算出对应的key

16384 = 16 * 1024 也就是2^14

相当于把整个哈希值,映射到16384个槽位上,也就是[0,16383],然后再把这些槽位比较均匀的分配给每一个分片,每个分片的节点都需要记录自己持有哪些分片;

假设当前有三个分片,一种可能的分配方式:

• 0号分片:[0,5461] 共5642个槽位
• 1号分片:[5642,10923] 共5642个槽位
• 2号分片:[10924,16383] 共5640个槽位

这里的分片规则是很灵活的,每个分片持有的槽位也不一定连续,每个分片的节点使用位图来表示自己持有哪些槽位,对于16384个槽位来说,需要2048个字节(2KB)大小的内存空间表示.

如果需要进行扩容,比如新增一个3号分片,就可以针对原有的槽位进行重新分配,比如可以把之前每个分片持有的槽位,各拿出一点,分给新分片,一种可能的分配方式:

• 0号分片:[0,4095] 共4096个槽位
• 1号分片:[5642,9557] 共4096个槽位
• 2号分片:[10924,15019] 共4096个槽位
• 3号分片:[4096,5461] + [9558,10923] + [15019,16383] 共4096个槽位

我们实际使用Redis集群分片的时候,不需要手动指定哪些槽位分配给某个分片,只需要告诉某个分片应该持有多少个槽位即可,Redis会自动完成后续的槽位分配,以及对应的key搬运的工作.

哈希槽分区算法的相关面试问题:

问题一:Redis集群是最多有16384个分片吗?

• 并非如此,如果一个分片只有一个槽位,这对于集群的数据均匀其实是难以保证的,实际上Redis作者建议集群分片数不应该超过1000.

问题二:为什么是16384个槽位?

• 节点之间通过⼼跳包通信.,⼼跳包中包含了该节点持有哪些 slots.,这个是使⽤位图这样的数据结构表⽰的.;表⽰ 16384 (16k) 个 slots,需要的位图⼤⼩是 2KB,如果给定的 slots 数更多了,⽐如 65536 个了,此时就需要消耗更多的空间,8 KB 位图表⽰了,8 KB,对于内存来说不算什么,但是在频繁的⽹络⼼跳包中,还是⼀个不⼩的开销;
• 另⼀⽅⾯,Redis 集群⼀般不建议超过 1000 个分⽚,所以 16k 对于最⼤ 1000 个分⽚来说是⾜够⽤的,同时也会使对应的槽位配置位图体积不⾄于很⼤.

二, 集群的故障处理

2.1 故障判定

集群中的所有节点,都会周期性的使用心跳包进行通信

1. 节点 A 给 节点 B 发送 ping 包, B 就会给 A 返回⼀个 pong 包. ping 和 pong 除了 message type属性之外, 其他部分都是⼀样的. 这⾥包含了集群的配置信息(该节点的id, 该节点从属于哪个分⽚,是主节点还是从节点, 从属于谁, 持有哪些 slots 的位图...).
2. 每个节点, 每秒钟, 都会给⼀些随机的节点发起 ping 包, ⽽不是全发⼀遍. 这样设定是为了避免在节点很多的时候, ⼼跳包也⾮常多(⽐如有 9 个节点, 如果全发, 就是 9 * 8 有 72 组⼼跳了, ⽽且这是按照 N^2 这样的级别增⻓的).
3. 当节点 A 给节点 B 发起 ping 包, B 不能如期回应的时候, 此时 A 就会尝试重置和 B 的 tcp 连接, 看能否连接成功. 如果仍然连接失败, A 就会把 B 设为 PFAIL 状态(相当于主观下线).
4. A 判定 B 为 PFAIL 之后, 会通过 redis 内置的 Gossip 协议, 和其他节点进⾏沟通, 向其他节点确认 B的状态. (每个节点都会维护⼀个⾃⼰的 "下线列表", 由于视⻆不同, 每个节点的下线列表也不⼀定相同). ​​​​​​
5. 此时 A 发现其他很多节点, 也认为 B 为 PFAIL, 并且数⽬超过总集群个数的⼀半, 那么 A 就会把 B 标记成 FAIL (相当于客观下线), 并且把这个消息同步给其他节点(其他节点收到之后, 也会把 B 标记成FAIL).

至此,B就彻底被判定为故障节点了.

某个或者某些节点宕机,有的时候会引起整个集群都宕机(称为fail状态),以下情况会出现集群宕机:

• 某个分片,所有主节点和从节点都挂了
• 某个分片上,主节点挂了,但是没有从节点
• 超过半数的master节点都挂了

2.2 故障迁移

上述例子中,B故障,并且A把B FAIL 的消息告知集群中的其他节点

• 如果B是从节点,那么不需要进行故障迁移
• 如果B是主节点,那么就会由B 的从节点(比如C和D)出发故障迁移了

所谓故障迁移,就是指把从节点提拔成主节点,继续给整个Redis集群提供支持,具体流程如下:

1. 从节点判定⾃⼰是否具有参选资格. 如果从节点和主节点已经太久没通信(此时认为从节点的数据和主节点差异太⼤了), 时间超过阈值, 就失去竞选资格
2. 具有资格的节点, ⽐如 C 和 D, 就会先休眠⼀定时间. 休眠时间 = 500ms 基础时间 + [0, 500ms] 随机时间 + 排名 * 1000ms. offset 的值越⼤, 则排名越靠前(越⼩)​​​​​​
3. ⽐如 C 的休眠时间到了, C 就会给其他所有集群中的节点, 进⾏拉票操作. 但是只有主节点才有投票资格
4. 主节点就会把⾃⼰的票投给 C (每个主节点只有 1 票). 当 C 收到的票数超过主节点数⽬的⼀半, C 就会晋升成主节点. (C ⾃⼰负责执⾏ slaveof no one, 并且让 D 执⾏ slaveof C)​​​​​​​
5. 同时, C 还会把⾃⼰成为主节点的消息, 同步给其他集群的节点. ⼤家也都会更新⾃⼰保存的集群结构信息

上述选举的过程,称为Raft算法,是一种在分布式系统中广泛使用的算法,在随机休眠时间的加持下,基本上就是谁先唤醒谁谁就能竞选成功.

三, 集群扩容

扩容是一个在开发中比较常遇到的场景,随着业务的发展,现有集群很可能无法容日益增长的数据,此时给集群中加入更多新的机器,就可以使存储空间更大了.

第一步:把新的主节点加入到集群

第二步:重现分配slots

在搬运key的过程中,对于那些不需要搬运的key,访问的时候是没有任何问题的,但是对于需要搬运的key,进行访问可能会出现短暂的访问错误(key的位置发生了变化),随着搬运完成,这样的错误自然就恢复了

第三步:给新的主节点添加从节点

光有主节点了,此时扩容的目标已经初步达成,但是为了保证集群可用性,还需要给这个新的主节点添加从节点,保证该主节点宕机之后,有从节点能够顶上

四, 集群缩容

扩容是比较常见的,但是缩容其实非常少见,此处简单说一下缩容的流程:

第一步:删除从节点

第二步:重新分配slots

第三步:删除主节点