|
SOFAJRaft 计划
- Node：Raft 分组中的一个节点，毗连封装底层的全部处事，用户看到的首要处事接口，出格是 apply(task)用于向 raft group 构成的复制状态机集群提交新使命应用到营业状态机。
- 存储：上图靠下的部门均为存储相干。
- Log 存储，记录 Raft 用户提交使命的日记，将日记从 Leader 复制到其他节点上。
- LogStorage 是存储实现，默认实现基于 RocksDB 存储，你也可以很轻易扩展本身的日记存储实现；
- LogManager 认真对底层存储的挪用，对换用做缓存、批量提交、须要的搜查和优化。
- Metadata 存储，元信息存储，记录 Raft 实现的内部状态，好比当前 term、投票给哪个节点等信息。
- Snapshot 存储，用于存放用户的状态机 snapshot 及元信息，可选：
- SnapshotStorage 用于 snapshot 存储实现；
- SnapshotExecutor 用于 snapshot 现实存储、长途安装、复制的打点。
- 状态机
- StateMachine：用户焦点逻辑的实现，焦点是 onApply(Iterator) 要领, 应用通过 Node#apply(task) 提交的日记到营业状态机；
- FSMCaller:封装对营业 StateMachine 的状态转换的挪用以及日记的写入等,一个有限状态机的实现,做须要的搜查、哀求归并提交和并发处理赏罚等。
- 复制
- Replicator：用于 Leader 向 Followers 复制日记，也就是 Raft 中的 AppendEntries 挪用，包罗心跳存活搜查等；
- ReplicatorGroup：用于单个 Raft group 打点全部的 replicator，须要的权限搜查和派发。
- RPC：RPC 模块用于节点之间的收集通信
- RPC Server：内置于 Node 内的 RPC 处事器，吸取其他节点可能客户端发过来的哀求，转交给对应处事处理赏罚；
- RPC Client：用于向其他节点提倡哀求，譬喻投票、复制日记、心跳等。
- KV Store：KV Store 是各类 Raft 实现的一个典范应用场景，SOFAJRaft 中包括了一个嵌入式的漫衍式 KV 存储实现（SOFAJRaft-RheaKV）。
SOFAJRaft Group
单个节点的 SOFAJRaft-node 是没什么现实意义的，下面是三副本的 SOFAJRaft 架构图：
SOFAJRaft Multi Group
单个 Raft group 是无法办理大流量的读写瓶颈的，SOFAJRaft 天然也要支持 multi-raft-group。
SOFAJRaft 实现细节理会之高效的线性同等读
什么是线性同等读? 所谓线性同等读，一个简朴的例子就是在 t1 的时候我们写入了一个值，那么在 t1 之后，我们必然能读到这个值，不行能读到 t1 之前的旧值 (想想 Java 中的 volatile 要害字，说白了线性同等读就是在漫衍式体系中实现 Java volatile 语义)。
如上图 Client A、B、C、D 均切合线性同等读，个中 D 看起来是 stale read，着实并不是，D 哀求凌驾了 3 个阶段，而读也许产生在恣意时候，以是读到 1 或 2 都行。
重要：接下来的接头均基于一个大条件，就是营业状态机的实现必需是满意线性同等性的，简朴说就是也要具有 Java volatile 的语义。
- 要实现线性同等读，起首我们简朴直接一些，是否可以直接从当前 Leader 节点读?
- 细心一想，这显然行不通，由于你无法确定这一刻当前的 "Leader" 真的是 Leader，好比在收集分区的环境下，它也许已经被颠覆王朝却不自知。
- 最简朴易懂的实现方法：同 “写” 哀求一样，“读” 哀求也走一遍 Raft 协议 (Raft Log)。
本图出自《Raft: A Consensus Algorithm for Replicated Logs》
这必然是可以的，但机能上显然不会太精彩，走 Raft Log 不只仅有日记落盘的开销，尚有日记复制的收集开销，其它尚有一堆的 Raft “读日记” 造成的磁盘占用开销，这在读比重很大的体系中凡是是无法被接管的。
- ReadIndex Read
- 这是 Raft 论文中提到的一种优化方案，详细来说：
- Leader 将本身当前 Log 的 commitIndex 记录到一个 Local 变量 ReadIndex 内里；
- 接着向 Followers 提倡一轮 heartbeat，假如半数以上节点返回了对应的 heartbeat response，那么 Leader 就可以或许确定此刻本身如故是 Leader (证明白本身是本身)；
- Leader 守候本身的状态机执行，直到 applyIndex 高出了 ReadIndex，这样就可以或许安详的提供 Linearizable Read 了，也不必管读的时候是否 Leader 已飘走 (思索：为什么比及 applyIndex 高出了 ReadIndex 就可以执行读哀求?)；
- Leader 执行 read 哀求，将功效返回给 Client。
- 通过ReadIndex，也可以很轻易在 Followers 节点上提供线性同等读：
- Follower 节点向 Leader 哀求最新的 ReadIndex；
- Leader 执行上眼前 3 步的进程(确定本身真的是 Leader)，并返回 ReadIndex 给 Follower；
- Follower 守候本身的 applyIndex 高出了 ReadIndex；
- Follower 执行 read 哀求，将功效返回给 Client。（SOFAJRaft 中可设置是否从 Follower 读取，默认不打开）
- ReadIndex小结：
- 对较量于走 Raft Log 的方法，ReadIndex 省去了磁盘的开销，能大幅度晋升吞吐，团结 SOFAJRaft 的 batch + pipeline ack + 全异步机制，三副本的环境下 Leader 读的吞吐可以靠近于 RPC 的吞吐上限；
- 耽误取决于大都派中最慢的一个 heartbeat response，理论上对付低落延时的结果不会很是明显。
- Lease Read
- Lease Read 与 ReadIndex 相同，但更进一步，不只省去了 Log，还省去了收集交互。它可以大幅晋升读的吞吐也能明显低落延时。
- 根基的思绪是 Leader 取一个比 election timeout 小的租期(最好小一个数目级)，在租约期内不会产生推举，这就确保了 Leader 不会变，以是可以跳过 ReadIndex 的第二步，也就低落了延时。可以看到 Lease Read 的正确性和时刻是挂钩的，因此时刻的实现至关重要，假如时钟漂移严峻，这套机制就会有题目。
- 实现方法：
- 按时 heartbeat 得到大都派相应，确认 Leader 的有用性 (在 SOFAJRaft 中默认的 heartbeat 隔断是 election timeout 的异常之一)；
- 在租约有用时刻内，可以以为当前 Leader 是 Raft Group 内的独一有用 Leader，，可忽略 ReadIndex 中的 heartbeat 确认步调(2)；
- Leader 守候本身的状态机执行，直到 applyIndex 高出了 ReadIndex，这样就可以或许安详的提供 Linearizable Read 了 。
（编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
