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

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：对称收集分区容忍性。

如上图 S1 为当前 leader，收集分区造成 S2 不绝增进当地 term，为了停止收集规复后 S2 提倡推举导致正在本心 事变的 leader step-down，从而导致整个集群从头提倡推举，SOFAJRaft 中增进了 pre-vote 来停止这个题目的产生。

SOFAJRaft 中在 request-vote 之前会先举办 pre-vote(currentTerm + 1, lastLogIndex, lastLogTerm)，大都派乐成后才会转换状态为 candidate 提倡真正的 request-vote，以是分区后的节点，pre-vote 不会乐成，也就不会导致集群一段时刻内无法正常提供处事。

7.Asymmetric network partition tolerance：非对称收集分区容忍性。

如上图 S1 为当前 leader，S2 不绝超时触发选主，S3 晋升 term 打断当前 lease，从而拒绝 leader 的更新。

1. 在 SOFAJRaft 中增进了一个 tick 的搜查，每个 follower 维护一个时刻戳记录下收到 leader 上数据更新的时刻(也包罗心跳)，只有高出 election timeout 之后才应承接管 request-vote 哀求。

8.Fault tolerance：容错性，少数派妨碍不影响体系整体可用性，包罗但不限于：

1）呆板掉电

2）强杀应用

3）慢节点(GC, OOM 等)

4）收集妨碍

5）其他各类奇葩缘故起因导致 raft 节点无法正常事变

9.Workaround when quorate peers are dead：大都派妨碍时，整个 grop 已不具备可用性，安详的做法是守候大都节点规复，只有这样才气担保数据安详；可是假如营业越发追求体系可用性，可以放弃数据同等性的话，SOFAJRaft 提供了手动触发 reset_peers 的指令以敏捷重建整个集群，规复集群可用。

10.Metrics：SOFAJRaft 内置了基于 Metrics 类库的机能指标统计，具有富厚的机能统计指标，操作这些指标数据可以辅佐用户更轻易找出体系机能瓶颈。

11.Jepsen：除了几百个单位测试以及部门 chaos 测试之外, SOFAJRaft 还行使 jepsen 这个漫衍式验证和妨碍注入测试框架模仿了许多种环境，都已验证通过：

1）随机分区，一大一小两个收集分区

2）随机增进和移除节点

3）随机遏制和启动节点

4）随机 kill -9 和启动节点

5）随机分别为两组，互通一此中间节点，模仿分区环境

6）随机分别为差异的 majority 分组

机能优化

除了成果上的完备性，SOFAJRaft 还做了许多机能方面的优化，这里有一份 KV 场景（get/put）的 Benchmark 数据, 在小数据包，读写比例为 9:1，担保线性同等读的场景下，三副本最高可以到达 40w+ 的 ops。

这里挑重点先容几个优化点：

1. Batch： 我们知道互联网两大优化瑰宝即是 Cache 和 Batch，SOFAJRaft 在 Batch 上花了较大心思，整个链路险些都是 Batch 的，依赖 disruptor 的 MPSC 模子批量斲丧，对整体机能有着极大的晋升，包罗但不限于：
2. 批量提交 task
3. 批量收集发送
4. 当地 IO batch 写入
5. 要担保日记不丢，一样平常每条 log entry 都要举办 fsync 同步刷盘，较量耗时，SOFAJRaft 中做了归并写入的优化。
6. 批量应用到状态机
7. 必要声名的是，固然 SOFAJRaft 中大量行使了 Batch 能力，但对单个哀求的延时并无任何影响，SOFAJRaft 中不会对哀求做延时的攒批处理赏罚。
8. Replication pipeline：流水线复制，凡是 Leader 跟 Followers 节点的 Log 同步是串行 Batch 的方法，每个 Batch 发送之后必要守候 Batch 同步完成之后才气继承发送下一批(ping-pong)，这样会导致较长的耽误。SOFAJRaft 中通过 Leader 跟 Followers 节点之间的 pipeline 复制来改造，很是有用低落了数据同步的耽误, 进步吞吐。经我们测试，开启 pipeline 可以将吞吐晋升 30% 以上，具体数据请参照 Benchmark。
9. Append log in parallel：在 SOFAJRaft 中 Leader 耐久化 log entries 和向 Followers 发送 log entries 是并行的。
10. Fully concurrent replication：Leader 向全部 Follwers 发送 Log 也是完全彼此独立和并发的。
11. Asynchronous：SOFAJRaft 中整个链路险些没有任何阻塞，完全异步的，是一个完全的 callback 编程模子。
12. ReadIndex：优化 Raft read 走 Raft log 的机能题目，每次 read，仅记录 commitIndex，然后发送全部 peers heartbeat 来确认 Leader 身份，假如 Leader 身份确认乐成，比及 appliedIndex >= commitIndex，就可以返回 Client read 了，基于 ReadIndex Follower 也可以很利便的提供线性同等读，不外 commitIndex 是必要从 Leader 哪里获取，多了一轮 RPC；关于线性同等读文章后头会具体说明。
13. Lease Read：SOFAJRaft 还支持通过租约 (lease) 担保 Leader 的身份，从而省去了 ReadIndex 每次 heartbeat 确认 Leader 身份，机能更好，可是通过期钟维护 lease 自己并不是绝对的安详（时钟漂移题目，以是 SOFAJRaft 中默认设置是 ReadIndex，由于凡是环境下 ReadIndex 机能已足够好。

（编辑：河北网）

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