分布式一致性算法 Raft

分布式一致性算法最著名的应该是 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