Raft协议

1. Raft协议介绍

Raft协议是一种分布式一致性算法，实现分为领导者选举和日志复制两个阶段。Raft协议的每个副本都会处于三种状态之一：

• 跟随者(Follower)：类似于选民，扮演完全被动的角色，它们等待接收通知并参与投票过程。
• 候选者(Candidate)：选举过程中提名自己为领导者，一旦选举成功，它就会成为新的领导者。
• 领导者(Leader)：处理客户端交互、日志复制等操作。Raft协议要求系统在任何时刻最多只能有一个领导者，正常工作期间只能由领导者和跟随者存在。

所有的请求(包括读)都会被转发到Leader节点处理，Leader处理读请求之前要先广播一次心跳，得到majority的反馈(为了避免网络分区读到的数据不是最新的问题)，采用的是CAP理论中CP方案。

2. 领导选举

Raft通过心跳机制来触发领导选举，如果follower在election timeout没有收到leader的心跳或者投票请求，则会将自己改成候选者，投自己一票，发起选举过程。候选者如果有超过半数的节点(包含自己)支持时，则更改自己为leader。否则将等待选举超时的时间后，继续发起新一轮的选举(如果等待过程中有新的term选举请求，则更改自己为follower)。
follower投票原则

• 在一个任期(term)内，单个节点最多只能投一票。
• 投票请求的term不低于自己的term，候选人知道的信息不能比自己少(通过log replication判断)
• 先到先得
  

3. 日志复制

Leader收到客户端发送的请求后，会进行以下操作：

• 创建一个新的日志条目，并将其追加到本地日志中
• Leader将这个日志条目广播到所有的follower
• 得到多数响应通过后，将命令应用到状态机
• 将结果返回给客户端
• leader通知follower提交日志。

需要注意：Raft协议只是保证已提交(指的时日志被复制到大多数节点)的数据不会被丢失，对于未提交的数据不一定会被丢失。
日志由按顺序进行编号实例组成，其除了包含具体的指令外，还包含当前任期信息和当前任期中指令的序号。

某个Leader选举成功后，不会提交前任Leader未提交的数据，而是通过提交当前任期(No-Op)的数据，顺带把之前任期未提交的数据提交了。

4. 日志压缩

在实际系统中，Log会无限制增长，导致占用太多磁盘空间，启动时间过长，将会导致系统不可用。Snapshot是Log Compaction的常用做法，将系统状的全部状态写入一个Snapshot中，并持久化到一个可靠存储系统中，完成Snapshot之后这个状态之前的Log就可以被删除。

5. 其它注意事项

• commitIndex只是一个位置，所谓的提交只是把index往前挪一位，并应用变更到当前状态机。新任期不会丢掉旧任期的日志(Append only)，只会在后面追加，当一个节点被选为leader后，会立刻生成一条no-op log广播并提交，就会把之前没应用的日志给应用到状态机。所以Raft协议只是保证已提交(指的时日志被复制到大多数节点)的数据不会被丢失，对于未提交的数据不一定会被丢失。
• Raft有两个很重要的随机超时时间：心跳超时-Leader周期性向Follower发送心跳（0.5ms -20ms)，如果follower在选举超时时间内都没收到心跳，则触发选举；选举超时-如果多个候选节点都没拿到多数节点的应答，需要重新选举，Raft引入随机选举超时时间(150ms-300ms)，避免选主活锁。
• snapshot的数据一定是apply到状态机(已提交)过的，节点重启之后，会先加载上一个snapshot，再加入Raft复制组。
• 预选举(PreVote)，Follower转为Candidate之前，先与集群节点通信，获取集群Leader是否存活的消息，如果当前有leader存活，则不从Follower转变为Candidate。