本文深入剖析了分布式一致性协议Raft在选票瓜分、网络分区和日志提交覆盖等异常场景下的应对策略。通过案例分析，揭示了Raft如何通过随机心跳超时和选举机制避免选票瓜分，防止网络分区导致的数据不一致，以及如何解决日志提交被覆盖的问题，确保集群数据一致性。
前言
这是Raft系列文章的第二篇。在上一篇《认识Raft》 中我们成功论证了Raft保证集群数据一致性的问题。然而现实世界是非常复杂的，任何情况都可能发生。那么对于各种异常场景Raft集群究竟如何应对的呢？
本篇会列举几个经典的Case来解释Raft的应对措施。如果没看过上一篇《认识Raft》 文章的同学可以先看一下，这篇相当于上篇的加强补充篇。
案例剖析
场景一-选票瓜分
上一篇我们知道，Leader为了巩固自己的领导地位，会定期向Follower发送心跳。假设集群中有4个节点，当Leader挂掉的时候，如果Follower有多个都出现心跳超时，这时集群会出现多个Candidate进行选举。
上图展示节点B和节点C同时成为Candidate，并且分别向其他三个节点发送投票请求（绿色小球表示投票请求）。因为B和C首先都会投给自己一票，要想成为Leader，还需要至少两个节点投票给自己形成多数派。Raft规定：每个节点对同一个Term最多投一票。 此时B和C都处于Term 4，而A和D处于Te
最低0.47元/天 解锁文章
487
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
