doc: 阅读redis cluster文档
This commit is contained in:
@@ -240,6 +240,12 @@
|
||||
- [replica election and promotion](#replica-election-and-promotion)
|
||||
- [Replica Rank](#replica-rank)
|
||||
- [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
|
||||
@@ -3803,4 +3809,90 @@ DELAY = 500 milliseconds + random delay between 0 and 500 milliseconds + REPLICA
|
||||
- 如果master已经投过票,那么在`NODE_TIMEOUT * 2`的时间范围内,master并不会再次针对`同一master的replica`投票
|
||||
- 对master而言,其并不会对`选取最佳副本`做任何尝试。如果replica的master处于FAIL状态,并且master在本epoch内没有针对`master of replica`进行投票,那么直接会授予选票。但是,基于replica发起AUTH REQUEST之前的延迟,最佳的副本最有可能赢得选举,因为其发起请求最早
|
||||
- 如果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`
|
||||
|
||||
|
||||
Reference in New Issue
Block a user