非拜占庭容错共识算法

目录

一、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桶,保证了K桶内的节点是当前节点时延最低的K个节点。而这 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. 
 

猜你喜欢

转载自blog.csdn.net/m0_47233175/article/details/123712322