6.824 Raft
raft是一个分布式一致性协议，用于集群对一系列的提交达成共识。raft设计的出发点是简单易懂。节点分为Leader、follower、candidate，Leader负责处理数据的提交和对从节点的负责，尽可能避免复杂的操作。整个协议主要分为三个部分：Leader选举、日志复制、安全容错
Leader选举：
- 每一个节点记录了当前节点上次与其他节点正常通信的时间，如果超时未正常通信代表当前集群不存在Leader，自己变为candidate，对自己的Term+1，并给自己投一票，并发对其他节点发送requestVote投票请求，并带有Term和自己最新数据的任期、index。其他节点收到来自大于自己任期且数据不比自己旧的投票请求时，就对他投一票，更新自己的任期，每个节点在同一任期最多投一票。当候选者收到大于半数票，立即变为Leader，并给所有节点发送心跳，建立Leader地位。
- 所有日志读、写请求都是发送或转发给Leader。Leader通过心跳与follwer同步数据，使用两阶段提交，当超过半数节点确认收到日志，Leader本地提交日志，返回客户端并向其他节点发送提交信息，其他节点收到后在本地进行提交。
日志复制：
- Leader维护了每个follower节点复制的index与commitIndex，当有新数据提交，日志会随着心跳发送到各个节点上。当超过半数的节点复制成功，Leader本地提交并返回客户端，然后Leader向所有从节点发送提交信息，从节点在本地进行提交。
安全容错
- Leader必须有超过半数节点支持，旧Leader收到新任期消息立即变为follwer，避免了脑裂。
- 每个节点超时时间150~300m随机数，减少了多节点同时过期选主竞争失败的可能
- 数据提交需要超过半数节点的支持，Leader选举也需要超过半数节点支持，因此每个Leader必定携带已提交的数据，保证了数据提交的不丢失。
- 日志不同步问题：raft基于有限状态机的思想，所有相同初始状态的节点，按相同的顺序执行相同的操作，最终的状态是一致的。Leader维护了每一个follower的下一个待提交的index、已提交的index。在心跳时follwer发送当前同步位置的前一个日志的index和term，当follwer确认同步就可继续发送剩下的消息，当不同步时，Leader将同步位置减一，依次查找直到同步。
- Leader对之前任期的数据只复制不提交，当前任期有新日志时，在当前日志的担保下同时提交
- 数据集持久化，所有节点在提交数据前将本节点的状态信息序列化并持久化，宕机重启后加载之前的状态信息即可。
