分布式一致性算法最著名的应该是 Paxos，1990年提出，google的Chubby Lock服务就是使用的Paxos

之后的一些一致性算法基本都是在Paxos思路上的调整，例如 ZooKeeper的 ZAB

但Paxos算法一直被认为比较繁杂，很不好理解，大家对其调整优化，就是因为他的复杂

2013年，斯坦福的两个人以易懂为目标，设计了一致性算法 Raft，现在已经被广泛应用，比较有名的是etcd，Google的Kubernetes就使用了etcd作为他的服务发现框架

什么是分布式一致？

在单节点环境中，client向node发送一个值，很容易就达成一致了



但当我们有多个node时，我们应该如何做，才能实现一致性呢？



这就是分布式一致性问题，Raft就是用来解决此问题的
 

Raft的思路

每个node都会处于以下3个状态之一：

（1）Follower 跟随者

（2）Candidate 候选人

（3）Leader *



所有node开始时都是follower



当follower没有收到leader的心跳时，他就会申请成为candidate，然后向其他node发送请求，说“我要成为Leader，请给我投票”



当candidate收到大多数node的同意后，就变为了Leader，以后对于系统的修改操作，都必须经过Leader



例如client要发送消息，会先发给leader，leader会把这个操作记录到自己的日志

注意，是记录到日志，并没有实际修改node中的值



leader把这条操作记录发送给各个follower，follower收到后，也保存到自己的日志中



follower收到操作记录后，向leader发送消息，说自己安排好了

leader收到大多数的回馈后，就把这条记录进行提交，真正修改了node中的值



leader执行提交以后，就通知各个follower，“我已经提交了，你们可以更新了”



现在，系统就达成了一致的状态

这个过程叫做 Log Replication 日志复制，是Raft的核心之一，还有选举leader过程也是核心，就不细说了

如果对Raft算法有兴趣，强烈建议看一下他的动态演示

地址 http://thesecretlivesofdata.com/raft/

非常易懂，上面介绍的日志复制过程就是整理自这个演示，里面还有很多其他内容，看过后就会对Raft有了整体认识

还有Raft的详细说明文档，中文的，很好的资料，地址

https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md