Redis-Cluster

简介

是一种去中心化的集群架构

1. 分布式，对总数据进行分片，每个节点存放一部分数据
2. 提供内置的高可用支持，当部分master不可用时，可以故障转移继续工作

Redis Cluster 优势

• 高性能

Redis Cluster 的性能与单节点部署是同级别的。
多主节点、负载均衡、读写分离

• 高可用

Redis Cluster 支持标准的 主从复制配置来保障高可用和高可靠。
failover （故障转移）
Redis Cluster 也实现了一个类似 Raft 的共识方式，来保障整个集群的可用性。

• 易扩展

向 Redis Cluster 中添加新节点，或者移除节点，都是透明的，不需要停机。
水平、垂直方向都非常容易扩展。
数据分区，海量数据存储

• 原生

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

---

部署架构

角色：master、slave

redis-cluster部署架构图

---

去中心化

Redis Cluster 由多个Redis节点组构成，是一个P2P（point to point）无中心节点的集群架构，依靠Gossip协议传播集群

• 在redis cluster 架构下，每个redis 要开放两个端口，一个默认6379，一个是加10000的端口号，默认16379
• 16379端口号是用来进行节点通信的，也就是cluster bus 的东西，集群总线，cluster bus的通信，用来进行故障检测，配置更新，故障转移授权
• cluster bus用了另外一种分布式一致性协议(Gossip)，主要用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间

Gossip

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

思想启发于：病毒传播

Gossip协议基本思想：
一个节点周期性(每秒)随机选择一些节点，并把信息传递给这些节点。

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

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

gossip协议包含多种消息，包括meet、ping、pong、fail、publish等等

命令	说明
meet	sender向receiver发出，请求receiver加入sender的集群
ping	节点检测其他节点是否在线
pong	receiver收到meet或ping后的回复信息；在failover后，新的Master也会广播pong
fail	节点A判断节点B下线后，A节点广播B的fail信息，其他收到节点会将B节点标记为下线
publish	节点A收到publish命令，节点A执行该命令，并向集群广播publish命令，收到publish 命令的节点都会执行相同的publish命令

通过gossip协议，cluster可以提供集群间状态同步更新、选举自助failover等重要的集群功能。

---

分布式hash算法

分布式架构设计中，核心问题即为如何分片数据。在技术的更替中出现过以下分布式hash算法：

1. 最老土的hash 算法和弊端（大量缓存重建）
2. 一致性hash算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
3. redis cluster 的 hash slot 算法

redis-cluster-slot

redis-cluster把所有的物理节点映射到[0-16383]个slot上,基本上采用平均分配和连续分配的方式。

slot槽必须在节点上连续分配，如果出现不连续的情况，则RedisCluster不能工作。

---

高可用

故障转移（failover）

判断故障节点

1. 集群中的每个节点都会定期地（每秒）向集群中的其他节点发送PIN

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

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

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

5. 其他节点收到广播，标记B为fail。

从节点选举

采用 raft 协议（参照Paxos算法 https://www.jianshu.com/p/40c658c9dcc2）

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

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

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

4. slave 发送FAILOVER_AUTH_REQUEST 前会将currentEpoch 自增，并将最新的Epoch 带入到FAILOVER_AUTH_REQUEST 消息中。

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

变更通知

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

RedisCluster失效的判定

• 集群中半数以上的主节点都宕机（无法投票）
• 宕机的主节点的从节点也宕机了（slot槽分配不连续）

主从切换

自动切换

就是上面讲的从节点选举

手动切换

人工故障切换是预期的操作，而非发生了真正的故障，目的是以一种安全的方式(数据无丢失)将当前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包将信息同步到集群的其他节点