目标
Raft是一种共识算法，为了解决的问题是在分布式系统中存在的一致性问题，它是一种去中心化，强一致的算法。
概览
为了完成上述目标，Raft的做法是将该问题分解成多个小问题：leader election， log replication，safety，membership changes；并且将节点的状态简化:leader, follower, candidate。
leader election（领导者选举）
所有节点启动时都是follower状态；在一段时间内如果没有收到来自leader的心跳，从follower切换到candidate，发起选举；如果收到majority的造成票（含自己的一票）则切换到leader状态；如果发现其他节点比自己更新，则主动切换到follower。
term
term是任期，以选举开始为term开始。如果没有选举出leader就结束了，然后会发起新的选举，并且term+1。
在单个任期内，每个节点最多只能投出一票
log replication
log replication保证了多个节点的强一致性。
复制状态机
相同的初识状态 + 相同的输入 = 相同的结束状态
这里保证的是不同的节点将以相同的确定的输入进行更新，而不会使用不确定的值进行更新，例如当地时间等。
日志同步
在raft中，leader将客户端请求（command）封装到一个个log entry，将这些log entries复制（replicate）到所有follower节点，然后大家按相同顺序应用（apply）log entry中的command，则状态肯定是一致的。
当leader节点收到写请求后会append log，并将该更新内容随着心跳请求发送给所有follower，当收到majority个回复后会apply这个entry，并回复client成功，最后通知follower去apply 这个entry。
这里日志的提交过程有点类似两阶段提交(2PC)，不过与2PC的区别在于，leader只需要大多数（majority）节点的回复即可，这样只要超过一半节点处于工作状态则系统就是可用的。
logs由顺序编号的log entry组成 ，每个log entry除了包含command，还包含产生该log entry时的leader term。并且raft其实不是一种强一致，而是保证最终一致，leader会不断尝试给follower发log entries，直到所有节点的log entries都相同。
raft的log保证以下两点：
如果不同日志中的两个条目有着相同的索引和任期号，则它们所存储的命令是相同的。
如果不同日志中的两个条目有着相同的索引和任期号，则它们之前的所有条目都是完全一样的。
leader和follower的日志状态
从上面可以看出，一个Follower可能会丢失掉Leader上的一些条目，也有可能包含一些Leader没有的条目，也有可能两者都会发生。丢失的或者多出来的条目可能会持续多个任期
拥有最新的已提交的log entry的Follower才有资格成为leader
Leader只能推进commit index来提交当前term的已经复制到大多数服务器上的日志，旧term日志的提交要等到提交当前term的日志来间接提交（log index 小于 commit index的日志被间接提交）。
Election safety
raft的选举安全性是为了保证系统中只有一个leader，从而防止了脑裂。
保证手段：1.一个节点某一任期内最多只能投一票；2.只有获得majority投票的节点才会成为leader。
