蚂蚁金服开源 SOFAJRaft：生产级 Java Raft 算法库

什么是 SOFAJRaft？

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

https://raft.github.io

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

https://github.com/brpc/braft

如何理解分布式共识?

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

有哪些分布式共识算法?

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

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

https://raft.github.io/

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

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

特点：Strong Leader

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

一句话总结 Strong Leader: "你们不要 BB! 按我说的做，做完了向我汇报!"。

另外，身为 Leader 必须保持一直 BB(heartbeat) 的状态，否则就会有别人跳出来想要 BB 。

Raft 中的基本概念

篇幅有限，这里只对 Raft 中的几个概念做一个简单介绍，详细请参考 Raft paper。

https://raft.github.io/raft.pdf

Raft-node 的 3 种角色/状态

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

Message 的 3 种类型

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

任期逻辑时钟

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

本图出自《Raft: A Consensus Algorithm for Replicated Logs》

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

https://github.com/brpc/braft

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

功能支持

1.Leader election：Leader 选举，这个不多说，上面已介绍过 Raft 中的 Leader 机制。

2.Log replication and recovery：日志复制和日志恢复。

1）Log replication 就是要保证已经被 commit 的数据一定不会丢失，即一定要成功复制到多数派。

2）Log recovery 包含两个方面：

3）Current term 日志恢复：主要针对一些 Follower 节点重启加入集群或者是新增 Follower 节点后如何追日志；

4）Prev term 日志恢复：主要针对 Leader 切换前后的日志一致性。

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!