Redis集群

Redis集群

Redis 集群通过分片来进行数据共享，并提供复制和故障转移功能。

1. 节点

1.1 节点的握手

Redis 集群中各个节点使用 CLUSTER MEET 命令进行连接。

CLUSTER MEET <ip> <port>

向一个节点 node 发送CLUSTER MEET命令，可以让 node 节点与 ip 和 port 的指定节点进行握手。握手成功后，node 节点会将目标节点添加到 node 节点所在的集群中。

重复这个操作，可以让多个节点处于同一集群。

1.2 集群数据结构

• clusterNode结构保存了一个节点的当前状态，包括节点创建时间、节点名字、节点配置纪元、节点 IP 地址和端口号等等。

• clusterLink结构是clusterNode的一个属性，保存了连接节点所需的有关信息，比如套接字描述符、输入缓冲区和输出缓冲区等等。

• clusterState结构被每个节点所保存，记录了当前节点视角下集群所处状态，例如集群是在线还是下线，集群包含多少个节点，集群当前的配置纪元等等。

  

1.3 CLUSTER MEET命令实现

收到命令的节点 A 将与目标节点 B 进行握手。

2. 槽指派

2.1 Redis中的槽

Redis 集群通过分片来保存数据库中的键值对，集群的整个数据库被分为 16384 个槽，数据库中的每个键都属于这 16384 个槽中的一个，集群中的每个节点可以处理 0 个或最多 16384 个槽。

当数据库中的 16384 个槽都有节点在处理，集群处于上线状态。如果有任何一个槽没有节点处理，那么集群处于下线状态。

通过向节点发送CLUSTER ADDSLOTS命令，我们可以将一个或多个槽指派给节点负责。例如以下命令可以将槽 0~5000 指派给节点 7000 负责：

127.0.0.1:7000> CLUSTER ADDSLOTS 0 1 2 3 4 ... 5000

2.2 记录节点的槽指派信息

clusterNode结构的slots属性和numslot属性记录了节点负责处理哪些槽。

• slots长度为 16384，某一位的长度是 1 或者 0，代表这个槽有没有被当前的节点负责处理。
• numslots属性记录了当前节点负责处理的槽的数量。

2.3 传播节点的槽指派信息

节点会将自己的slots数组通过消息发送给集群中的其他节点，告诉他们自己目前负责处理哪些槽。

当节点 A 通过消息从节点 B 那里接收到节点 B 的slots数组时，会在自己的clusterState.nodes字典中查找节点 B 对应的clusterNode结构，并进行更新。

3. 在集群中执行命令

上线状态的集群可以执行命令。

当客户端向节点发送命令时，接受命令的节点会检查命令要处理的数据库键属于哪个槽，并检查这个槽是否指派给了自己。

• 如果是，则执行命令。
• 如果不是，则向客户端返回一个MOVED错误，指引客户端转向正确节点，重新发送之前的命令。

3.1 计算键属于哪个槽

redis使用如下算法来计算给定的key属于哪个槽

def slot_number(key):
	return CRC16(key) & 16383

CRC16(key)语句计算出key的CRC-16校验和，而& 16383计算出一个介于 0 和 16383 之间的整数作为key的槽号。

CLUSTER KEYSLOT命令是根据上面的槽分配算法来实现的。

3.2 判断槽是否由当前节点负责

检查自己的slots数组中的对应位置即可。

3.3 MOVED错误

MOVED错误的格式为：

MOVED <slot> <ip>:<port>

客户端可以根据MOVED错误，转向正确的节点。

3.4 节点数据库的实现

除了将键值对保存在数据里面外，节点还会用clusterState结构中的slots_to_keys跳跃表来保存槽和键之间的关系。

该跳表的每个节点的分值都是一个槽号。而每个节点的成员都是一个数据库键。

使用这个跳表，可以方便地对属于某些槽的所有数据库键进行批量操作。

4. 重新分片

4.1 重新分片流程

Redis 集群的重新分片操作可以令分派给某个槽的节点重新分派给另一个节点。重新分片可以在线进行，过程中集群不需要下线，且可以正常处理命令请求。

重新分片由 Redis 集群管理软件redis-trib负责执行。

重新分片流程如上图。如果要分片的槽属于多个节点，就要对多个节点发送命令。

4.2 ASK错误

重新分片期间可能出现一种情况：属于被迁移槽的一部分键值对保存在源节点里面，另一部分键值对保存在目标节点里面。

此时当客户端向源节点发送一个命令，并且要求处理的数据库键恰好正在被迁移：

• 源节点现在自己的数据找，找到就直接发送命令。
• 没找到就向客户端返回 ASK 错误，指引客户端转向目标节点执行命令。

一个 ASK 错误如下图所示：

收到 ASK 错误的客户端会根据错误提供的 IP 地址和端口号，转向目标节点，先向目标节点发送一个 ASKING 命令，之后再重新发送原本要执行的命令。

ASKING 命令可以打开发送该命令的客户端的REDIS_ASKING标识。这在服务端接收到后面的命令时有用。

正在进行重新分片的服务端判断发送请求的客户端的 ASKING 标识是否打开

• 如果打开，该客户端的请求是一个槽分派时的重定向请求，正常执行。

• 如果没打开，该客户端的请求是一个普通的寻址错误的命令请求，返回 MOVED 错误。

5. 复制和故障转移

Redis 集群中的主节点用于处理槽，从节点用于复制某个主节点，并且在被复制的主节点下线时接替它。

假如某个场景下服务器间的状态如下：

假如主服务器 7000 下线，那么剩余的主服务器即 7001、7002、7003 会从 7000 的两个从服务器 7004、7005 选择一个接管 7000 负责的槽。另一个从服务器会变成新主服务器的从服务器。

如果后续 7000 重新上线，它会变成 7004 的新主节点。

5.1 故障检测

集群中每个节点会定时向集群中的其它节点发送 PING 消息，以此检测对方是否下线。如果接收 PING 的节点没有在规定时间内返回 PONG 消息，就会被标记为疑似下线。

集群中的节点在别的节点的视角下有三种状态：在线、疑似下线、已下线。

当一个主节点 A 通过消息得知主节点 B 认为主节点 C 进入疑似下线时，主节点 A 会在自己的clusterState.nodes字典中找到主节点 C 对应的clusterNode结构，并将主节点 B 的下线报告添加到clusterNode结构的fail_reports链表中。

如果在集群中，有一个主节点发现半数以上的主节点都将某个主节点 x 标记为意思下线，那么他将把这个主节点标记为已下线，并向其他所有节点广播 FAIL 消息。

5.2 故障转移

当一个从节点发现自己正在复制的主节点进入已下线状态时，从节点将开始对下线主节点进行故障转移操作：

1. 第一个发现问题的主节点举行一个选举，要求自己称为新的主节点。选举的规则和 Sentinel 中选举领头 Sentinel 非常相似，他们都基于 Raft 算法的领头选举方法。
   • 成功则称为新主节点
   • 失败则等待下一个从节点提出选举。
2. 被选中的从节点执行SLAVEOF no one命令，成为新的主节点。
3. 新的主节点接管已下线主节点的全部槽指派。
4. 新主节点广播 PONG 消息，让别的节点知道自己已经成为主节点。
5. 新主节点开始行使主节点职责。