“声明：由于个人水平有限，文中若存在不妥或错误之处，欢迎大家拍砖，并且一起讨论，交流。在文中会引用其他专家学者的观点和理论等内容，如文中出现版权问题，请联系我，我将以最快的速度删除。”
0 前言
作为IT行业的学生或者从业者，在我们的工作和学习的过程中，“一致性”这个词出现的非常频繁，当我们讨论数据库多副本同步时候我们提到一致性，当我们设计微服务的时候，我们讨论多个微服务的业务上的一致性。然而，我们说的一致性未必是真正的一致性，有时候我们可能指的是共识协议。在我们进行一致性和共识的深入讨论前，我们先区分“一致性”和“共识”两者的区别，以及二者之间的联系，以确保余下讨论不会出现理解上的偏差。
本文的目的是：
(1) 说明“一致性”和“共识”在分布式系统语境中的含义；
(2) 厘清“一致性”和“共识”在分布式系统的区别和联系；
在阅读下文之前可以参考网络上有关于“一致性”和“共识”的说明，如kongfy的“被误用的一致性”[1]。
1 一致性-Consistency
Consistency in database systems refers to the requirement that any given database transaction must change affected data only in allowed ways.[2]
上面的这句关于Consistency的定义是来自维基百科中数据库中的定义，大意是：数据库中的一致性指的是数据库中任何事务操作影响的数据必须遵循特定的规则（或者说容许的/可接受的规则）。其中，的“allowed ways”就为数据库一致性的定义预留了很大的空间。也就是说，只要符合allowed ways的操作都算是符合一致性要求的，那么，相应的数据库中的数据就是一致的。
这就隐含着：在特定的系统中、特定的业务需求的背景下，会对数据库中的一致性提出不同的要求，也就是allowed ways不同。这就催生出了很多种特定场景下的一致性解决方案，也产生了众多的一致性模型（如图1所示）。
图1 分布式系统中的一致性模型及其分类[3]
这篇文章里面我们先不深入探讨各种一致性的适用场景（即allowed ways），我们先来看看为什么分布式系统中需要一致性，一致性的具体作用是什么以及我们常说的一致性的语义是什么。
1.1 一致性问题的根源
从我们上一篇文章中可以看出，分布式系统可通过水平的扩展提供更强的性能（这里说的是整体性能，如吞吐量、计算能力、存储能力等）。例如，在集中式系统中，数据存储能力受限于系统中的磁盘容量，即使我们可通过增加磁盘的方式增强系统的存储能力，但是，当并发访问磁盘的用户达到一定数量时，系统中的IO性能将成为瓶颈，如果访问的数据需要进行一定的计算时，系统中的CPU性能也将成为瓶颈，这种垂直扩展的方式是具有上限的。；而在分布式系统中，我们可以通过增加机器及磁盘数量来解决上述的问题，这种通过水平扩展的方式在理论上是可以无限扩展的，也就是说：理论上，我们只要成倍扩展机器和存储设备，那么系统的处理能力和存储能力也是成倍的提升的，即系统能力的线性提升。
然而，上面说的水平扩展也存在问题，这种水平扩展是建立在我们的计算和存储是可以垂直切分的，也就是说：分布式系统中的每台机器及其存储所处理的问题是可以并发的且互相无交互的。这样一来，问题似乎又回到了原点，分布式系统中的单台机器就是集中式的，那么，集中式系统的问题仍然存在。所以，分布式系统还需要解决一个任务在系统中多台机器上并发执行时任务键的协调问题。
在回到集中式系统的问题上来，除了上面说的性能问题之外，集中式系统还存在可用性问题。我们知道，任何的硬件都无法保证7*24*365的可用性，因为硬件总是会出故障；任何的软件都无法100%保证不存在bug。所以，只要集中式系统中某一个硬件/软件出故障（实际上，这种问题肯定会出现），那么系统中的某一能力甚至整体就会不可用。
上述问题最直观的解决方案就是集群+副本的机制，具体来说就是：让多台机器提供相同的服务能力解决单台机器故障时的服务不可用问题，用副本机制解决单机性能问题及可用性问题（如图2所示）。
图2一个集群架构例子
如图2所示的集群架构，Node 1-Node n提供相同的服务（服务1和服务2），Node 1-Node n都存储相同的数据，这样，即使Node 1出现故障Node 2-Node n同样可以对外提供服务（服务1和服务2），这保证了系统的可用性。同样，每台Node上面都存储相同的数据（即数据有n-1个副本），那么，即使Node 1上的磁盘损坏，其它机器上的数据a和数据b仍然可用，这就保证了数据的可用性。从性能上来讲，Node 1-Node n同时提供相同的服务，理论上这种集群的性能是单台Node的n倍，这就保证了系统的性能。上面的例子仅用于说明，实际的分布式系统中还有许多其它架构。
当出现上述分布式系统时，在数据层面上，我们需要保证Node 1-Node n上的数据a和数据b要实时保持相同，这样才能够保证系统中任何机器上任何服务对外部提供的数据时相同的，这就是数据副本的一致性（确切的说是强一致性）；另外，还有一种一致性：假设数据a和数据b必须满足一定的要求，如a+b=100。这种也属于一致性范畴，这种一致性可以说是语义上的一致性（非正式名称）。
我们知道，在分布式系统中，网络通信开销、无共享的物理时钟、软硬件故障以及并发的操作导致了上述的一致性问题解决起来比较困难，尤其是在需要平衡性能、可用性和一致性之间的关系时，问题变得愈发困难。
总结说来，不管是数据副本的一致性还是语义上的一致性都是我们开头所说的“allowed ways”，数据副本的一致性的“allowed way=数据副本需要实时保持相同”，语义上的一致性的“allowed way=数据副本间需要满足特定的要求”。
1.2 一致性本质
从上面我们对一致性问题的来源描述中我们可以感受到，一致性其实是描述系统中特定元素的一种状态，如数据的状态，服务的状态。这种状态是需要满足我们所说的“allowed ways”。
总的来说，分布式系统中的一致性是指系统中的特定元素（或者说组件）在某一时刻的状态，这种状态需要满足特定的要求（即“allowed ways”）。在细细体会一下，“状态”这个词是一个静态的概念，是某个时间点的概念，所以说，一致性描述的是一种静态概念。但是，这种状态是可以改变的，系统中的某一个元素的状态可以从一个状态变成另一个状态，和就是常用的状态机（State Machine）的概念。
“一致性 = 符合特定规则的静态状态（静态）”
2 共识-Consensus
提到共识算法就不得不提Paxos算法，1990由Leslie Lamport提出Paxos算法是在其发表的的名为《The Part-Time Parliament》[4]论文中提出的，因为原文使用的是一种故事的描述方式而不易被理解，Leslie Lamport在2001用计算机领域的描述方式重新对Paxos算法进行了论述并发表了《Paxos Made Simple》[5]。这两篇论文配合阅读效果更好。
2.1 共识问题的根源
《The Part-Time Parliament》描述了一个希腊城邦进行法律条文确定的事情，其大意是这样的：在希腊的一个名为Paxos小岛上，有一个城邦，城邦内的社会组织很民主，城邦内的每一条法令是由议员共同表决确定的，但每一条法令需要一个议员提出提议，只要多数议员同意通过某一个议员的法令提议，那么这个法令就生效，每个议员都会记录已生效的法令。而且，每条法令需要有一个编号来保证法令颁布的顺序以及保证大家能够有相同的法令顺序。问题是，这里的议员都是兼职的（因为要养家糊口，需要外出做生意），所以，将所有议员集中起来一起表决是不可能的，而且，即使参加表决会议的议员也可能随时离开。为了尽快确定一条法令，每个议员都会尽可能同意其它议员的提议。
最终的问题就演变成了：如何找出一种议员的工作流程和方式来确定一个法令编号及表决通过这个标号对应的法令。
《Paxos Made Simple》描述了一个分布式系统中多个进程间如何协调以确定一个操作的算法。其大意是：在一个分布式系统中，有多个进程（分布在系统中不同的计算机节点上），这些进程需要就下一步的操作达成一致意见。为此，进程间需要一系列的协商过程来确定最终的操作。
最终的问题就演变成了：如何找出一种共识算法（进程间的协调过程）来确定一个序号及对应的操作，然后，所有进程执行这个操作。
两篇文章的具体细节本文就不详细描述了，后面会单独介绍。
2.2 共识问题的本质
从上面的描述可以看出，共识算法本质上是一个过程，这个过程用于在多个进程间进行协调来确定所有相关进程的下一个操作。总体说来：
“共识 = 状态间变换规则的选举过程（动态）”
所以说，共识算法是一个动态的过程，这个过程来确定下一个动作（操作），这个动作就是系统中进程状态改变的原因。
3 一致性和共识的区别
从上面对一致性和共识的描述我们可以列出二者之间的一些区别如下：
图3 Consistency和Consensus的区别
4 一致性和共识的联系
从上面对一致性和共识的描述我们可以列出二者之间的一些联系如下：
图4 Consistency和Consensus的关系
Consensus是用来描述一组进程间协作的过程，这个过程的目的是在相关的进程间确定下一个操作；
再借助Raft来说明一下，在Raft算法中，作者将一致性问题看成系统中进程间（在不同机器上）一个状态机同步问题，为保证每个机器上的进程具有一致性（即状态改变的过程一样），作者使用了Raft这个共识算法来保证在每个进程初始状态相同的情况下，每个进程的下一个操作（状态改变操作）相同，这样就能保证所有进程的状态机的改变过程是一样的，即系统中的进程最终会达成一致状态。
可以说，Consistency是系统中需要保证的一个属性（即“Allowed ways”），而Consensus算法是实现Consistency的一种手段（主要是最终一致性）。当然，保证一致性的方法还有其它手段，如强一致性可通过2PC保证。
5 总结
一致性可分为数据副本的一致性和语义上的一致性（非正式分类），共识算法主要是为了保证数据副本一致性的一种手段。
6 参考文献
[1] [endif]http://blog.kongfy.com/2016/08/%E8%A2%AB%E8%AF%AF%E7%94%A8%E7%9A%84%E4%B8%80%E8%87%B4%E6%80%A7/
[2] https://en.wikipedia.org/wiki/Consistency_(database_systems)
[3] https://arxiv.org/pdf/1902.03305.pdf
[4] https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf
[5] https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
[6] https://raft.github.io/raft.pdf
网友评论