非拜占庭容错共识算法

目录

一、Raft 算法

二、KRaft 算法

参考文献

---

一、Raft 算法

三种角色不同的节点：跟随者（follower）、候选者（candidate）、领导者（leader）

两个阶段：

1、领导者选举阶段：

最初所有节点都为 follower 节点，随机超时发生后，若没接收到来自高层（leader | candidate）的消息；follower 节点转变为 candidate 节点。获取大多数票的 candidate 节点转变为 leader 节点（最先完成随机超时时间的高任期candidate节点可以获取follower节点的唯一投票）若未选出 leader节点，经随机超时后，重新触发选举。

2、日志同步(达成共识)

leader 节点将客户端的请求封装到日志条目中，并将 leader 节点的心跳与日志一同广播到给其余节点，整个广播过程是单向的( leader 节点——>其他节点)，

当 leader 节点完成大多数节点的日志同步，则可以向客户端返回共识达成。

二、KRaft 算法

文献【1】提出的基于 Raft 共识算法的改进，基于双层 Kademlia 协议对 leader 节点的产生过程，以及日志同步时的效率进行了优化。

三种角色不同的节点：跟随者（follower）、候选者（candidate）、领导者（leader）

两个阶段：

1、领导者选举阶段：

首次随机选取 leader节点。利用双层的 Kademlia 协议动态维护Ｋ桶，保证了Ｋ桶内的节点是当前节点时延最低的Ｋ个节点。而这 K  个节点则为 candidate 节点。当 leader 节点宕机时，则由 K 桶内的 K 个 candidate 节点选出新的 leader节点。（leader节点必须保证时时延最低的节点）

2、日志同步(达成共识)

与 Raft 算法不同的是，KRaft 算法大日志同步分两步走：

①leader 节点以单节点多线程的方式发送日志给 candidate 节点，所有 candidate 节点收到日志后，第一步完成。若有 candidate 节点未收到，则回滚。

②candidate 节点通过并行发送日志给 follower 节点；提高了效率。

（follower 节点设置了确认收到日志的布尔类型标志位，避免日志错乱）

当leader节点收到超过一半的日志确认回复后，可以向客户端返回共识达成

参考文献

[1] 王日宏,周 航,徐泉清,张立锋.用于联盟链的非拜占庭容错共识算法 [J].计算机科学,2021, 48 (9): 317-323.