doc: 阅读redis cluster文档

This commit is contained in:
asahi
2025-10-15 14:54:17 +08:00
parent 5e9a6fa7cd
commit 04e8485dca

View File

@@ -240,6 +240,12 @@
- [replica election and promotion](#replica-election-and-promotion) - [replica election and promotion](#replica-election-and-promotion)
- [Replica Rank](#replica-rank) - [Replica Rank](#replica-rank)
- [masters reply to replica vote request](#masters-reply-to-replica-vote-request) - [masters reply to replica vote request](#masters-reply-to-replica-vote-request)
- [Example of configuration epoch usefulness during partitions](#example-of-configuration-epoch-usefulness-during-partitions)
- [Hash slots configuration propagation](#hash-slots-configuration-propagation)
- [Rule 1](#rule-1)
- [Rule 2](#rule-2)
- [UPDATE message, a closer look](#update-message-a-closer-look)
- [How nodes rejoin the cluster](#how-nodes-rejoin-the-cluster)
# redis # redis
@@ -3803,4 +3809,90 @@ DELAY = 500 milliseconds + random delay between 0 and 500 milliseconds + REPLICA
- 如果master已经投过票那么在`NODE_TIMEOUT * 2`的时间范围内master并不会再次针对`同一master的replica`投票 - 如果master已经投过票那么在`NODE_TIMEOUT * 2`的时间范围内master并不会再次针对`同一master的replica`投票
- 对master而言其并不会对`选取最佳副本`做任何尝试。如果replica的master处于FAIL状态并且master在本epoch内没有针对`master of replica`进行投票那么直接会授予选票。但是基于replica发起AUTH REQUEST之前的延迟最佳的副本最有可能赢得选举因为其发起请求最早 - 对master而言其并不会对`选取最佳副本`做任何尝试。如果replica的master处于FAIL状态并且master在本epoch内没有针对`master of replica`进行投票那么直接会授予选票。但是基于replica发起AUTH REQUEST之前的延迟最佳的副本最有可能赢得选举因为其发起请求最早
- 如果master拒绝为replica进行投票那么其并不会向replica发送negative reply仅仅会无视请求 - 如果master拒绝为replica进行投票那么其并不会向replica发送negative reply仅仅会无视请求
- master不会为 - 如果replicas发送的configEpoch小于`master table中负责replica宣称slots的configEpoch`那么master将不会为replica投票
#### Example of configuration epoch usefulness during partitions
如下示例展示了epoch如何令replica promotion的过程在network partition的场景下容错性更高
- 假如一个master之后都不再可访问且其拥有3个replicas A, B, C
- replica A赢得选举并且被提升为master
- network partition令A不再可被majority of clusters访问
- replica B赢得选举并被提升为master
- partition又令B不再可被majority of clusters访问
- 此时第一次partition恢复A再次可被访问
在这种场景下B宕机而A又重新可访问此时A的role仍为master同时replica也在尝试发起选举具体发生如下
- C会尝试被选举并且成功因为对于majority of masters而言C的masterB已经宕机C将会获取一个新的configEpoch
- A在通过ping/pong packet向其他节点生成其为master的操作会失败对于其他节点而言A宣称的slots已经关联了更高版本configEpoch
- 故而所有节点都会更新其table将对应hash slots分配给C
#### Hash slots configuration propagation
在redis cluster中`节点负责slots集合信息的传播机制`是重要的部分。该机制对于`新集群启动`以及`replica被提升为master后升级configuration`都至关重要。
通过该机制允许节点在被partitioned away任意长时间之后都能以合理的方式重新加入集群。
如下存在两种hash slot configuration的传播方式
- heartbeat message: ping/pong packet的发送者总会将其负责slots的信息添加到packet中
- update message: 由于每个heartbeat message中都包含发送方的configEpoch以及负责slots的信息如果heartbeat message的接收方发现发送方的信息已过时则会向发送方发送一个update message用于对发送方进行更新update message中包含新的信息
heartbeat/UPDATE message的接收方会使用简单的规则来更新hash slots到node的映射table。当创建新的cluster node时新节点的local hash slot table将会简单初始化为NULL entires故而每个hash slot都没有和任何node相关联示例如下
```
0 -> NULL
1 -> NULL
2 -> NULL
...
16383 -> NULL
```
##### Rule 1
如果一个hash slot并没有被分配给任何节点设置为NULL并且有一个known node对该slot做了宣称那么会修改hash slot table将该hash slot与宣称节点做关联。
故而如果从A节点处接收到了heartbeat packet宣称A将负责1和2slot且configEpoch值为3那么table被修改后的值如下
```
0 -> NULL
1 -> A [3]
2 -> A [3]
...
16383 -> NULL
```
当创建新的cluster时系统管理员需要手动将slots分配给masters并且该分配信息将会在集群内传播。
但是hash slots可以通过如下两种事件进行修改故而上述规则是不够的
- 当failover导致replica promotion时由原master负责的节点会被重新分配给replica
- 通过reshard一个slot可以从一个节点被移动到另一个节点
当故障转移发生时其会获取一个新的configEpoch该configEpoch比之前生成过的任何configEpoch都要大。在完成故障转移后其会在集群范围内广播heartbeat packet而packet的接收方将更新其slot table。
##### Rule 2
如果hash slot已经被分配并且一个known node声称其负责该hash slot那么会比较configEpoch的大小。如果heartbeat的大小要大于当前hash slot table中该hash slot的configEpoch其会将hash slot重新绑定给新的节点。
故而在从B处收到消息声称其负责hash slot 1和hash slot 2且configEpoch为4时接收方则会将其hash slot table更新更新后内容如下
```
0 -> NULL
1 -> B [4]
2 -> B [4]
...
16383 -> NULL
```
由于Rule 2最终集群中所有的节点都会达成共识hash slot的owner为`声称该slot的所有节点中configEpoch最大的节点`
redis cluster中该机制被称为`last failover wins`
在resharding的过程中也会发生上述流程。当`node importing a hash slot`完成import操作时其configuration epoch将会递增确保该改动将会在集群中传播。
### UPDATE message, a closer look
在先前的章节中表明了update message的工作机制。node A可能在一段时间后重新加入到集群中其会发送heartbeat packets来声称其对hash slot 1和2的所有权epoch为3。所有`receivers with updated information`都会发现被声称的slot已经被分配且该分配的configEpoch更大。
故而拥有更大configEpoch的接收者将会向node A发送UPDATE message向A发送最新的配置而A会对slot的分配进行更新。
### How nodes rejoin the cluster
当节点重新加入到cluster时将使用同样的机制。
继续使用上述的示例node A将会被通知hash slot 1和2目前归属于node B。假设slot 1和2是A仅有的slots那么A所负责的slots的数量将会变为0故而A将会重新变为新master的replica。
在实际场景下可能会更加复杂。如果A在过了很久之后才重新加入集群那么A原来负责的slots可能散布在多个节点中例如slot 1现可能归属于B而slot 2现归属于C。
实际的cluster node role switch rule如下
- a master node will change its configuration to replciate the node that stole its last hash slot
对于replicas而言其行为和master相同也会`reconfigure to replicate the node that stole the last hash slot of its former master`