演示地址：http://thesecretlivesofdata.com/raft/
什么是分布式一致性？
假设我们有一个单节点系统，对于本例，可以将我们的节点视为存储单个值的数据库服务器。我们有一个客户端可以发送值给服务器。
只有一个节点，这个值得一致性很容易实现。
但是如果这里有很多个节点呢？这就是分布式一致性的问题
Leader选举
Raft就是分布式一致性的一个实现方案。接下来我们从上帝视角来看看它是怎么运作的。
一个节点有三个状态：Follower（从节点）、Candidate（候选节点）、 Leader（主节点），
所有的节点初始状态都是Follower状态，如果Follower节点没有接收到Leader节点的心跳信息，Follower节点就可以变成一个Candidate节点
Candidate节点向其他节点发起选票请求
其他节点将会响应他的选票
Candidate节点如果获取到大多节点的选票，则会变成leader节点。这个过程叫做Leader选举。
日志同步
现在所有对系统的修改都要经过这个Leader节点。每一次修改都会以日志对象的形式添加在日志里面。现在日志对象没有提交，所以其他节点还没有更新这个值。
为了提交这个日志，主节点首先将其拷贝到Follower节点，
然后Leader节点会一直等待，知道大多数节点已经把日志记录下来，现在日志被提交到了其他节点上，这个时候才把Leader节点的值修改成5.
然后Leader节点把已经提交日志的消息告诉Follower节点，Follower节点把值更新为5，现在整个集群就达到了一致性。这个过程叫日志复制。
选举超时&心跳超时
在Raft中有两个超时配置来控制选举，
选举超时：是Follower节点成为Candidate节点的超时时间，选举超时时间被随机分配到150ms和300ms之间，在选举超时时间结束后，节点会变成一个Candidate节点，并开始新一轮的选举，
并向其他节点发起选举投票请求，
如果接收到选取请求的节点在当届选举期没有投票，则会将选票投递给候选节点，并且重置他们的选举超时时间。
一旦候选节点获取到多数选票时，候选节点则会变成Leader节点。
心跳超时：Leader节点开始发送消息给他的Follower节点，这些消息以心跳超时时间为间隔的发送给Follower节点，Follower节点响应每一次消息，这次选举任期将持续到有一个Follower节点收不到心跳消息而变成下一个候选节点为止。
当我们把节点A停掉后，进入下一轮的选票，并且节点C成为了新的Leader
分裂投票
要求获取票数多的成为Leader是为了保证每一届只有一位Leader，如果两个节点同时成为Leader，则会发送分裂投票，看下面这个例子：
两个节点同时开启了下一轮投票，
并且每个节点的选举请求都先到达一个Follower节点
现在两个候选人都得到两票选票，且在选举期间无法得到更多的选票，
这个时候则会等待开启新一轮的选举，
节点A在新的一轮中获取到更多选票，成为了新的Leader
日志同步的一致性
一旦产生了新的Leader节点，我们需要拷贝所有的修改日志到所有的节点上去，这是在心跳信息上加附加信息实现的，让我们看看他的全过程。
首先客户端发送一个改变给Leader节点，这个改变会记录在Leader的日志中，
在下一次心跳的时候，这个改变日志会被发送到Follower节点，
当大部分Follower节点反馈收到日志后，这个改变日志将提交，并响应客户端。随后把提交的消息发送给Follower节点，达到分布式一致性。
随后客户端又想Leader节点发送了一个ADD2的请求，Leader以相同的流程把ADD2的日志消息同步到Follower节点，系统的值被更新成7。
Rate甚至可以在面对网络分区的时候达到一致性，在A,B节点和C,D,E节点之间添加物理隔离
因为我们的隔离，现在在不同的选举届产生了两个不同的Leader节点，
让我们添加客户端去更新所有的Leader节点，
节点C因为获取了大多节点的更新响应，日志得以提交成功，
当我们撤去隔离后，节点B看到届数更高的节点C，从而退出变成Follower节点，A,B节点的日志都将进行回滚，并且获取C节点最新的日志。现在整个集群的日志是一致性的。
