Redis集群详细介绍2

一、是否使用过Redis集群，集群的原理是什么 ？

Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务

哨兵解决了高可用的问题，而 Redis Cluster集群就是终极方案，一举解决高可用和分布式问题

数据分区： 是集群最核心的功能。集群将数据分散到多个节点，一方面 突破了Redis 单机内存大小的限制，

存储容量大大增加；另一方面 每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力

高可用： 集群支持主从复制和主节点的 自动故障转移 （与哨兵类似），当任一节点发生故障时，集群仍然可以对外提供服务

二、集群中数据如何分区 ？

分布式的存储中，要把数据集按照分区规则映射到多个节点，常见的数据分区规则三种：

方案一：节点取余分区

节点取余分区，非常好理解，使用特定的数据，比如Redis的键，或者用户ID之类，对响应的hash值取余：hash（key）%N，来确定数据映射到哪一个节点上

不过该方案最大的问题是，当节点数量变化时，如扩容或收缩节点，数据节点映射关 系需要重新计算，会导致数据的重新迁移

方案二：一致性哈希分区

将整个 Hash值空间组织成一个虚拟的圆环，然后将缓存节点的 IP 地址或者主机名做 Hash取值后，放置在这个圆环上。

当我们需要确定某一个 Key 需 要存取到哪个节点上的时候，先对这个 Key 做同样的 Hash 取值，确定在环上的位置，

然后按照顺时针方向在环上“行走”，遇到的第一个缓存节点就是要访问的节点

比如说下面 这张图里面，Key 1 和 Key 2会落入到 Node 1中，Key 3、Key 4会落入到 Node 2中，Key 5落入到 Node 3 中，Key 6 落入到 Node 4 中

这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中 相邻的节点，对其他节点无影响

但它还是存在问题：

• 缓存节点在圆环上分布不平均，会造成部分缓存节点的压力较大

• 当某个节点故障时，这个节点所要承担的所有访问都会被顺移到另一个节点上，会对后面这个节点造成力

方案三：虚拟槽分区

这个方案 一致性哈希分区的基础上，引入了虚拟节点 的概念。Redis 集群使用的便是该方案，其中的虚拟节点称为槽（slot）。

槽是介于数据和实际节点之间的虚拟概念，每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据

在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点 之间的关系，增加或删除节点对系统的影响很小

仍以上图为例，系统中有4个实际节点，假设为其分配 16 个槽（0-15）；

• 槽 0-3 位于 node1；4-7 位于 node2；以此类推....

如果此时删除 node2，只需要将槽 4-7 重新分配即可，例如槽 4-5 分配给 node1，槽 6 分配给 node3，槽 7 分配给 node4，数据在其他节点的分布仍然较为均衡

三、能说说Redis集群的原理 ?

Redis集群通过数据分区来实现数据的分布式存储，通过自动故障转移实现高可用

集群创建

数据分区是在集群创建的时候完成的

设置节点

Redis集群一般由多个节点组成，节点数量至少为6个才能保证组成完整高可用的集群。每个节点需要开启配置 cluster-enabled yes，让Redis运行在集群模式下

节点握手

节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信， 达到感知对方的过程。节点握手是集群彼此通信的第一步，

由客户端发起命令：cluster meet{ip}{port}。完成节点握手之后，一个个的Redis节点就组成了一个多节点的集群

分配槽（slot）

Redis集群把所有的数据映射到16384个槽中。每个节点对应若干个槽，只有当节点分配了槽，才能响应和这些槽关联的键命令。通过 cluster addslots命令为节点分配槽

四、故障发现

Redis集群内节点通过 ping/pong 消息实现节点通信，集群中每个节点都会定期向其他节点发送 ping 消息，接收节点回复 pong 消息作为响应。

如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线（pfail）状态

当某个节点判断另一个节点主观下线后，会将这个主观下线的节点状态在集群内传播。通过Gossip消息传播，集群内其它节点不断收集该故障节点的下线报告。

当超半数以上持有槽的主节点都标记该故障节点是主观下线时。触发客观下线流程

五、故障恢复

故障节点变为客观下线后，如果下线节点是持有槽的主节点则需要在它 的从节点中选出一个替换它，从而保证集群的高可用

选举过程

第一步、检查该客观下线的故障节点其下的从节点是否有竞选为主节点的资格

• 数据同步：主从数据同步，低延迟的从节点

• 优先级：优先级高的从节点

• 运行状态：从节点必须处于正常运行状态

第二步、发起选举

• 符合条件的从节点会发起选举，并向其它持有哈希槽的主节点发送故障选举请求

• 请求中包含从节点的配置纪元（configEpoch），这是一个递增的计数器，用于保证选举的顺序性

• 配置纪元（configEpoch）：一个纪元代表一轮投票选举，进入下一轮投票时纪元会加 1

第三步、投票过程

• 其它主节点收到请求后，会检测发起选举的从节点与持有哈希槽的主节点是否在同一版本的纪元【所谓的纪元是指是否在同一个选举版本内，同一个纪元主节点只能投一票】内且是否已经投票给其它从节点

• 如果没有且请求合理，主节点会投票支持该从节点

• 从节点收集投票，如果获得超过半数主节点的支持，则选举成功

第四步、从节点晋升为主节点，替换已客观下线的主节点

• 赢得选举的从节点执行：

• 更新集群状态，广播 pong 消息通知其它主节点

• 其它从节点开始复制新主节点