raft协议-理解与探索

Raft原理

在Raft中，每个结点会处于下面三种状态中的一种：

• follower：所有结点都以follower的状态开始。如果没收到leader消息则会变成candidate状态
• candidate：会向其他结点“拉选票”，如果得到大部分的票则成为leader。这个过程就叫做Leader选举(Leader Election)
• leader：所有对系统的修改都会先经过leader。每个修改都会写一条日志(log entry)。leader收到修改请求后的过程如下，这个过程叫做日志复制(Log Replication)： 
  1. 复制日志到所有follower结点(replicate entry)
  2. 大部分结点响应时才提交日志
  3. 通知所有follower结点日志已提交
  4. 所有follower也提交日志
  5. 现在整个系统处于一致的状态

Leader Election

当follower在选举超时时间(election timeout)内未收到leader的心跳消息(append entries)，则变成candidate状态。为了避免选举冲突，这个超时时间是一个150~300ms之间的随机数，每个follower都有自己的心跳时间。

成为candidate的结点发起新的选举期(election term)去“拉选票”：

1. 重置自己的计时器
2. 投自己一票
3. 发送 Request Vote消息

 

个人总结结合日常生活：

1、选举：假设我们是一个工作小组，有一些人，刚刚进入这个小组的时候我们都是平级级的，这时老板会挑选出一个精炼的人作为领导，这个时候这个人就会成功Leader。

2、工作：小组工作时，为了达到工作一致，所有产品的需求都是经过Leader然后再下发到其他下属，所有下属完成了工作也都要经过Leader的审核最后交到产品部门，在此过程中主要是由Leader跟产品部门打交道，由Leader统一安排工作；保持大家的工作不会乱。

3、投屏选举：突然有一天Leader辞职不干了，一群人没了Leader的安排不知道怎么进行，产品也不知道找谁对接，这时小组进行投票决定重新挑选一个精炼的人做Leader，当然是投票最多的人最终成为小组的Leader，最终重新由Leader安排工作和产品的对接。

 

动态演示地址 http://thesecretlivesofdata.com/raft/

可视化演示地址：https://raft.github.io/