redis系列6——Cluster模式

        Redis3.0版本增加Redis Cluster，Redis Cluster解决了Redis分布式方面的需求。如果遇到并发、流量瓶颈时，用Redis Cluster模式实现负载均衡。

一、数据分区原理

        分布式数据库要解决整个数据集按照分区规则映射到多个节点，让每个节点负责整体数据的一部分数据。分布式数据库redis的数据分区规则常用的是哈希分区、顺序分区。哈希分区离散度好、数据分布与业务无关、无法顺序访问。顺序分区离散度不好、数据分布与业务相关、支持顺序访问。

1.哈希分区规则

（1）节点取余分区：hash（key）%N(结点数量)计算哈希值。使用简单，但是可能分配不均匀。

（2）一致性hash分区：每个节点分配token，构成一个hash环，根据key计算hash，顺时针找到第一个大于等于hash值的token节点。增加和删除只影响临近节点对其他节点无影响。加减节点会造成部分数据无法命中，需要手动处理数据。

（3）虚拟槽分区：使用离散度好的哈希函数把所有数据映射到一个固定的整数集合中，定义为槽。为了方便数据拆分和集群扩展，每个节点会负责一定数量的槽。

二、Redis Cluster实现原理

1.Cluster分区规则

        Redis Cluser采用虚拟槽分区，所有的键根据哈希函数映射到0~16383整数槽内，计算公式为slot=CRC16（key）&16383。每一个节点负责维护一部 分槽以及槽所映射的键值数据。

比如5个结点，每个槽负责大约3276个槽的数据。槽与节点关系图：

通过CRC16（key）&16383把key映射到槽上：

特点：

• 解耦数据和节点之前的关系，简化扩容和缩容。
• 节点自己维护槽的对应关系。
• 支持节点、槽、键之间的映射查询。

redis集群限制：

• key批量操作，mget，mset，必须是一个槽操作。
• 事务，多key在一个结点的事务，多个节点不支持。
• key是数据分区最小粒度，hash结构数据量大也在一个结点。
• 复制结构只支持一层，不支持嵌套。

2.节点通信

        Redis集群采用P2P的Gossip（流言）协议，节点之间不断的通信交换信息，一段时间后所有的节点都会知道完整的信息，类似留言传播。

常用的Gossip消息可分为：ping消息、pong消息、meet消息、fail消息等。

meet消息：用于通知新节点加入。

ping消息：用于检测节点是否在线和交换彼此状态信息。

pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信。

fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个 fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态。

3.集群扩容

3.1.准备新节点

        新加入的结点还没有和其他结点通信。加入集群使用cluster meet ip 端口 命令。集群内新旧节点会相互发送ping/pong消息通信，一段时间后所有节点都会发现新节点并把状态保存到本地。目前新节点还不支持读写功能，没有负责的主节点的槽或者是设置某个主节点的从节点。

3.2迁移槽和数据

（1）首选需要针对槽做迁移计划，需要保证每个节点负责相似数量的槽，保证各节点分配均匀。比如加入新节点6007，原有节点负责的槽数量从 5462变为4096个。

（2）迁移数据，逐个槽进行迁移。槽迁移过程中集群正常提供读写服务。

4.缩容集群

        首先要确认要下线的节点是否持有槽，没有持有槽通知其他节点忘记下线节点。持有槽，需要把槽内的数据迁移到其他节点之后在下线节点。缩容原理与节点扩容的迁移槽过程一致。

5.故障转移

        redis集群实现了高可用。高可用首先需要解决集群内少了结点出现故障时通过自动故障转移保证集群可以正常的对外提供服务。

5.1故障发现

        redis集群内通过ping/pong消息命令结点通信，传播结点槽信息和其他状态(主从，节点故障)。故障发现是通过消息传播机制实现的。主要包含主观下线 （pfail）和客观下线（fail）。

（1）主观下线：集群中每个结点都会定期像其他结点发送ping命令，接收点回复pong消息作为相应。如果在cluster-node-timeout时间内通信一直失败。则发送节点会认为接收节点存在故障，把接收节点标记为主观下线（pfail）状态。

（2）客观下线：当某个节点判断另一个节点主观下线后，节点状态会跟随消息在集群内传播。ping/pong消息的消息体会携带集群1/10的其他节点状态数据， 当接受节点发现消息体中含有主观下线的节点状态时，会在本地找到故障节点的ClusterNode结构，保存到下线报告链表中，报告链表内保存了保存了其他主节点针对当前节点的下线报告。当半数以上持有槽的主节点都标记某个节点是主观下线时，触发客观下线流程。如果是持有槽的主节点，需要进行故障转移。

5.2故障恢复

        故障节点客观下线后，如果主节点是持有槽的主节点则需要选一个替代它。保证集群的高可用性。下线主节点的所有节点承担恢复的义务，当从节点通过内部定时任务发现复制的主节点进入客观下线时，会触发故障恢复流程。

故障转移过程：

（1）资格检查：判断短线时间大于配置不参与选举。

（2）准备选举时间：从节点符合资格，更新触发故障的选举时间，到达时间后执行后续流程。延迟触发机制，主要是为了通过不同的延迟选举时间支持优先级问题。复制偏移量越大说明从节点延迟越低应该替换故障主节点。rank为0表示偏移量最大。

（3）发起选举：当任一从节点到达故障选举时间后，发起选举。 延迟时间少的优先选举。广播选举消息。

（4）选举投票：只有持有槽的结点参与选举，一个主节点只能投个一个从节点，N/2+1的选票为主节点。

（5）替换主节点:从节点取消复制变成主节点，执行clusterDelSlot操作撤销故障主节点复制的槽，执行clusterAddSlot把这些槽委派给自己。集群广播自己的pong消息，通知其他结点当前从节点变成主节点，并接管故障主节点复制的槽。