Raft算法

https://zhuanlan.zhihu.com/p/32052223

https://cloud.tencent.com/developer/news/221746

Raft动画演示：     http://thesecretlivesofdata.com/raft/

关键字：
AppendEntries RPC：（term_index_command）+上一条目(term_index)
RequestVote RPC：vote信息 + 自己的最后一条日志（term_index）
Snapshot：日志元数据+最后一条已提交的 log entry（term_index)

• 五大问题

1. leader选举、
2. 日志同步、
3. 成员变更、
4. 日志压缩、
5. 安全性。

先选领导，再干活

• 三个角色（或者说一个node的三种状态）

领导者（Leader）：皇帝
跟从者（Follower）：大臣
候选人（Candidate）：太子

• 三种消息

RequestVote RPC（选举消息）、
AppendEntries RPC（日志消息）、
InstalledSnapshot RPC

• Candidate参与leader的三种选举结果

成功、失败、平局

• 日志同步的三次握手

角色	操作	角色
leader	>>>>>>同步到	follower
leader	<<<<<<反馈同步成功,leader commit	follower
leader	>>>>>>通知follower，leader已经commit	follower

• leader选举的两个timeout 

election-timeout：a follower 等待election-timeout时间后，变成 a candidate，election-timeout 随机 [150ms ,300ms]。

1. 投票给自己，
2. 发起其他node的投票请求RequestVote RPC，
3. 重置选举定时器，
4. 开启一个新的term。

heartbeat-timeout：两次heartbeat时间间隔。

Follower接收到Leader的心跳包AppendEntries RPC的同时，也重置选举定时器。
The leader begins sending out Append Entries messages to its followers.
These messages are sent in intervals specified by the heartbeat timeout.
Followers then respond to each Append Entries message.
This election term will continue until a follower stops receiving heartbeats and becomes a candidate.

与leader日志不一致时的霸权统治

若follower日志少，则leader发送的AppendEntries RPC递减，直到找到日志一致的地方；
若follower日志多，覆盖之。

Leader选举 

1. leader：独裁集权，任期制，类似于外交官。
2. Follower：将其当前term+1，然后转换为Candidate
3. candinate：先自己选自己，脸皮厚

日志同步 

1. 新日志条目组成：（term, index, command）
   a.任期（term）
   b.有序编号（log index）
   c.命令
2. 一个 AppendEntries RPC，包含两部分：
        a.新日志条目（term, index, command）
        b.上一条目的(term和index)。
   如果Follower在它的日志中，没有找到上一条目的log index和term都相同的日志，会拒绝新的日志条目
3. Candidate发送的RequestVote RPC包含：
       a.vote信息
       b.自己的最后一条日志的term和log index。
   其他节点收到投票请求时，如果发现自己的日志比请求中携带的更新，则拒绝投票。
   日志比较的原则：
       a.如果本地的最后一条log entry的term更大，则term大的更新，
       b.如果term一样大，则log index更大的更新。
4. Leader会从后往前试，每次AppendEntries失败后，尝试前一个日志条目，直到成功找到每个Follower的日志一致位点，然后向后逐条覆盖Followers在该位置之后的条目。
5. Leader通过强制Followers复制它的日志，来处理日志的不一致，Followers上的不一致的日志会被Leader的日志覆盖。

安全性  

1. 拥有最新的已提交的log entry的Follower才有资格成为Leader。
   candinate把自己的最新从leader获取并提交的日志的（term，index）放到RequestVote RPC中。
   正常情况下，大多数节点都已经包含该 （term，index）。
   匹配则投票给该candinate，否则，拒绝。
2. Leader只能推进commit index，来提交当前term的，已经复制到大多数服务器上的日志，
   旧term日志的提交，要等到提交当前term的日志来间接提交（log index 小于 commit index的日志被间接提交）

日志压缩 

1. 每个副本独立的对自己的系统状态进行snapshot，并且只能对已经提交的日志记录进行snapshot。
2. snapshot之前的日志都可以丢弃。
3. Snapshot中包含以下内容：
   a.日志元数据
   b.最后一条已提交的 log entry的term和index。

成员变更

https://blog.csdn.net/sky302761277/article/details/85318791

同行