SOFAJRaft 是一个基于 Raft 分歧性算法的消费级高功用 Java 完成，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 运用 SOFAJRaft 你可以专注于本人的业务范围，由 SOFAJRaft 担任处置一切与 Raft 相关的技术难题，并且 SOFAJRaft 十分易于运用，你可以经过几个示例在很短的时间内掌握它。
https://raft.github.io
SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改良，感谢百度 braft 团队开源了如此优秀的 C++ Raft 完成。
https://github.com/brpc/braft
基础知识：散布式共识算法 (Consensus Algorithm)如何了解散布式共识?
多个参与者某一件事分歧 ：一件事，一个结论
已达成分歧的结论，不可推翻
有哪些散布式共识算法?
Paxos：被以为是散布式共识算法的基本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的进程，并没有给出复制形状机中需求的 multi-paxos 的相关细节的描画，完成 Paxos 具有很高的工程复杂度（如多点可写，允许日志空泛等）。
Zab：被运用在 Zookeeper 中，业界运用普遍，但没有笼统成通用的 library。
Raft：以容易了解著称，业界也涌现出很多 Raft 完成，比如大名鼎鼎的 etcd, braft, tikv 等。
什么是 Raft？Raft 是一种更易于了解的散布式共识算法，中心协议本质上还是师承 Paxos 的精髓，不同的是依托 Raft 模块化的拆分以及愈加简化的设计，Raft 协议相对更容易完成。
https://raft.github.io/
模块化的拆分主要体如今：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 中的几个概念做一个复杂引见，详细请参考 Raft paper。
https://raft.github.io/raft.pdf
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 招致)。
本图出自《Raft: A Consensus Algorithm for Replicated Logs》
什么是 SOFAJRaft？SOFAJRaft 是一个基于 Raft 分歧性算法的消费级高功用 Java 完成，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 运用 SOFAJRaft 你可以专注于本人的业务范围，由 SOFAJRaft 担任处置一切与 Raft 相关的技术难题，并且 SOFAJRaft 十分易于运用，你可以经过几个示例在很短的时间内掌握它。
https://github.com/brpc/braft
SOFAJRaft 是从百度的 braft 移植而来，做了一些优化和改良，感谢百度 braft 团队开源了如此优秀的 C++ Raft 完成。
SOFAJRaft 全体功用&功用优化功用支持
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 切换前后的日志分歧性。
3.Snapshot and log compaction：定时生成 snapshot，完成 log compaction 减速启动和恢复，以及 InstallSnapshot 给 Followers 拷贝数据，如下图：
本图出自《In Search of an Understandable Consensus Algorithm》
4.Membership change：用于集群线上配置变更，比如添加节点、删除节点、交流节点等。
5.Transfer leader：自动变更 leader，用于重启维护，leader 负载平衡等。
6.Symmetric network partition tolerance：对称网络分区容忍性。
(责任编辑：admin)