Raft 协议学习笔记

一致性

Raft 是一种分布式一致性协议。何为一致性（consensus）？它是开发具有容错性（fault-tolerant）的分布式系统的基础。在一个具有一致性性质的分布式系统里面，同一时刻所有节点对存储在系统中的某个 key 都具有相同的结果。也就是说其对共享的存储保持一致。
通常情况下，如果系统中的大部分节点能够正常工作，那么整个系统就是可服务的，当下线的节点占大部分时，整个系统就会宕机。
一致性协议就是用来保证这种情况的。用来保证及时小部分节点（副本）宕机的情况下，整个系统仍然能正常服务。一致性协议一半基于 replacated state mechine， 即所有节点从同一个 state 出发，经过一些列的 log 操作，最终到达同样的 state。

系统组件

状态机: 当我们说一致性的时候，实际就是在说要保证这个状态机的一致性。状态机会从log里面取出所有的命令，然后执行一遍，得到的结果就是我们对外提供的保证了一致性的数据
Log: 保存了所有修改记录
一致性模块: 一致性模块算法就是用来保证写入的log的命令的一致性，这也是raft算法核心内容

Raft 协议

Raft 协议的主要内容：Leader election， Log Replication， Safety

Leader Election

Raft 协议的每个副本会处于三个状态之一： Leader， Follower， Candidate。

Leader：所有请求的处理者，Leader 副本接受 client 的更新请求，本地处理后再同步至多个其他副本；
Follower：请求的被动更新者，从 Leader 接受更新请求，然后写入本地日志文件
Candidate：如果 Follower 副本在一段时间内没有收到 Leader 副本的心跳，则判断Leader 可能已经故障，此时启动选主过程，此时副本会变成 Candidate 状态，直到选主结束。

Raft 协议里有 term 的概念，起始状态时为 term0，每隔一段时间，变为新的 term。每个副本的时间时随机的，每段 term 一开始就重新选主：

1. Follower 将自己维护的 current_term_id 加 1，
2. Follower 将状态改成 Candidate，
3. 发送 RequestVoteRPC（带有 term_id 消息）给其他所有server。

选主过程会有三种结果：

• 自己选成了主
  当 Follower 收到 majority 的投票后，将状态切换成 Leaader，并且定期给其它的所有server发心跳消息（不带 log 的 AppendEntriesRPC）以告诉对方自己是current_term_id所标识的term的leader。每个term最多只有一个leader，term id作为logical clock，在每个RPC消息中都会带上，用于检测过期的消息。当一个server收到的RPC消息中的rpc_term_id比本地的current_term_id更大时，就更新current_term_id为rpc_term_id，并且如果当前state为leader或者candidate时，将自己的状态切成follower。如果rpc_term_id比本地的current_term_id更小，则拒绝这个RPC消息。

• 别人成为了主。
  如1所述，当Candidator在等待投票的过程中，收到了大于或者等于本地的current_term_id的声明对方是leader的AppendEntriesRPC时，则将自己的state切成follower，并且更新本地的current_term_id。

• 没有选出主。
  当投票被瓜分，没有任何一个candidate收到了majority的vote时，没有leader被选出。这种情况下，每个candidate等待的投票的过程就超时了，接着candidates都会将本地的current_term_id再加1，发起RequestVoteRPC进行新一轮的leader election。

投票策略：

每个节点只会给每个term投一票，具体的是否同意和后续的Safety有关。
当投票被瓜分后，所有的candidate同时超时，然后有可能进入新一轮的票数被瓜分，为了避免这个问题，Raft采用一种很简单的方法：每个Candidate的election timeout从150ms-300ms之间随机取，那么第一个超时的Candidate就可以发起新一轮的leader election，带着最大的term_id给其它所有server发送RequestVoteRPC消息，从而自己成为leader，然后给他们发送心跳消息以告诉他们自己是主。