Raft是一个共识算法。比如比特币之类的加密货币，就需要共识算法。Spring Cloud 的注册中心的解决方案 Consul 也用到了Raft 协议。
Raft的核心思想： 先到先得，少数服从多数。
只要存在多个副本的问题,就存在保证数据一致性问题，要保证所有的节点达成数据一致性，就必须通过复制的方式。多个节点，就需要选举出一个Leader。
数据一致性需要两个步骤： 领导选举，数据复制。
Raft算法的大致步骤- 分布式环境中节点状态：Follower、Leader(实线外框)、Candidate(虚线外框)。
- 一开始所有的节点都是 Follower 状态。如果 Follower 节点连接不到 Leader（Leader挂了),他就会成为 Candidate。Candidate 请求其他节点的投票，其他的节点会投给他。如果他得到了大多数节点的投票，他就成为了主节点。这个过程就叫做 Leader Election。
- 现在所有的写操作需要在 Leader 节点上发生。Leader 会记录操作日志。没有同步到其他 Follower 节点的日志，状态是 uncommitted。等到超过半数的 Follower 同步了这条记录，日志状态就会变成 committed。Leader 会通知所有的 Follower
日志已经 committed，这个时候所有的节点就达成了一致。这个过程叫 Log Replication。 - 在 Raft 协议里面，选举的时候有两个超时时间。第一个交 election timeout。也就是说，为了防止同一时间大量节点参与选举，每个节点在变成 Candidate 之前需要随机等待一段时间，时间范围是 150ms and 300ms 之间。第一个变成 Candidate 的节点会先发起投票。他会先投给自己，然后请求其他节点投票。（Request Vote）
- 如果还没有收到投票结果，又到了超时时间，需要重置超时时间。只要有大部分节点投给了一个节点，他就会变成Leader。
- 成为 Leader 之后，他会发消息让来同步数据，发消息的间隔是由 heartbeat timeout 来控制的。Followers 会回复同步数据的消息。
- 只要 Followers 收到了同步数据的消息，代表 Leader 没挂，他们就会清除 heartbeat timeout 的计时。
- 但是一旦 Followers 在 heart timeout 时间之内没有收到 Append Entries 消息，他就会认为 Leader 挂了，开始让其它节点投票，成为新的 Leader。
- 必须超过半数以上节点投票，保证只有一个 Leader 被选出来。
10.如果两个 Follower 同时变成了 Candidate，他就会出现分割投票。比如有两个节点同时变成 Candidate，而且各自有一个投票请求先达到了其他的节点。加上他们给自己的投票，每个 Candidate 手上有 2 票。但是，因为他们的 election timeout 不同，在发起新的一轮选举的时候，有一个节点收到了更多的投票，所以它变成了 Leader。
Sentinle 的 Raft 算法和 Raft 有点不同:
- master 客观下线触发选举，而不是过了 election timeout 时间开始选举。
- Leader 并不会把自己成为 Leader 的消息发送给其他 Sentinel。其他 Sentinel 等待 Leader 从 Slave 选出 master 后，检测到新的 master 正常工作后，就会去掉客观下线的标识，从而不需要进入故障转移流程。
