共识算法（三）—— Raft（分布式一致性算法）

Raft简介

Raft替代了paxos（太复杂），并提供了一种在计算系统集群中分布状态机的通用方法，确保集群中的每个节点都同意一系列相同的状态转换，也就是说，它在提供的计算机集群分布状态机时，有个别或者多个状态机down掉了，从而使其状态不统一并影响了consensus一致性，继而影响了整个系统的运行，而Raft算法就可以解决这个问题，它允许有down机，从而可以避免影响整个系统的运行。一个Raft集群包含若干个服务器节点，通常是5个，这允许整个系统容忍2个节点的失效，每个节点处于一下三种状态之一：

1. follower（跟随者） ：所有节点都以 follower 的状态开始。如果没收到 leader 消息则会变成 candidate 状态。

2. candidate（候选人）：会向其他节点“拉选票”，如果得到大部分的票则成为 leader，这个过程就叫做 Leader 选举(Leader Election)。

3. leader（领导者）：所有对系统的修改都会先经过 leader 。

Raft分为两个阶段

1. 第一个阶段：选举：从集群中选出一个合适的节点作为leader。即计算机集群开始运行时，每个节点都是follower状态，当term周期过后，就会有folloer节点成为conmidited节点，并给自己投一票，然后将自己通过RPC广播出去，让其他的节点投票给自己，其他节点收到它的广播后，首先会检查自己的票是否已经投出，如果没有投出或者votefor为null，则就会检查竞选节点的日志信息是否比当前节点更全，如果不全，则拒绝投票，反之则投给它，当自己的票属于一大半时，则竞选通过，转为leader，然后再将自己的信息同步给其他节点。
2. 日志同步：1.选举出的leader接收客户端请求，将其转为raft日志。2.Leader将日志同步到其他节点，当大多数节点已经同步完毕日志后，日志的状态就会变为conmmited，从而这些日志将不会被篡改。3.当leader节点down掉后，会重新执行第一阶段。

raft日志冲突：

如果follower节点的数据与leader节点数据发生冲突，则同步leader节点的数据，删除自己本身的脏数据。