分布式一致性协议Raft-案例剖析

最新推荐文章于 2022-10-10 15:05:06 发布

原创

最新推荐文章于 2022-10-10 15:05:06 发布 · 1.9k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#共识算法 #分布式 #算法

本文深入剖析了分布式一致性协议Raft在选票瓜分、网络分区和日志提交覆盖等异常场景下的应对策略。通过案例分析，揭示了Raft如何通过随机心跳超时和选举机制避免选票瓜分，防止网络分区导致的数据不一致，以及如何解决日志提交被覆盖的问题，确保集群数据一致性。

前言

这是Raft系列文章的第二篇。在上一篇《认识Raft》 中我们成功论证了Raft保证集群数据一致性的问题。然而现实世界是非常复杂的，任何情况都可能发生。那么对于各种异常场景Raft集群究竟如何应对的呢？

本篇会列举几个经典的Case来解释Raft的应对措施。如果没看过上一篇《认识Raft》 文章的同学可以先看一下，这篇相当于上篇的加强补充篇。

案例剖析

场景一-选票瓜分

上一篇我们知道，Leader为了巩固自己的领导地位，会定期向Follower发送心跳。假设集群中有4个节点，当Leader挂掉的时候，如果Follower有多个都出现心跳超时，这时集群会出现多个Candidate进行选举。多个Candidate同时选举
上图展示节点B和节点C同时成为Candidate，并且分别向其他三个节点发送投票请求（绿色小球表示投票请求）。因为B和C首先都会投给自己一票，要想成为Leader，还需要至少两个节点投票给自己形成多数派。Raft规定：每个节点对同一个Term最多投一票。 此时B和C都处于Term 4，而A和D处于Term 3，因此B和C都有机会获得来自A和D的投票，关键就看投票请求到达的先后。假如C的投票请求先到达A和D，获得了A和D的投票，那么C就提升为Leader。同理B也一样。但是还有一种情况，D投票给