这是我参与「第四届青训营 」笔记创作活动的第2天
我们想要将raft算法应用于本次分布式存储大作业中，因此调研学习了一些共识算法。
简介：
raft中每个节点可能在不同时间有不同的状态
- Leader
- Candidate
- Follower
raft中的活动
- Leader选举
- 日志复制
集群内部RPC消息类型
-
RequestVote：请求投票信息，用于选举Leader
-
AppendEntries：追加条目信息
- 用于向Follower执行日志复制
- 用于Leader与Follower之间的心跳检测
- 用于Leader与Follower之间的日志对齐
超时机制（在Raft中超时后的下一次操作的时间都是随机的 这样做可以大概率规避多节点同时发起选举的情况发生）：
- Follower等待心跳超时
- 等待选举投票超时
投票规则：
- term大的成员拒绝给term小的RequestVote消息（Leader任期高的成员不会投票给Leader任期小的RequestVote消息）
- 最后一条日志项编号（uncommitted）大的拒绝投票给最后一条日志项编号（uncommitted）小的成员（日志编号大的成员会拒绝投票给日志编号小的成员），这一操作可以保证新选举出的Leader有最完整的数据
- 每个成员，一届term任期内只投出一张选票，先来先获得选票
日志复制
日志项（存放提案） Raft所有的协商过程都是以日志项的形式进行协商
日志项只能由Leader流入到Follower，Follower不能以任何形式覆盖掉Leader的日志项
日志索引，全局唯一且连续递增的整数编号，用于标识每个日志项在日志列表中所处的位置。其连续性不限于多个Leader周期之间
- 日志索引是连续的当新Leader晋升的时候，不需要考虑新Leader的本地日志中是否存在空洞的日志，比如在Paxos中，新Leader晋升后，它就要先获取到集群中所有其他成员的最大提案，然后以最大的提案来补充它所缺少的那些提案
- 通过最大的日志项，Raft就能比较两个成员之间的差异数据
