Redis 笔记十一 官方cluster分区

Redis3.0 之后， Redis 官方提供了完整的集群解决方案。

方案采用去中心化的方式，包括： sharding （分区）、 replication （复制）、 failover （故障转移）。 称为RedisCluster 。

Redis5.0 前采用 redis-trib 进行集群的创建和管理，需要 ruby 支持

Redis5.0可以直接使用Redis-cli进行集群的创建和管理
部署架构

去中心化

RedisCluster 由多个 Redis 节点组构成，是一个 P2P 无中心节点的集群架构，依靠 Gossip 协议传播的集群。

Gossip协议

Gossip 协议是一个通信协议，一种传播消息的方式。

起源于：病毒传播

Gossip 协议基本思想就是：

一个节点周期性 ( 每秒 ) 随机选择一些节点，并把信息传递给这些节点。

这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。

信息会周期性的传递给 N 个目标节点。这个 N 被称为 fanout （扇出）

gossip 协议包含多种消息，包括 meet 、 ping 、 pong 、 fail 、 publish等等。
通过gossip协议，cluster可以提供集群间状态同步更新、选举自助failover等重要的集群功能 。
slot

redis-cluster 把所有的物理节点映射到 [0-16383] 个 slot 上 , 基本上采用平均分配和连续分配的方式。
cluster 负责维护节点和 slot 槽的对应关系 value------>slot-------->节点

当需要在 Redis 集群中放置一个 key-value 时， redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽， redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

RedisCluster的优势

1.高性能

Redis Cluster 的性能与单节点部署是同级别的。

多主节点、负载均衡、读写分离

2.高可用

Redis Cluster 支持标准的 主从复制配置来保障高可用和高可靠。

failover

Redis Cluster 也实现了一个类似 Raft 的共识方式，来保障整个集群的可用性。

3.易扩展

向 Redis Cluster 中添加新节点，或者移除节点，都是透明的，不需要停机。

水平、垂直方向都非常容易扩展。

数据分区，海量数据，数据存储

4.原生

部署 Redis Cluster 不需要其他的代理或者工具，而且 Redis Cluster 和单机 Redis 几乎完全兼容。
分片

不同节点分组服务于相互无交集的分片（ sharding ）， Redis Cluster 不存在单独的 proxy 或配置服务器，所以需要将客户端路由到目标的分片

客户端路由

Redis Cluster 的客户端相比单机 Redis 需要具备路由语义的识别能力，且具备一定的路由缓存能力

moved 重定向

1. 每个节点通过通信都会共享 Redis Cluster 中槽和集群中对应节点的关系

2. 客户端向 Redis Cluster 的任意节点发送命令，接收命令的节点会根据 CRC16 规则进行 hash 运算与16384取余，计算自己的槽和对应节点

3. 如果保存数据的槽被分配给当前节点，则去槽中执行命令，并把命令执行结果返回给客户端

4. 如果保存数据的槽不在当前节点的管理范围内，则向客户端返回 moved 重定向异常

5. 客户端接收到节点返回的结果，如果是 moved 异常，则从 moved 异常中获取目标节点的信息

6.客户端向目标节点发送命令，获取命令执行结果

ask重定向
在对集群进行扩容和缩容时，需要对槽及槽中数据进行迁移
当客户端向某个节点发送命令，节点向客户端返回 moved异常，告诉客户端数据对应的槽的节点信息

如果此时正在进行集群扩展或者缩空操作，当客户端向正确的节点发送命令时，槽及槽中数据已经被迁移到别的节点了，就会返回ask ，这就是 ask重定向机制

1. 客户端向目标节点发送命令，目标节点中的槽已经迁移支别的节点上了，此时目标节点会返回 ask 转向给客户端

2. 客户端向新的节点发送 Asking 命令给新的节点，然后再次向新节点发送命令

3. 新节点执行命令，把命令执行结果返回给客户端

moved和ask的区别

1 、 moved ：槽已确认转移

2 、 ask：槽还在转移过程中

Smart智能客户端

JedisCluster

JedisCluster 是 Jedis 根据 RedisCluster 的特性提供的集群智能客户端

JedisCluster 为每个节点创建连接池，并跟节点建立映射关系缓存（ Cluster slots ）

JedisCluster 将每个主节点负责的槽位一一与主节点连接池建立映射缓存

JedisCluster 启动时，已经知道 key,slot 和 node 之间的关系，可以找到目标节点

JedisCluster 对目标节点发送命令，目标节点直接响应给 JedisCluster

如果 JedisCluster 与目标节点连接出错，则 JedisCluster 会知道连接的节点是一个错误的节点此时节点返回moved 异常给 JedisCluster

JedisCluster 会重新初始化 slot 与 node 节点的缓存关系，然后向新的目标节点发送命令，目标命令执行命令并向JedisCluster 响应

如果命令发送次数超过 5次，则抛出异常"Too many cluster redirection!"

 

迁移

在 RedisCluster 中每个 slot 对应的节点在初始化后就是确定的。在某些情况下，节点和分片需要变更：

1.新的节点作为 master 加入；

2.某个节点分组需要下线；

3.负载不均衡需要调整 slot 分布。
此时需要进行分片的迁移，迁移的触发和过程控制由外部系统完成。包含下面 2 种：

1.节点迁移状态设置：迁移前标记源 / 目标节点。

2.key迁移的原子化命令：迁移的具体步骤。

1 、向节点 B 发送状态变更命令，将 B 的对应 slot 状态置为 importing 。
2 、向节点 A 发送状态变更命令， 将A 对应的 slot 状态置为 migrating 。
3 、向 A 发送 migrate 命令，告知 A 将要迁移的 slot 对应的 key 迁移到B 。

4 、当所有 key 迁移完成后， cluster setslot 重新设置槽位。

 

容灾（failover）
故障检测

集群中的每个节点都会定期地（每秒）向集群中的其他节点发送 PING 消息

如果在一定时间内 (cluster-node-timeout) ，发送 ping 的节点 A 没有收到某节点 B 的 pong 回应，则 A 将 B 标识为pfail 。

A 在后续发送 ping 时，会带上 B 的 pfail 信息， 通知给其他节点。

如果 B 被标记为 pfail 的个数大于集群主节点个数的一半（ N/2 + 1 ）时， B 会被标记为 fail ， A 向整个集群广播，该节点已经下线。 其他节点收到广播，标记B 为 fail

从节点选举

raft ，每个从节点，都根据自己对 master 复制数据的 offset ，来设置一个选举时间， offset 越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。

slave 通过向其他 master 发送 FAILVOER_AUTH_REQUEST 消息发起竞选，

master 收到后回复 FAILOVER_AUTH_ACK 消息告知是否同意。

slave 发送 FAILOVER_AUTH_REQUEST 前会将 currentEpoch 自增，并将最新的 Epoch 带入到FAILOVER_AUTH_REQUEST 消息中，如果自己未投过票，则回复同意，否则回复拒绝。

所有的 Master 开始 slave 选举投票，给要进行选举的 slave 进行投票，如果大部分 master node （ N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成 master 。

RedisCluster 失效的判定：

1 、集群中半数以上的主节点都宕机（无法投票）

2 、宕机的主节点的从节点也宕机了（ slot 槽分配不连续）

变更通知

当 slave 收到过半的 master 同意时，会成为新的 master 。此时会以最新的 Epoch 通过 PONG 消息广播自己成为master ，让 Cluster 的其他节点尽快的更新拓扑结构(node.conf)
主从切换
自动切换
手动切换

人工故障切换是预期的操作，而非发生了真正的故障，目的是以一种安全的方式 ( 数据无丢失 ) 将当前master节点和其中一个 slave 节点 ( 执行 cluster-failover 的节点 ) 交换角色

1 、向从节点发送 cluster failover 命令（ slaveof no one ）

2 、从节点告知其主节点要进行手动切换（ CLUSTERMSG_TYPE_MFSTART ）

3 、主节点会阻塞所有客户端命令的执行（ 10s ）

4 、从节点从主节点的 ping 包中获得主节点的复制偏移量

5 、从节点复制达到偏移量，发起选举、统计选票、赢得选举、升级为主节点并更新配置

6 、切换完成后，原主节点向所有客户端发送 moved 指令重定向到新的主节点

以上是在主节点在线情况下。

如果主节点下线了，则采用 cluster failover force 或 cluster failover takeover 进行强制切换

 

副本漂移

我们知道在一主一从的情况下，如果主从同时挂了，那整个集群就挂了。

为了避免这种情况我们可以做一主多从，但这样成本就增加了。

Redis提供了一种方法叫副本漂移，这种方法既能提高集群的可靠性又不用增加太多的从机。

Master1 宕机，则 Slaver11 提升为新的 Master1

集群检测到新的 Master1 是单点的（无从机）

集群从拥有最多的从机的节点组（ Master3 ）中，选择节点名称字母顺序最小的从机（ Slaver31 ）漂移到单点的主从节点组(Master1) 。

具体流程如下（以上图为例）：

1 、将 Slaver31 的从机记录从 Master3 中删除

2 、将 Slaver31 的的主机改为 Master1

3 、在 Master1 中添加 Slaver31 为从节点

4 、将 Slaver31 的复制源改为 Master1

5 、通过 ping 包将信息同步到集群的其他节点