共识机制的概念，我们在前面的文章“浅说区块链共识机制”中已经讲解了一部分，但是，共识算法其实是一个非常大的话题，一篇文章肯定没有办法做到面面俱全。
那么今天的内容，我会将重点放在梳理技术的脉络上，详细分析的部分会少一点。如果你对共识算法有兴趣的话，可以自行查找相关内容，也可以和其他的资料进行相互补充的阅读。
从相亲大会说起：分布式系统的模型
由于区块链就是一种分布式系统，所以这篇文章我就从这一概念开始讲起。 为了让你更容易理解分布式系统，我们先来构建一个模型。
在“浅说区块链共识机制”那篇文章中，我举了一个村庄举办相亲大会的例子，我们来回顾一下。
大村子因为人口增长变成11个小村落分散在地图各地；
村落之间的通信只能依靠信鸽；
一只信鸽可能无法完全覆盖所有村落，需要有中继村落代为传输消息。
相亲大会的举办权会为村子带来巨大收益，为了产生合理的举办者，人们约定了几条规则：
大会举办权从A和B两个村子中产生，他们每一届都是候选村；
投票时所有村落仅能投A或B；
用投票的方式产生举办者，少数服从多数。
所有村子会为了举办权都会使出浑身解数，比如延迟发送投票结果、篡改别人的投票结果、假装没有接收到通知等等。
其实这是一个典型的分布式系统，可以看成是我们简化版的区块链网络环境，那么这个分布式系统会遇到什么样的问题呢？
分布式系统面临的问题
分布式系统面临了几个问题：一致性问题，可终止性问题、合法性问题。
可终止性可以理解为系统必须在有限的时间内给出一致性结果，合法性是指提案必须是系统内的节点提出。当然其中面对的最重要也是最基础的问题，就是我们常说的一致性问题。
一致性是指在某个分布式系统中，任意节点的提案能够在约定的协议下被其他所有节点所认可。
需要提醒你区分的一点是：这里的“认可”表示所有节点对外呈现的信息一致，而不是对信息的内容认可。一致性也分严格一致性、最终一致性，这些我们在后文会谈到。
我们回到上面的例子，我们提到了所有的村子只能投A或B，其实这个投票的动作可以理解为提案。
在“投票过程被大家所认可”这个语境下，“被大家所认可”表示某个村落投票的结果已经被记录，用于最后统计结果，而不是认可投给A或者投给B，这也是我在上述强调你要注意区分的一点。
那我们这里所说的一致性到底体现在那里呢？
主要体现在下面两种类型的问题上。
非人为恶意的意外投票过程。非人为恶意篡改可归类为信鸽半路挂掉、信鸽迷路、信鸽送错目的地、信鸽送信途中下雨导致信件内容模糊、接收信件的人不在家、天气变化信鸽延迟送达等等。这些对应到分布式系统面临的问题就是：消息丢包、网络拥堵、消息延迟、消息内容校验失败、节点宕机等。
人为恶意篡改投票过程。人为恶意篡改包括“精神分裂式投票”，中继篡改上一个村落的投票信息。对应到分布式系统面临的问题就是：消息被伪造、系统安全攻击等等。发生的人为恶意篡改的过程就可以称之为系统发生了拜占庭错误（Byzantine Fault)，如果系统可以容忍拜占庭错误而不至于崩溃，也就是在发生系统被恶意篡改的情况下仍然可以达成一致，我们将这样系统称作为做拜占庭容错系统。
问题1我们已经有较成熟的方案了。分布式系统本质上是一种并行异步操作，如果通过中心化的手段将系统中的“并行不确定”操作变更为“同步串行”操作就能解决上述的问题。
比如让第三方机构介入托管所有人的投票；或者构造一个不可伪造令牌，大家轮流将投票统一写到令牌上。
这些也是现代分布式系统经常使用的方法。但是这些方法有个缺陷，如果在分布式系统中被过多地使用以后，系统便会越来越像单点系统。
我们设计分布式系统的初衷就是为了克服单点系统的可用性不足、扩展性不好、单点性能上限等缺陷，这种退化的方案可能不是我们想要的。
而问题2要求设计拜占庭容错系统，这个在IT行业并不常见，因为多数IT系统是中心化的，所以如果我们想要解决问题2，这就引出了我们今天要介绍的共识算法与分布式一致性算法。
有关分布式系统的定理
我们在介绍具体的分布式一致性算法之前，先介绍两个定理，做一下铺垫。