Redis学习总结第五章--Redis集群选举原理分析

Redis学习总结第五章--Redis集群选举原理分析

 

参考文章：https://redis.io/topics/cluster-spec

 

Slave election and promotion

Slave election and promotion is handled by slave nodes, with the help of master nodes that vote for the slave to promote. A slave election happens when a master is in FAIL state from the point of view of at least one of its slaves that has the prerequisites in order to become a master.

In order for a slave to promote itself to master, it needs to start an election and win it. All the slaves for a given master can start an election if the master is in FAIL state, however only one slave will win the election and promote itself to master.

A slave starts an election when the following conditions are met:

• The slave's master is in FAIL state.
• The master was serving a non-zero number of slots.
• The slave replication link was disconnected from the master for no longer than a given amount of time, in order to ensure the promoted slave's data is reasonably fresh. This time is user configurable.

In order to be elected, the first step for a slave is to increment its currentEpoch counter, and request votes from master instances.

Votes are requested by the slave by broadcasting a FAILOVER_AUTH_REQUEST packet to every master node of the cluster. Then it waits for a maximum time of two times the NODE_TIMEOUT for replies to arrive (but always for at least 2 seconds).

Once a master has voted for a given slave, replying positively with a FAILOVER_AUTH_ACK, it can no longer vote for another slave of the same master for a period of NODE_TIMEOUT * 2. In this period it will not be able to reply to other authorization requests for the same master. This is not needed to guarantee safety, but useful for preventing multiple slaves from getting elected (even if with a different configEpoch) at around the same time, which is usually not wanted.

A slave discards any AUTH_ACK replies with an epoch that is less than the currentEpoch at the time the vote request was sent. This ensures it doesn't count votes intended for a previous election.

Once the slave receives ACKs from the majority of masters, it wins the election. Otherwise if the majority is not reached within the period of two times NODE_TIMEOUT (but always at least 2 seconds), the election is aborted and a new one will be tried again after NODE_TIMEOUT * 4 (and always at least 4 seconds).

Slave rank

As soon as a master is in FAIL state, a slave waits a short period of time before trying to get elected. That delay is computed as follows:

DELAY = 500 milliseconds + random delay between 0 and 500 milliseconds +

        SLAVE_RANK * 1000 milliseconds.

The fixed delay ensures that we wait for the FAIL state to propagate across the cluster, otherwise the slave may try to get elected while the masters are still unaware of the FAIL state, refusing to grant their vote.

The random delay is used to desynchronize slaves so they're unlikely to start an election at the same time.

 

 

官方文档关于Redis集群选举原理是这么说的：

slave节点的选举和升级是由从slave节点处理的，而master节点则需要对slave节点进行投票。当集群中存在master节点处于fail转态时，该主节点下的slave节点将产生选举并且只有一个slave节点将赢得选举并提升为master节点。

满足以下条件时，slave节点将开始选举：

1、改集群节点master节点处于FAIL状态。

2、master节点的hash槽数量非零。

3、slave节点与master节点的连接没超时，以确保升级后的slave节点数据是 合理的。这个时间是用户可配置的。

为了被选举，slave节点第一步是增加currentEpoch计数器，并请求其他master节点进行投票。slave节点通过将FAILOVER_AUTH_REQUEST数据包广播到群集的每个master节点来请求投票。然后，该slave节点最多等待NODE_TIMEOUT答复的两倍的时间（但始终至少2秒钟）。

一旦某个master节点投票给了一个slave节点FAILOVER_AUTH_ACK后，在NODE_TIMEOUT * 2这段时间里，它就不能再投票选举同一master节点下其他slave节点。在此期间，它将无法回复同一master节点下的其他授权请求。这不是保证安全所必需的，但是可以有效的防止多个slave节点在大约同一时间同时被选举。

一旦从机收到大多数master节点的ACK，便赢得选举。否则，如果在两次NODE_TIMEOUT（但始终至少为2秒）内未达到多数，则该选举将中止，并且新的选举将在之后NODE_TIMEOUT * 4（且至少应为4秒）再次尝试。

一旦主机处于FAIL状态，则slave节点会等待一小段时间才能尝试选举。延迟计算如下：

DELAY = 500 milliseconds + random delay between 0 and 500 milliseconds +  SLAVE_RANK * 1000 milliseconds.