概述
raft算法是一种分布式共识算法,主要解决的多节点共识一致性问题。
举个例子,当我们去饭店吃饭时,怎么保证多个服务员的共识,而不出现一个客人来多个服务员涌上去服务,另一个客人来却没有一个服务员理他的尴尬局面;
一、节点角色
在raft算法中,节点有三种角色:
1、leader:领导,接受客户端请求,并向follower同步请求日志
2、follower:候选人,接受leader同步的日志
3、candidate:候选者,选举过程中的临时角色
二、选举过程
初始状态下,所有节点都为follower,当follower节点未收到leader节点的日志或者心跳,此时follower节点会变candidate状态,并触发选举操作:
1、候选人节点向其他节点发起投票通知
2、若候选人节点收到了大多数节点的投票,那么它就会升级成为leader节点
Raft算法将时间分为一个个的任期(term),每一个term的开始都是Leader选举。在成功选举Leader之后,Leader会在整个term内管理整个集群。如果Leader选举失败,该term就会因为没有Leader而结束
此时外部的请求会先下发到leader节点上,在通过leader节点两段式提交进行同步到follow节点上
三、leader节点与follower节点数据同步
两段式提交过程:
1、leader节点先将数据提交至follower节点
2、leader节点统计到了大多数节点已经写入完成,将请求本地置为提交状态,并响应客户
3、leader节点通知大多数follower节点将数据置为提交状态
四、leader节点宕机了,怎么办?
如果leader节点与follower节点保存心跳连接,如果leader节点宕机,此时未收到心跳包的follower节点会在150ms - 300ms之间变成选举人角色,并触发选举流程
五、如果系统中有多个选举人节点怎么办?
按照刚才的流程,同一系统中可能出现,多个选举人节点,但是如果其中已经有一个选举人已经当选成leader节点,那么剩下的选举人节点该怎么办呢?
当选举人节点收到新的leader节点通知时,会自动退化为follower节点
问题:
若系统中出现网络分割,导致多个节点隔离,多地分别有自己任期内的Leader节点,当网络恢复,多节点间该如何共识呢?
提示:任期term
参考:
http://thesecretlivesofdata.com/raft/