这是我参与「第四届青训营 」笔记创作活动的的第12天
共识算法案例：Raft
Paxos
困难，且没有liveness
被认为是分布式共识算法的根本，其他都是其变种，但是 paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。
RSM 复制状态机
commit index， log， 状态机
Raft 角色
- Follower：完全被动，不能发送任何请求, 只接受并响应来自 leader 和 candidate 的 message, node启动后的初始状态必须是 follower。
- Leader：处理所有来自客户端的请求，以及复制 log 到所有 followers。
- Candidate：用来竞选一个新 leader (candidate 由 follower 触发超时而来)。
Raft 日志复制
当选出 leader 后，它会开始接受客户端请求，每个请求会带有一个指令，可以被回放到状态机中。leader 把指令追加成一个 log entry，然后通过 AppendEntries RPC 并行的发送给其他的 follower。当改 log entry 被多数派 follower 复制后(leader 将这种日志视为安全的, committed entry)，leader 会把该 log entry 回放到状态机中，然后把结果返回给客户端。
Raft 从节点失效
对于失效的节点，leader不断询问发送缺失的Log，知道被接受
Raft 主节点失效
Leader定期发送内容
从节点有一段时间没有收到则成为candidate
其余节点进行投票
- 投票原则：
- 一个任期内，follower只会投票一次票，且先来先得；
- Candidate存储的日志至少要和follower一样新；
- 只有获得超过半数投票才有机会成为leader；
Raft 安全性 - 跨Term
- Raft选举保证只有最新的才能当选
- 选举需要多数派投票， 而Commited log也在多数派中
- 新Leader一定持有commited log，且Leader永远不会overwrite log
Raft 安全性验证
- 使用TLA+进行验证
- 形式验证
