Raft将共识问题分解三个子问题：
- Leader election 领导选举：有且仅有一个leader节点，如果leader宕机，通过选举机制选出新的leader；
- Log replication 日志复制：leader从客户端接收数据更新/删除请求，然后日志复制到follower节点，从而保证集群数据的一致性；
- Safety 安全性：通过安全性原则来处理一些特殊case，保证Raft算法的完备性；
所以，Raft算法核心流程可以归纳为：
- 首先选出leader，leader节点负责接收外部的数据更新/删除请求；
- 然后日志复制到其他follower节点，同时通过安全性的准则来保证整个日志复制的一致性；
- 如果遇到leader故障，followers会重新发起选举出新的leader；
Raft规定：只有拥有最新提交日志的follower节点才有资格成为leader节点。具体做法：candidate竞选投票时会携带最新提交日志，follower会用自己的日志和candidate做比较。
因为日志提交需要超过半数的节点同意，所以针对日志同步落后的follower（还未同步完全部日志，导致落后于其他节点）在竞选leader的时候，肯定拿不到超过半数的票，也只有那些完成同步的才有可能获取超过半数的票成为leader。
日志更新判断方式是比较日志项的term和index：
- 如果TermId不同，选择TermId最大的；
- 如果TermId相同，选择Index最大的；
Raft对日志提交有额外安全机制：leader只能提交当前任期Term的日志，旧任期Term（以前的数据）只能通过当前任期Term的数据提交来间接完成提交。简单的说，日志提交有两个条件需要满足：
- 当前任期；
- 复制结点超过半数；
Raft在日志项提交上增加了限制：只有当前任期且复制超过半数的日志才可以提交。