分布式共识算法之Raft设计与实现-JZTXT

如何理解分布式共识?

多个参与者针对某一件事达成完全一致：一件事，一个结论
已达成一致的结论，不可推翻

有哪些分布式共识算法?

Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 Paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。
Zab：被应用在 Zookeeper 中，业界使用广泛，但没有抽象成通用的 library。
Raft：以容易理解著称，业界也涌现出很多 Raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等。

什么是 Raft？

Raft 是一种更易于理解的分布式共识算法，核心协议本质上还是师承 Paxos 的精髓，不同的是依靠 Raft 模块化的拆分以及更加简化的设计，Raft 协议相对更容易实现。

模块化的拆分主要体现在：Raft 把一致性协议划分为 Leader 选举、MemberShip 变更、日志复制、Snapshot 等几个几乎完全解耦的模块。

更加简化的设计则体现在：Raft 不允许类似 Paxos 中的乱序提交、简化系统中的角色状态（只有 Leader、Follower、Candidate 三种角色）、限制仅 Leader 可写入、使用随机化的超时时间来设计 Leader Election 等等。

特点：Strong Leader

系统中必须存在且同一时刻只能有一个 Leader，只有 Leader 可以接受 Clients 发过来的请求；
Leader 负责主动与所有 Followers 通信，负责将“提案”发送给所有 Followers，同时收集多数派的 Followers 应答；
Leader 还需向所有 Followers 主动发送心跳维持领导地位(保持存在感)。

一句话总结 Strong Leader: “你们不要 BB! 按我说的做，做完了向我汇报!”。另外，身为 Leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB 。

Raft 中的基本概念

Raft-node 的 3 种角色/状态

Follower：完全被动，不能发送任何请求，只接受并响应来自 Leader 和 Candidate 的 Message，每个节点启动后的初始状态一定是 Follower；
Leader：处理所有来自客户端的请求，以及复制 Log 到所有 Followers；
Candidate：用来竞选一个新 Leader （Candidate 由 Follower 触发超时而来）。

Message 的 3 种类型

RequestVote RPC：由 Candidate 发出，用于发送投票请求；
AppendEntries (Heartbeat) RPC：由 Leader 发出，用于 Leader 向 Followers 复制日志条目，也会用作 Heartbeat （日志条目为空即为 Heartbeat）；
InstallSnapshot RPC：由 Leader 发出，用于快照传输，虽然多数情况都是每个服务器独立创建快照，但是Leader 有时候必须发送快照给一些落后太多的 Follower，这通常发生在 Leader 已经丢弃了下一条要发给该Follower 的日志条目(Log Compaction 时清除掉了) 的情况下。

任期逻辑时钟

时间被划分为一个个任期 (term)，term id 按时间轴单调递增；
每一个任期的开始都是 Leader 选举，选举成功之后，Leader 在任期内管理整个集群，也就是 “选举 + 常规操作”；
每个任期最多一个 Leader，可能没有 Leader (spilt-vote 导致)。

什么是 SOFAJRaft？

SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。使用 SOFAJRaft 你可以专注于自己的业务领域，由 SOFAJRaft 负责处理所有与 Raft 相关的技术难题，并且 SOFAJRaft 非常易于使用，你可以通过几个示例在很短的时间内掌握它。Nacos源码中就使用到了此库。

SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改进，感谢百度 braft 团队开源了如此优秀的 C++ Raft 实现。源码位置