Redis集群选举机制

转载已于 2023-09-01 17:35:05 修改 · 711 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://www.cnblogs.com/wugang/p/14490649.html

文章标签：

#redis #java #数据库

于 2023-09-01 13:26:32 首次发布

redis 专栏收录该内容

91 篇文章

订阅专栏

文章解释了Redis集群中Master选举过程，强调使用奇数Master数量确保高可用性，即使部分故障也能通过过半机制选举新Master。偶数虽可，但奇数在故障恢复上更优。拓展时，增加至奇数Master数量维持高可用。

文章系转载，原文地址：https://www.cnblogs.com/wugang/p/14490649.html

1.每个slave会与自己的master通讯，当slave发现自己的master变为fail时。每个slave都会参与竞争，推举自己为master。
2.增加currentEpoch的值，并且每个slave向集群中的其他所有节点广播FAILOVER_AUTH_REQUEST。
3.其他master会受到多个slave的广播，但是只会给第一个slave回复FAILOVER_AUTH_ACK。
4.slave接收到ack之后，会使用过半机制开始统计。即：当前有多少master给自己ack，如果超过一半的master发送ack，则成为master。
5.广播PONG，通知给集群中的其节点。
至此，选举流程结束。

思考

Redis集群中，为什么Master的数量要使用奇数？使用偶数是否可以？
答案是可以。但是因为采用过半机制的选举流程，在高可用方面来说，与偶数是一致的。
例如：
在9个master的架构中，如果4台master故障，通过过半机制，redis可以选举新的master。如果5台master故障无法选举新的master
在10个master的架构中，如果4台master故障，通过过半机制，redis可以选举新的master。如果5台master故障无法选举新的master
在高可用方面，9台master与10台master一致。所以通常会使用奇数。假设现在reids内存不足需要拓展，我们将master的数量加到11台，就高可用方面来说，就算其中5台master发送故障，也可以自动选举新的master。