各大中间件底层技术-分布式一致性协议 Raft 详解

前言

---

正式介绍 Raft 协议之前，我们先来举个职场产研团队的一个例子🌰。

方式一：

在一个技术团队内假设角色都是 均等的，会导致什么情况呢？产品提出一个需求，就可以随便去找团队中的任意一个人去发起需求。如果这个人因为请假走了，但是他没有把需求及时同步给团队其他人，因此会导致该需求存在很大的延迟。

方式二：

在技术团队中选举一个 ** Leader角色**，产品提出的需求必须优先提给 Leader，找 Leader 先沟通。Leader 自己消化完后，在将需求传达给团队其他成员。如果 Leader 请假了，会指定某一个人充当 Leader 角色负责接收产品需求，并将需求同步给其他成员。

上述很简单的案例，可以对应理解分布式系统中的数据一致性算法。

分布式系统数据一致性算法一般都应用在中间件项目中，平时你写的业务代码，一般根本不会接触到的。

SpringCloud 家族中集成了大名鼎鼎的注册中心 Eureka 就使用的上面的 方式一 的思路来完成节点之间数据同步的，称为 Peer To Peer 集群架构。

Eureka 当中的每个节点的地位都是均等的，每个节点都可以接收写入请求，每个节点接收请求之后，进行请求打包处理，异步化延迟一点时间，将数据同步给 Eureka 集群当中的其他节点。任何一台节点宕机之后，理论上应该是不影响集群运行的，都可以从其他节点获取注册表信息。

另外的一些开源项目，比如 Etcd、Consul，Zookeeper，还有未来会流行的国产技术阿里开源的 Nacos 项目，其中的 CP 模式也是基于 Raft 协议 来实现分布式一致性算法的。当然 Zookeeper 在 Raft 协议基础上做了一些改良，使用的 ZAB 分布式一致性协议来实现的。

在 Raft 协议出现之前，广泛使用的一致性算法是 Paxos。Paxos 算法解决的是如何保障单一客户端操作的一致性，完成每个操作都需要至少两轮的消息交换。和 Paxos 算法不同，Raft 里有 Leader 的概念，Raft 在处理任何客户端操作之前必须要选举出来一个 leader 角色，选举一个 Leader 经过至少一轮的消息交换，但是选举了 Leader 之后，处理每个客户端的操作只需要一轮消息交换。

详解 Raft 协议

---

接下来，围绕如下几点展开：

1）Leader选举流程

2）节点心跳检测

3）选主超时操作

4）日志复制流程

5）日志条目结构

6）Leader崩溃恢复操作

---

1）Leader选举流程

如果系统中只有唯一一个节点，读写操作都由这一个节点来负责，不会存在数据不一致的问题。

但是，对于分布式系统会存在至少两个节点，需要有一个角色来充唯一的节点，我们把这个唯一节点叫做 Leader 节点，其他节点叫做 <