Raft算法笔记

Raft算法笔记

---

基本思路

   将系统中的nodes分类成三部分：leader（领导者）、follower（追随者）、candidate（候选者）。一方面，leader负责与client进行交互，比如说client发出对“x-1”的请求。另一方面，leader负责与follower进行交互，比如说leader将client的“x-1”的请求转发给其余所有的follower。也就是说，整个系统的状态的变更是由leader协调的。

---

一些个小细节

1. 选举
   说到leader，和现实生活中的leader一样，是有任期的，在这里我们称之为term。整个系统中，在一次term中只允许存在一个leader。leader通过向follower发送心跳来保持通讯（防止follower脱离自己的控制）。

   在Raft算法中，脱离leader“领导”的follower会成为candidate，然后以candidate的身份通知系统中的其他nodes他要参加leader的竞选，并向其他nodes索要选票。收到多数票的节点会成为leader。对于如何真正确定leader，大致分成以下两种：

   • 若先前脱离leader的原因是leader节点挂了，那竞选出来的新的leader就直接成为新一轮term的leader。
   • 若先前的原因是因为follower因为网络原因掉线了，最新的leader讲由保存着最全日志的备选leader担任。

   在投票过程中需要注意以下几点：

   • candidate日志里的内容不能比投票者少，否则得不到选票
   • 一段时间内没有收到majority投票，则保持candidate状态，重新发出选举

2. 日志同步
   当有了leader，系统应该进入对外工作期了。客户端的一切请求来发送到leader，leader来调度这些并发请求的顺序，并且保证leader与followers状态的一致性。raft中的做法是，将这些请求以及执行顺序告知followers。leader和followers以相同的顺序来执行这些请求，保证状态一致。

   在raft中，leader将客户端请求（command）封装到一个个log entry，将这些log entries复制（replicate）到所有follower节点，然后大家按相同顺序应用（apply）log entry中的command，则状态肯定是一致的。

   当系统（leader）收到一个来自客户端的写请求，到返回给客户端，整个过程从leader的视角来看会经历以下步骤：

   1. leader append log entry
   2. leader issue AppendEntries RPC in parallel
   3. leader wait for majority response
   4. leader apply entry to state machine
   5. leader reply to client
   6. leader notify follower apply log

   在上面的流程中，leader只需要日志被复制到大多数节点即可向客户端返回，一旦向客户端返回成功消息，那么系统就必须保证log（其实是log所包含的command）在任何异常的情况下都不会发生回滚。这里有两个词：commit（committed），apply(applied)，前者是指日志被复制到了大多数节点后日志的状态；而后者则是节点将日志应用到状态机，真正影响到节点状态。

3. 安全性
   raft协议会保证以下属性：

   • 选举安全性（election safety）
     一个节点某一任期内最多只能投一票，且只有获得majority投票的节点才会成为leader。这样就保证了一个任期内一定只有一个leader
   • 日志匹配（log matching）
     如果两个节点上的某个log entry的log index相同且term相同，那么在该index之前的所有log entry应该都是相同的。当出现了leader与follower不一致的情况，leader强制follower复制自己的lo

4. 参考
   感谢一文搞懂Raft算法