如上图 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 的更新。
在 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。
这里挑重点引见几个优化点：
Batch： 我们知道互联网两大优化法宝便是 Cache 和 Batch，SOFAJRaft 在 Batch 上花了较大心思，整个链路简直都是 Batch 的，依托 disruptor 的 MPSC 模型批量消费，对全体功用有着极大的提升，包括但不限于：
批量提交 task
批量网络发送
本地 IO batch 写入
要保证日志不丢，普通每条 log entry 都要停止 fsync 同步刷盘，比较耗时，SOFAJRaft 中做了兼并写入的优化。
批量运用到形状机
需求阐明的是，虽然 SOFAJRaft 中少量运用了 Batch 技巧，但对单个央求的延时并无任何影响，SOFAJRaft 中不会对央求做延时的攒批处置。
Replication pipeline：流水线复制，通常 Leader 跟 Followers 节点的 Log 同步是串行 Batch 的方式，每个 Batch 发送之后需求等候 Batch 同步完成之后才能继续发送下一批(ping-pong)，这样会招致较长的延迟。SOFAJRaft 中经过 Leader 跟 Followers 节点之间的 pipeline 复制来改良，十分有效降低了数据同步的延迟, 提高吞吐。经我们测试，开启 pipeline 可以将吞吐提升 30% 以上，详细数据请参照 Benchmark。
Append log in parallel：在 SOFAJRaft 中 Leader 耐久化 log entries 和向 Followers 发送 log entries 是并行的。
Fully concurrent replication：Leader 向一切 Follwers 发送 Log 也是完全相互独立和并发的。
Asynchronous：SOFAJRaft 中整个链路简直没有任何阻塞，完全异步的，是一个完全的 callback 编程模型。
ReadIndex：优化 Raft read 走 Raft log 的功用成绩，每次 read，仅记载 commitIndex，然后发送一切 peers heartbeat 来确认 Leader 身份，假设 Leader 身份确认成功，等到 appliedIndex >= commitIndex，就可以前往 Client read 了，基于 ReadIndex Follower 也可以很方便的提供线性分歧读，不过 commitIndex 是需求从 Leader 那里获取，多了一轮 RPC；关于线性分歧读文章前面会详细剖析。
Lease Read：SOFAJRaft 还支持经过租约 (lease) 保证 Leader 的身份，从而省去了 ReadIndex 每次 heartbeat 确认 Leader 身份，功用更好，但是经过时钟维护 lease 本身并不是相对的安全（时钟漂移成绩，所以 SOFAJRaft 中默许配置是 ReadIndex，由于通常状况下 ReadIndex 功用已足够好。
SOFAJRaft 设计
(责任编辑：admin)