持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第29天，点击查看活动详情
介绍
Raft算法是一个共识算法，即多个节点对某个事情达成一致的算法，它被用于在分布式情况下，确保强一致性、高可用等情况。
例如etcd、Consul、Tidb等框架都使用了Raft算法来实现相关功能。
在Raft算法中主要解决leader election和log replication这两个问题。
leader election
Raft算法将节点角色分为以下三种
- leader：接受客户端的请求，并向对应follower同步请求，当多个follower都接受到该请求后，都将该请求commit。
- follower：接受并持久化leader的请求日志，随后等待leader的通知进行commit。
- candidate：选举leader过程中的临时角色。
一开始所有的节点启动时都是follower角色，如果一段时间内都没有收到leader的心跳，则从follower转换为candidate角色，发起leader选举。
leader选举中一个节点大致有三种情况：
- 当一个节点收到大多数节点的票后，并且该节点的数据也比较新，就被选举为leader。
- 收到其他节点被当选为leader的消息，那么当前节点就变为follower角色。
- 如果一直没有节点当选leader，就重新进行leader选举。
Raft算法保证同一个term内，只有一个leader当选。
当选举出leader后，leader会定期向follower发送心跳信息来保持状态。如果follower没有收到心跳连接后，就重新开始选举。
leader election还有一些约束：
- 同一个term中，最多只能投一票。
- 选举人的数据信息，例如term，log index需要比自己节点拥有的多。
replicated state machines
共识算法通常是基于replicated state machines来实现的，即各个节点都用确定的函数去处理相同的输入值，这样就都能得出相同的结果。
相同状态+相同的输入=相同的输出
log replication
Raft算法也是基于replicated state machines这一思想来实现的。
当leader接受到客户端的请求信息后，会将请求信息封装为日志条目（包含创建时的term和请求的命令）加入到自己的日志中，随后将该日志条目发送到follower们。
大多数follower都收到该日志条目并存储到对应的日志中后，leader将会将该请求应用到状态机中，并向客户端返回相关结果。
Raft算法对于log replication会保证两点：
If two entries in different logs have the same index and term, then they store the same command.
If two entries in different logs have the same index and term, then the logs are identical in all preceding entries.
即不同的日志中有两个日志条目的term和索引相同，则它们存储的请求命令是相同的，同时它们之前的命令也都相同。
log replication同样也有些约束：
- 当一个日志条目被复制到大多数节点后，直接进行
commited，保证不会有回滚操作。 - leader一定包含最新的日志条目信息。
