图解分布式一致性算法

今天的文章，咱们会通过图的方式，来深入学习和理解分布式一致性的实现原理。

开始的时候，咱们先来灵魂一问：什么是分布式一致性?

• 你的应用是单节点吗?
• 你的系统用户多吗、支持扩容吗?
• 你的系统扩容后数据能保持一致吗?
• 你的系统是否使用Raft、Paxos?
• ……

是否理解都没关系，后面开始咱们的例子，通过图的方式，来描述一致性的工作原理。

一、前奏

假设咱们有个系统。是个单节点的系统，只部署在一个实例上。可以把它理解成一个数据库服务(Database Server)，实例上只有一个数据X，咱们后续的故事都是要围绕操作变更X的值开展的。

咱们还有个客户端(Client)，它要向节点 (Server) 写数据，这个时候应用代码写起来也简单，这个数据的一致性很容易保证。

写请求执行后，客户端和服务端的X数据都变成了8。

在用户量少的时候，还天天操心啥时候来个百万千万用户，等用户稍微一多起来才发现，原来的一个实例扛不住了。这个时候为了支持更多用户访问，又扩容出来了更多的实例。

那么这下问题来了，当我们有多个实例节点间的时候，客户端向其中一个节点写了数据，如何再同步给其他节点呢?怎样保证节点间数据的一致性呢?这就是分布式一致性问题。

二、 Raft 协议概览

Raft 就是一个解决上述分布式一致性问题的协议。类似的协议还有Paxos、Zab等等。相比 Paxos，Raft 更易理解和实现。

咱们本次会俯瞰 Raft ， 来了解其工作原理。

在 Raft 里， 节点可能存在三种状态：

• Follower
• Candidate
• Leader

在后面的图里内容中，上述三种状态分别和下面三个图一一对应。

任何时候，都只会处于上述三种状态中的一种。初始时候，所以节点都处于 Follower状态。

如果follower 节点不再能接收到 leader 节点的消息， 他们的状态就会变成 Candidate。

Candidate 节点会向其他节点发起投票请求，

其他节点也会投票进行响应。

如果获得了多数节点的投票，那 Candidate节点会成为Leader。

上面的这个过程就是分布式一致性协议中的「选举」(Leader Election)。

后续所有对于系统的变更，都是通过Leader进行的。经由 Leader 再到达其他节点。

每次 Client 的变更请求到达 leader 时，都会视为一个 Entry ，先添加到节点的日志 (Log)里。这个新增的 log entry，目前还并没有提交，所以不会真的更新节点里 X 的值。

leader 首先会复制 log entry 给所有 follower节点。

然后， leader 会等待，直到多数节点都写入了entry。

在收到多数节点的写入响应之后， leader 节点会将 entry 提交，此时 leader节点的值变成了 5.

然后 leader 会通知 follower 节点 自己的 entry 已经提交了。

（编辑：ASP站长网）