区块链：分布式系统核心技术
万法皆空，因果不空。
随着摩尔定律碰到瓶颈，分布式架构越来越常见。
从单点演变到分布式结构，首要问题之一就是数据一致性。很显然，如果分布式集群中多个节点处理结果无法保证一致，那么在其上的业务系统将无法正常工作。
区块链系统是一个典型的分布式系统，必然也会碰到这些经典问题。
本章将介绍分布式系统领域的核心技术，包括一致性、共识的定义，基本的原理和常见算法，最后还介绍了评估分布式系统可靠性的指标。
一致性问题
一致性问题是分布式领域最基础、最重要的问题，也是半个世纪以来的研究热点。
随着业务场景越来越复杂，计算规模越来越庞大，单点系统往往难以满足高可扩展（Scalability）和高容错（Fault-tolerance）两方面的需求。此时就需要多台服务器通过组成集群，构建更加强大和稳定的“虚拟超级服务器”。
任务量越大，处理集群的规模越大，设计和管理的挑战也就越高。谷歌公司的全球搜索集群系统，包括数十万台服务器，每天响应百亿次的互联网搜索请求。
集群系统要实现一致性不是一件容易的事。不同节点可能处于不同的状态，不同时刻收到不同的请求，而且随时可能有节点出现故障。要保持对外响应的“一致性”，好比训练一群鸭子齐步走，难度可想而知。
定义与重要性
定义 一致性（Consistency），早期也叫（Agreement），在分布式系统领域中是指对于多个服务节点，给定一系列操作，在约定协议的保障下，使得它们对处理结果达成“某种程度”的协同。
理想情况（不考虑节点故障）下，如果各个服务节点严格遵循相同的处理协议（即构成相同的状态机逻辑），则在给定相同的初始状态和输入序列时，可以确保处理过程中的每个步骤的执行结果都相同。因此，传统分布式系统中讨论一致性，往往是指在外部任意发起请求（如向多个节点发送不同请求）的情况下，确保系统内大部分节点实际处理请求序列的一致，即对请求进行全局排序。
那么，为什么说一致性问题十分重要呢？
举个现实生活中的例子，多个售票处同时出售某线路上的火车票，该线路上存在多个经停站，怎么才能保证在任意区间都不会出现超售（同一个座位卖给两个人）的情况？
这个问题看起来似乎没那么难，现实生活中经常通过分段分站售票的机制。然而，要支持海量的用户进行并行购票，并非易事（参考 12306 的案例）。特别是计算机系统往往需要达到远超物理世界的高性能和高可扩展性需求，挑战会变得更大。这也是为何每年到了促销季，各大电商平台都要提前完善系统。
注：一致性关注的是系统呈现的状态，并不关注结果是否正确；例如，所有节点都对某请求达成否定状态也是一种一致性。
问题挑战
计算机固然很快，但在很多地方都比人类世界脆弱的多。典型的，在分布式系统中，存在不少挑战：
- 节点完成请求的时间无法保障，处理的结果可能是错误的，甚至节点自身随时可能发生故障；
- 为了实现可扩展性，集群往往要采用异步设计，依靠网络消息交互，意味着不可预测的通信延迟、丢失或错误。
仍以火车票售卖问题为例，愿意动脑筋的读者可能已经想到了一些不错的解决思路，例如：
- 要出售任意一张票前，先打电话给其他售票处，确认下当前这张票不冲突。即退化为同步调用来避免冲突；
- 多个售票处提前约好隔离的售票时间。比如第一家可以在上午 8 点到 9 点期间卖票，接下来一个小时是另外一家……即通过令牌机制来避免冲突；
- 成立一个第三方的存票机构，票集中存放，每次卖票前找存票机构查询。此时问题退化为中心化中介机制。
这些思路假设售票处都能保证正常工作，并且消息传递不会出现错误。
当然，还可以设计出更多更完善的方案，但它们背后的核心思想，都是将可能引发不一致的并行操作进行串行化。这实际上也是现代分布式系统处理一致性问题的基础思路。另外，由于普通计算机硬件和软件的可靠性不足，在工程实现上还要对核心部件稳定性进行加强。
反过来，如果节点都很鲁棒，性能足够强，同时网络带宽足够大、延迟足够低，这样的集群系统往往更容易实现一致性。
然而，真实情况可能比人们预期的糟糕。2015年，论文《Taming Uncertainty in Distributed Systems with Help from the Network》中指出，即便部署了专业设备和冗余网络的数据中心，每个月发生的网络故障高达 12 次。
一致性的要求
规范来看，分布式系统达成一致的过程，应该满足：
- 可终止性（Termination）：一致的结果在有限时间内能完成；
- 约同性（Agreement）：不同节点最终完成决策的结果是相同的；
- 合法性（Validity）：决策的结果必须是某个节点提出的提案。
可终止性很容易理解。有限时间内完成，意味着可以保障提供服务（Liveness）。这是计算机系统可以被正常使用的前提。需要注意，在现实生活中这点并不是总能得到保障的。例如取款机有时候会出现“服务中断”；拨打电话有时候是“无法连接”的。
约同性看似容易，实际上暗含了一些潜在信息。决策的结果相同，意味着算法要么不给出结果，任何给出的结果必定是达成了共识的，即安全性（Safety）。挑战在于算法必须要考虑的是可能会处理任意的情形。凡事一旦推广到任意情形，往往就不像看起来那么简单。例如现在就剩一张某区间（如北京 --> 南京）的车票了，两个售票处也分别刚通过某种方式确认过这张票的存在。这时，两家售票处几乎同时分别来了一个乘客要买这张票，从各自“观察”看来，自己一方的乘客都是先到的……这种情况下，怎么能达成对结果的共识呢？看起来很容易，卖给物理时间上率先提交请求的乘客即可。然而，对于两个来自不同位置的请求来说，要判断在时间上的“先后”关系并不是那么容易。两个车站的时钟时刻可能是不一致的；时钟计时可能不精确的……根据相对论的观点，不同空间位置的时间是不一致的。因此追求绝对时间戳的方案是不可行的，能做的是要对事件的发生进行排序。
事件发生的相对先后顺序（逻辑时钟）十分重要，确定了顺序，就没有了分歧。这也是解决分布式系统领域很多问题的核心秘诀：把不同时空发生的多个事件进行全局唯一排序，而且这个顺序还得是大家都认可的。
如果存在可靠的物理时钟，实现排序往往更为简单。高精度的石英钟的漂移率为 
，最准确的原子震荡时钟的漂移率为 
。Google 曾在其分布式数据库 Spanner 中采用基于原子时钟和 GPS 的“TrueTime”方案，能够将不同数据中心的时间偏差控制在 10ms 置信区间。在不考虑成本的前提下，这种方案简单、有效。然而，计算机系统的时钟误差要大得多，这就造成分布式系统达成一致顺序十分具有挑战。
注：Leslie Lamport 在 1978 年发表的论文《Time, Clocks and the Ordering of Events in a Distributed System》中将分布式系统中顺序与相对论进行对比，提出了偏序关系的观点。而根据相对论，并不存在绝对的时间。因此，先后顺序可能更有意义。
最后的合法性看似绕口，但其实比较容易理解，即达成的结果必须是节点执行操作的结果。仍以卖票为例，如果两个售票处分别决策某张票出售给张三和李四，那么最终达成一致的结果要么是张三，要么是李四，而不能是其他人。
带约束的一致性
从前面的分析可以看到，要实现绝对理想的严格一致性（Strict Consistency）代价很大。除非系统不发生任何故障，而且所有节点之间的通信无需任何时间，此时整个系统其实就等价于一台机器了。实际上，越强的一致性要求往往意味着带来越弱的处理性能，以及越差的可扩展性。根据实际需求的不用，人们可能选择不同强度的一致性，包括强一致性（Strong Consistency）和弱一致性（Weak Consistency）。
一般地，强一致性主要包括下面两类：
- 顺序一致性（Sequential Consistency）：又叫因果一致性，最早由 Leslie Lamport 1979 年经典论文《How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs》中提出，是一种比较强的约束。所有进程看到的全局执行顺序（total order）一致（否则数据副本就不一致了）；并且每个进程看自身操作的顺序（local order）跟实际发生顺序一致。例如，某进程先执行 A，后执行 B，则实际得到的全局结果（其它进程也看到这个结果）中就应该为 A 在 B 前面，而不能反过来。如果另外一个进程先后执行了C、D操作，则全局顺序可以共识为 A、B、C、D 或 A、C、B、D 或 C、A、B、D 或 C、D、A、B 的一种（即 A、B 和 C、D 的组合），决不能出现 B、A 或 D、C。顺序一致性实际上限制了各进程内指令的偏序关系，但不在进程间按照物理时间进行全局排序，属于实践中可行的最强保证。以算盘为例，每个进程的事件是某根横轴上的算珠，它们可以前后拨动（改变不同进程之间先后顺序），但同一个横轴上的算珠的相对先后顺序无法改变。
- 线性一致性（Linearizability Consistency）：Maurice P. Herlihy 与 Jeannette M. Wing 在 1990 年经典论文《Linearizability: A Correctness Condition for Concurrent Objects》中共同提出，是一种更强的保证。在顺序一致性前提下加强了进程间的操作排序，形成理想化的全局顺序。线性一致性要求系统看起来似乎只有一个数据副本，客户端操作都是原子的，并且顺序执行；所有进程的操作似乎是实时同步的，并且跟实际发生顺序一致。例如某个客户端写入成功，则其它客户端将立刻看到最新的值。线性一致性下所有进程的所有事件似乎都处于同一个横轴，存在唯一的先后顺序。线性一致性很难实现，目前基本上要么依赖于全局的时钟或锁，要么通过一些复杂同步算法，性能往往不高。
强一致的系统往往比较难实现，而且很多场景下对一致性的需求并没有那么强。因此，可以适当放宽对一致性的要求，降低系统实现的难度。例如在一定约束下实现所谓最终一致性（Eventual Consistency），即总会存在一个时刻（而不是立刻），让系统达到一致的状态。例如电商购物时将某物品放入购物车，但是可能在最终付款时才提示物品已经售罄了。实际上，大部分的 Web 系统为了保持服务的稳定，实现的都是最终一致性。
相对强一致性，类似最终一致性这样在某些方面弱化的一致性，被笼统称为弱一致性。
共识算法
共识（Consensus），很多时候会见到与一致性（Consistency）术语放在一起讨论。严谨地讲，两者的含义并不完全相同。
一致性的含义比共识宽泛，在不同场景（基于事务的数据库、分布式系统等）下意义不同。具体到分布式系统场景下，一致性指的是多个副本对外呈现的状态。如前面提到的顺序一致性、线性一致性，描述了多节点对数据状态的共同维护能力。而共识，则特指在分布式系统中多个节点之间对某个事情（例如多个事务请求，先执行谁？）达成一致看法的过程。因此，达成某种共识并不意味着就保障了一致性。
实践中，要保障系统满足不同程度的一致性，往往需要通过共识算法来达成。
共识算法解决的是分布式系统对某个提案（Proposal），大部分节点达成一致意见的过程。提案的含义在分布式系统中十分宽泛，如多个事件发生的顺序、某个键对应的值、谁是主节点……等等。可以认为任何可以达成一致的信息都是一个提案。
对于分布式系统来讲，各个节点通常都是相同的确定性状态机模型（又称为状态机复制问题，State-Machine Replication），从相同初始状态开始接收相同顺序的指令，则可以保证相同的结果状态。因此，系统中多个节点最关键地是对多个事件的顺序进行共识，即排序。
注：计算机世界里采用的是典型的“多数人暴政”，足够简单、高效。
问题与挑战
无论是在现实生活中，还是计算机世界里，达成共识都要解决两个基本的问题：
- 首先，如何提出一个待共识的提案？如通过令牌传递、随机选取、权重比较、求解难题……等；
- 其次，如何让多个节点对该提案达成共识（同意或拒绝），如投票、规则验证……等。
理论上，如果分布式系统中各节点都能以十分“理想”的性能（瞬间响应、超高吞吐）稳定运行，节点之间通信瞬时送达（如量子纠缠），则实现共识过程并不十分困难，简单地通过广播进行瞬时投票和应答即可。
可惜地是，现实中这样的“理想”系统并不存在。不同节点之间通信存在延迟（光速物理限制、通信处理延迟），并且任意环节都可能存在故障（系统规模越大，发生故障可能性越高）。如通信网络会发生中断、节点会发生故障、甚至存在被入侵的节点故意伪造消息，破坏正常的共识过程。
一般地，把出现故障（Crash 或 Fail-stop，即不响应）但不会伪造信息的情况称为“非拜占庭错误（Non-Byzantine Fault）”或“故障错误（Crash Fault）”；伪造信息恶意响应的情况称为“拜占庭错误”（Byzantine Fault），对应节点为拜占庭节点。显然，后者场景中因为存在“捣乱者”更难达成共识。
此外，任何处理都需要成本，共识也是如此。当存在一定信任前提（如接入节点都经过验证、节点性能稳定、安全保障很高）时，达成共识相对容易，共识性能也较高；反之在不可信的场景下，达成共识很难，需要付出较大成本（如时间、经济、安全等），而且性能往往较差（如工作量证明算法）。
注：非拜占庭场景的典型例子是通过报数来统计人数，即便偶有冲突（如两人同时报一个数）也能很快解决；拜占庭场景的一个常见例子是“杀人游戏”，当参与者众多时很难快速达成共识。
常见算法
根据解决的场景是否允许拜占庭错误情况，共识算法可以分为 Crash Fault Tolerance (CFT) 和 Byzantine Fault Tolerance（BFT）两类。
对于非拜占庭错误的情况，已经存在不少经典的算法，包括 Paxos（1990 年）、Raft（2014 年）及其变种等。这类容错算法往往性能比较好，处理较快，容忍不超过一半的故障节点。
对于要能容忍拜占庭错误的情况，包括 PBFT（Practical Byzantine Fault Tolerance，1999 年）为代表的确定性系列算法、PoW（1997 年）为代表的概率算法等。确定性算法一旦达成共识就不可逆转，即共识是最终结果；而概率类算法的共识结果则是临时的，随着时间推移或某种强化，共识结果被推翻的概率越来越小，最终成为事实上结果。拜占庭类容错算法往往性能较差，容忍不超过 1/3 的故障节点。
此外，XFT（Cross Fault Tolerance，2015 年）等最近提出的改进算法可以提供类似 CFT 的处理响应速度，并能在大多数节点正常工作时提供 BFT 保障。
Algorand 算法（2017 年）基于 PBFT 进行改进，通过引入可验证随机函数解决了提案选择的问题，理论上可以在容忍拜占庭错误的前提下实现更好的性能（1000+ TPS）。
注：实践中，对客户端来说要拿到共识结果需要自行验证，典型地，可访问足够多个服务节点来比对结果，确保获取结果的准确性。
理论界限
科学家都喜欢探寻问题最坏情况的理论界限。那么，共识问题的最坏界限在哪里呢？很不幸，在推广到任意情况时，分布式系统的共识问题无通用解。
这似乎很容易理解，当多个节点之间的通信网络自身不可靠情况下，很显然，无法确保实现共识（例如，所有涉及共识的消息都丢失）。那么，对于一个设计得当，可以大概率保证消息正确送达的网络，是不是一定能获得共识呢？
理论证明告诉我们，即便在网络通信可靠情况下，一个可扩展的分布式系统的共识问题通用解法的下限是——没有下限（无解）。
这个结论，被称为“FLP 不可能原理”。该原理极其重要，可以看做是分布式领域里的“测不准原理”。
注：不光分布式系统领域，实际上很多领域都存在类似测不准原理的约束，或许说明世界本源就存在限制。
FLP 不可能原理
定义
FLP 不可能原理：在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法（No completely asynchronous consensus protocol can tolerate even a single unannounced process death）。
提出并证明该定理的论文《Impossibility of Distributed Consensus with One Faulty Process》是由 Fischer，Lynch 和 Patterson 三位科学家于 1985 年发表，该论文后来获得了 Dijkstra（就是发明最短路径算法的那位计算机科学家）奖。
FLP 不可能原理告诉我们，不要浪费时间，去试图为异步分布式系统设计面向任意场景的共识算法。
如何理解
要正确理解 FLP 不可能原理，首先要弄清楚“异步”的含义。
在分布式系统中，同步和异步这两个术语存在特殊的含义。
- 同步，是指系统中的各个节点的时钟误差存在上限；并且消息传递必须在一定时间内完成，否则认为失败；同时各个节点完成处理消息的时间是一定的。因此同步系统中可以很容易地判断消息是否丢失。
- 异步，则意味着系统中各个节点可能存在较大的时钟差异；同时消息传输时间是任意长的；各节点对消息进行处理的时间也可能是任意长的。这就造成无法判断某个消息迟迟没有被响应是哪里出了问题（节点故障还是传输故障？）。不幸地是，现实生活中的系统往往都是异步系统。
FLP 不可能性在论文中以图论的形式进行了严格证明。要理解其基本原理并不复杂，一个不严谨的例子如下。
三个人在不同房间，进行投票（投票结果是 0 或者 1）。彼此可以通过电话进行沟通，但经常有人会时不时睡着。比如某个时候，A 投票 0，B 投票 1，C 收到了两人的投票，然后 C 睡着了。此时，A 和 B 将永远无法在有限时间内获知最终的结果，究竟是 C 没有应答还是应答的时间过长。如果可以重新投票，则类似情形可以在每次取得结果前发生，这将导致共识过程永远无法完成。
FLP 原理实际上说明对于允许节点失效情况下，纯粹异步系统无法确保共识在有限时间内完成。即便对于非拜占庭错误的前提下，包括 Paxos、Raft 等算法也都存在无法达成共识的极端情况，只是在工程实践中这种情况出现的概率很小。
那么，这是否意味着研究共识算法压根没有意义？
不必如此悲观。学术研究，往往考虑地是数学和物理意义上理想化的情形，很多时候现实世界要稳定得多（感谢这个世界如此鲁棒！）。例如，上面例子中描述的最坏情形，每次都发生的概率其实并没有那么大。工程实现上某次共识失败，再尝试几次，很大可能就成功了。
科学告诉你什么是不可能的；工程则告诉你，付出一些代价，可以把它变成可行。
这就是科学和工程不同的魅力。FLP 不可能原理告诉大家不必浪费时间去追求完美的共识方案，而要根据实际情况设计可行的工程方案。
那么，退一步讲，在付出一些代价的情况下，共识能做到多好？
回答这一问题的是另一个很出名的原理：CAP 原理。
注：科学告诉你去赌场是愚蠢的，因为最终总会输钱；工程则告诉你，如果你愿意接受最终输钱的风险，中间说不定能偶尔小赢几笔呢！
CAP 原理
CAP 原理最早出现在 2000 年，由加州大学伯克利分校的 Eric Brewer 教授在 ACM 组织的 Principles of Distributed Computing（PODC）研讨会上提出猜想。两年后，麻省理工学院的 Nancy Lynch 等学者进行了理论证明。
该原理被认为是分布式系统领域的重要原理之一，深刻影响了分布式计算与系统设计的发展。
定义
CAP 原理：分布式系统无法同时确保一致性（Consistency）、可用性（Availability）和分区容忍性（Partition），设计中往往需要弱化对某个特性的需求。
一致性、可用性和分区容忍性的具体含义如下：
- 一致性（Consistency）：任何事务应该都是原子的，所有副本上的状态都是事务成功提交后的结果，并保持强一致；
- 可用性（Availability）：系统（非失败节点）能在有限时间内完成对操作请求的应答；
- 分区容忍性（Partition）：系统中的网络可能发生分区故障（成为多个子网，甚至出现节点上线和下线），即节点之间的通信无法保障。而网络故障不应该影响到系统正常服务。
CAP 原理认为，分布式系统最多只能保证三项特性中的两项特性。
比较直观地理解，当网络可能出现分区时候，系统是无法同时保证一致性和可用性的。要么，节点收到请求后因为没有得到其它节点的确认而不应答（牺牲可用性），要么节点只能应答非一致的结果（牺牲一致性）。
由于大部分时候网络被认为是可靠的，因此系统可以提供一致可靠的服务；当网络不可靠时，系统要么牺牲掉一致性（多数场景下），要么牺牲掉可用性。
注意：网络分区是可能存在的，出现分区情况后很可能会导致发生“脑裂”现象。
应用场景
既然 CAP 三种特性不可同时得到保障，则设计系统时候必然要弱化对某个特性的支持。
弱化一致性
对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才最终更新成功，期间不保证一致性。
例如网站静态页面内容、实时性较弱的查询类数据库等，简单分布式同步协议如 Gossip，以及 CouchDB、Cassandra 数据库等，都为此设计。
弱化可用性
对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce 等为此设计。
Paxos、Raft 等共识算法，主要处理这种情况。在 Paxos 类算法中，可能存在着无法提供可用结果的情形，同时允许少数节点离线。
弱化分区容忍性
现实中，网络分区出现概率较小，但很难完全避免。
两阶段的提交算法，某些关系型数据库以及 ZooKeeper 主要考虑了这种设计。
实践中，网络可以通过双通道等机制增强可靠性，实现高稳定的网络通信。
ACID 原则与多阶段提交
ACID 原则
ACID，即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）四种特性的缩写。
ACID 也是一种比较出名的描述一致性的原则，通常出现在分布式数据库等基于事务过程的系统中。
具体来说，ACID 原则描述了分布式数据库需要满足的一致性需求，同时允许付出可用性的代价。
- Atomicity：每次事务是原子的，事务包含的所有操作要么全部成功，要么全部不执行。一旦有操作失败，则需要回退状态到执行事务之前；
- Consistency：数据库的状态在事务执行前后的状态是一致的和完整的，无中间状态。即只能处于成功事务提交后的状态；
- Isolation：各种事务可以并发执行，但彼此之间互相不影响。按照标准 SQL 规范，从弱到强可以分为未授权读取、授权读取、可重复读取和串行化四种隔离等级；
- Durability：状态的改变是持久的，不会失效。一旦某个事务提交，则它造成的状态变更就是永久性的。
与 ACID 相对的一个原则是 eBay 技术专家 Dan Pritchett 提出的 BASE（Basic Availability，Soft-state，Eventual Consistency）原则。BASE 原则面向大型高可用分布式系统，主张牺牲掉对强一致性的追求，而实现最终一致性，来换取一定的可用性。
注：ACID 和 BASE 在英文中分别是“酸”和“碱”，看似对立，实则是对 CAP 三特性的不同取舍。
两阶段提交
对于分布式事务一致性的研究成果包括著名的两阶段提交算法（Two-phase Commit，2PC）和三阶段提交算法（Three-phase Commit，3PC）。
两阶段提交算法最早由 Jim Gray 于 1979 年在论文《Notes on Database Operating Systems》中提出。其基本思想十分简单，既然在分布式场景下，直接提交事务可能出现各种故障和冲突，那么可将其分解为预提交和正式提交两个阶段，规避冲突的风险。
- 预提交：协调者（Coordinator）发起提交某个事务的申请，各参与执行者（Participant）需要尝试进行提交并反馈是否能完成；
- 正式提交：协调者如果得到所有执行者的成功答复，则发出正式提交请求。如果成功完成，则算法执行成功。
在此过程中任何步骤出现问题（例如预提交阶段有执行者回复预计无法完成提交），则需要回退。
两阶段提交算法因为其简单容易实现的优点，在关系型数据库等系统中被广泛应用。当然，其缺点也很明显。整个过程需要同步阻塞导致性能一般较差；同时存在单点问题，较坏情况下可能一直无法完成提交；另外可能产生数据不一致的情况（例如协调者和执行者在第二个阶段出现故障）。
三阶段提交
三阶段提交针对两阶段提交算法第一阶段中可能阻塞部分执行者的情况进行了优化。具体来说，将预提交阶段进一步拆成两个步骤：尝试预提交和预提交。
完整过程如下：
- 尝试预提交：协调者询问执行者是否能进行某个事务的提交。执行者需要返回答复，但无需执行提交。这就避免出现部分执行者被无效阻塞住的情况。
- 预提交：协调者检查收集到的答复，如果全部为真，则发起提交事务请求。各参与执行者（Participant）需要尝试进行提交并反馈是否能完成；
- 正式提交：协调者如果得到所有执行者的成功答复，则发出正式提交请求。如果成功完成，则算法执行成功。
其实，无论两阶段还是三阶段提交，都只是一定程度上缓解了提交冲突的问题，并无法一定保证系统的一致性。首个有效的算法是后来提出的 Paxos 算法。
Paxos 算法与 Raft 算法
Paxos 问题是指分布式的系统中存在故障（crash fault），但不存在恶意（corrupt）节点的场景（即可能消息丢失或重复，但无错误消息）下的共识达成问题。这也是分布式共识领域最为常见的问题。因为最早是 Leslie Lamport 用 Paxos 岛的故事模型来进行描述，而得以命名。解决 Paxos 问题的算法主要有 Paxos 系列算法和 Raft 算法。
Paxos 算法
1988 年，Brian M. Oki 和 Barbara H. Liskov 在论文《Viewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems》中首次提出了解决 Paxos 问题的算法。
1990 年由 Leslie Lamport 在论文《The Part-time Parliament》中提出的 Paxos 共识算法，在工程角度实现了一种最大化保障分布式系统一致性（存在极小的概率无法实现一致）的机制。Paxos 算法本质上与前者相同，被广泛应用在 Chubby、ZooKeeper 这样的分布式系统中。Leslie Lamport 作为分布式系统领域的早期研究者，因为相关杰出贡献获得了 2013 年度图灵奖。
论文中为了描述问题编造了一个虚构故事：在古代爱琴海的 Paxos 岛，议会如何通过表决来达成共识。议员们通过信使传递消息来对议案进行表决。但议员可能离开，信使可能走丢，甚至重复传递消息。
Paxos 是首个得到证明并被广泛应用的共识算法，其原理类似 两阶段提交 算法，进行了泛化和扩展，通过消息传递来逐步消除系统中的不确定状态。
作为后来很多共识算法（如 Raft、ZAB 等）的基础，Paxos 算法基本思想并不复杂，但最初论文中描述比较难懂，甚至连发表也几经波折。2001 年，Leslie Lamport 还专门发表论文《Paxos Made Simple》进行重新解释。
基本原理
算法中存在三种逻辑角色的节点，在实现中同一节点可以担任多个角色。
- 提案者（Proposer）：提出一个提案，等待大家批准（Chosen）为结案（Value）。系统中提案都拥有一个自增的唯一提案号。往往由客户端担任该角色。
- 接受者（Acceptor）：负责对提案进行投票，接受（Accept）提案。往往由服务端担任该角色。
- 学习者（Learner）：获取批准结果，并帮忙传播，不参与投票过程。可为客户端或服务端。
算法需要满足安全性（Safety） 和存活性（Liveness）两方面的约束要求。实际上这两个基础属性也是大部分分布式算法都该考虑的。
- Safety：保证决议（Value）结果是对的，无歧义的，不会出现错误情况。
- 只有是被提案者提出的提案才可能被最终批准；
- 在一次执行中，只批准（chosen）一个最终决议。被多数接受（accept）的结果成为决议；
- Liveness：保证决议过程能在有限时间内完成。
- 决议总会产生，并且学习者能获得被批准的决议。
基本思路类似两阶段提交：多个提案者先要争取到提案的权利（得到大多数接受者的支持）；成功的提案者发送提案给所有人进行确认，得到大部分人确认的提案成为批准的结案。
Paxos 并不保证系统总处在一致的状态。但由于每次达成共识至少有超过一半的节点参与，这样最终整个系统都会获知共识结果。一个潜在的问题是提案者在提案过程中出现故障，这可以通过超时机制来缓解。极为凑巧的情况下，每次新一轮提案的提案者都恰好故障，又或者两个提案者恰好依次提出更新的提案，则导致活锁，系统会永远无法达成共识（实际发生概率很小）。
Paxos 能保证在超过一半的节点正常工作时，系统总能以较大概率达成共识。读者可以试着自己设计一套非拜占庭容错下基于消息传递的异步共识方案，会发现在满足各种约束情况下，算法过程总会十分类似 Paxos 的过程。这也是为何 Google Chubby 的作者 Mike Burrows 说：“这个世界上只有一种一致性算法，那就是 Paxos（There is only one consensus protocol, and that's Paxos）”。
下面，由简单情况逐步推广到一般情况来探讨算法过程。
单个提案者+多接受者
如果系统中限定只允许某个特定节点是提案者，那么共识结果很容易能达成（只有一个方案，要么达成，要么失败）。提案者只要收到了来自多数接受者的投票，即可认为通过，因为系统中不存在其他的提案。
但此时一旦提案者故障，则整个系统无法工作。
多个提案者+单个接受者
限定某个特定节点作为接受者。这种情况下，共识也很容易达成，接受者收到多个提案，选第一个提案作为决议，发送给其它提案者即可。
缺陷也是容易发生单点故障，包括接受者故障或首个提案者节点故障。
以上两种情形其实类似主从模式，虽然不那么可靠，但因为原理简单而被广泛采用。
当提案者和接受者都推广到多个的情形，会出现一些挑战。
多个提案者+多个接受者
既然限定单提案者或单接受者都会出现故障，那么就得允许出现多个提案者和多个接受者。问题一下子变得复杂了。
一种情况是同一时间片段（如一个提案周期）内只有一个提案者，这时可以退化到单提案者的情形。需要设计一种机制来保障提案者的正确产生，例如按照时间、序列、或者大家猜拳（出一个参数来比较）之类。考虑到分布式系统要处理的工作量很大，这个过程要尽量高效，满足这一条件的机制非常难设计。
另一种情况是允许同一时间片段内可以出现多个提案者。那同一个节点可能收到多份提案，怎么对他们进行区分呢？这个时候采用只接受第一个提案而拒绝后续提案的方法也不适用。很自然的，提案需要带上不同的序号。节点需要根据提案序号来判断接受哪个。比如接受其中序号较大（往往意味着是接受新提出的，因为旧提案者故障概率更大）的提案。
如何为提案分配序号呢？一种可能方案是每个节点的提案数字区间彼此隔离开，互相不冲突。为了满足递增的需求可以配合用时间戳作为前缀字段。
同时允许多个提案，意味着很可能单个提案人无法集齐足够多的投票；另一方面，提案者即便收到了多数接受者的投票，也不敢说就一定通过。因为在此过程中投票者无法获知其它投票人的结果，也无法确认提案人是否收到了自己的投票。因此，需要实现两个阶段的提交过程。
两阶段的提交
提案者发出提案申请之后，会收到来自接受者的反馈。一种结果是提案被大多数接受者接受了，一种结果是没被接受。没被接受的话，可以过会再重试。即便收到来自大多数接受者的答复，也不能认为就最终确认了。因为这些接受者自己并不知道自己刚答复的提案可以构成大多数的一致意见。
很自然的，需要引入新的一个阶段，即提案者在第一阶段拿到所有的反馈后，需要再次判断这个提案是否得到大多数的支持，如果支持则需要对其进行最终确认。
Paxos 里面对这两个阶段分别命名为准备（Prepare）和提交（Commit）。准备阶段通过锁来解决对哪个提案内容进行确认的问题，提交阶段解决大多数确认最终值的问题。
准备阶段：
- 提案者发送自己计划提交的提案的编号到多个接受者，试探是否可以锁定多数接受者的支持。
- 接受者时刻保留收到过提案的最大编号和接受的最大提案。如果收到提案号比目前保留的最大提案号还大，则返回自己已接受的提案值（如果还未接受过任何提案，则为空）给提案者，更新当前最大提案号，并说明不再接受小于最大提案号的提案。
提交阶段：
- 提案者如果收到大多数的回复（表示大部分人听到它的请求），则可准备发出带有刚才提案号的接受消息。如果收到的回复中不带有新的提案，说明锁定成功。则使用自己的提案内容；如果返回中有提案内容，则替换提案值为返回中编号最大的提案值。如果没收到足够多的回复，则需要再次发出请求。
- 接受者收到接受消息后，如果发现提案号不小于已接受的最大提案号，则接受该提案，并更新接受的最大提案。
一旦多数接受者接受了共同的提案值，则形成决议，成为最终确认。
Raft 算法
Paxos 算法虽然给出了共识设计，但并没有讨论太多实现细节，也并不重视工程上的优化，因此后来在学术界和工程界出现了一些改进工作，包括 Fast Paxos、Multi-Paxos，Zookeeper Atomic Broadcast（ZAB）和 Raft 等。这些算法重点在于改进执行效率和可实现性。
其中，Raft 算法由斯坦福大学的 Diego Ongaro 和 John Ousterhout 于 2014 年在论文《In Search of an Understandable Consensus Algorithm》中提出，基于 Multi-Paxos 算法进行重新简化设计和实现，提高了工程实践性。Raft 算法的主要设计思想与 ZAB 类型，通过先选出领导节点来简化流程和提高效率。实现上分解了领导者选举、日志复制和安全方面的考虑，并通过约束减少了不确定性的状态空间。
算法包括三种角色：领导者（Leader）、候选者（Candidate） 和跟随者（Follower），每个任期内选举一个全局的领导者。领导者角色十分关键，决定日志（log）的提交。每个日志都会路由到领导者，并且只能由领导者向跟随者单向复制。
典型的过程包括两个主要阶段：
- 领导者选举：开始所有节点都是跟随者，在随机超时发生后未收到来自领导者或候选者消息，则转变角色为候选者（中间状态），提出选举请求。最近选举阶段（Term）中得票超过一半者被选为领导者；如果未选出，随机超时后进入新的阶段重试。领导者负责从客户端接收请求，并分发到其他节点；
- 同步日志：领导者会决定系统中最新的日志记录，并强制所有的跟随者来刷新到这个记录，数据的同步是单向的，确保所有节点看到的视图一致。
此外，领导者会定期向所有跟随者发送心跳消息，跟随者如果发现心跳消息超时未收到，则可以认为领导者已经下线，尝试发起新的选举过程。
拜占庭问题与算法
拜占庭问题（Byzantine Problem）又叫拜占庭将军（Byzantine Generals Problem）问题，讨论的是允许存在少数节点作恶（消息可能被伪造）场景下的如何达成共识问题。拜占庭容错（Byzantine Fault Tolerant，BFT）讨论的是容忍拜占庭错误的共识算法。
两将军问题
拜占庭问题之前，学术界就已经存在两将军问题的讨论（《Some constraints and tradeofis in the design of network communications》，1975 年）：两个将军要通过信使来达成进攻还是撤退的约定，但信使可能迷路或被敌军阻拦（消息丢失或伪造），如何达成一致？根据 FLP 不可能原理，这个问题无通用解。
拜占庭问题
拜占庭问题最早由 Leslie Lamport 等学者于 1982 年在论文《The Byzantine Generals Problem》中正式提出，是用来解释异步系统中共识问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，假设其守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致决定。但由于将军中可能存在叛徒（系统中节点出错），这些叛徒将向不同的将军发送不同的消息，试图干扰共识的达成。
拜占庭问题即讨论在此情况下，如何让忠诚的将军们能达成行动的一致。
在大多数的分布式系统中，拜占庭的场景并不多见。然而在特定场景下存在意义，例如允许匿名参与的系统（如比特币），或是出现欺诈可能造成巨大损失的情况。
问题的解决
论文中指出，对于拜占庭问题来说，假如节点总数为 N，故障节点数为 F，则当 N >= 3F + 1 时，问题才能有解，由 BFT 算法进行保证。
例如，N = 3，F = 1 时。
若提案人不是叛变者，提案人发送一个提案出来，收到的叛变者可以宣称收到的是相反的命令。则对于第三个人（忠诚者）会收到两个相反的消息，无法判断谁是叛变者，则系统无法达到一致。
若提案人是叛变者，发送两个相反的提案分别给另外两人，另外两人都收到两个相反的消息，无法判断究竟谁是叛变者，则系统无法达到一致。
更一般的，当提案人不是叛变者，提案人提出提案信息 1，则对于合作者来看，系统中会有 N - F 份确定的信息 1，和 F 份不确定的信息（可能为 0 或 1，假设叛变者会尽量干扰一致的达成），N − F > F，即 N > 2F 情况下才能达成一致。
当提案人是叛变者，会尽量发送相反的提案给 N - F 个合作者，从收到 1 的合作者看来，系统中会存在 (N - F)/2 个信息 1，以及 (N - F)/2 个信息 0；从收到 0 的合作者看来，系统中会存在 (N - F)/2 个信息 0，以及 (N - F)/2 个信息 1；
另外存在 F − 1 个不确定的信息。合作者要想达成一致，必须进一步的对所获得的消息进行判定，询问其他人某个被怀疑对象的消息值，并通过取多数来作为被怀疑者的信息值。这个过程可以进一步递归下去。
Leslie Lamport 等人在论文《Reaching agreement in the presence of faults》中证明，当叛变者不超过 1/3 时，存在有效的拜占庭容错算法（最坏需要 F+1 轮交互）。反之，如果叛变者过多，超过 1/3，则无法保证一定能达到一致结果。
那么，当存在多于 1/3 的叛变者时，有没有可能存在解决方案呢？
设想 F 个叛变者和 L 个忠诚者，叛变者故意使坏，可以给出错误的结果，也可以不响应。某个时候 F 个叛变者都不响应，则 L 个忠诚者取多数既能得到正确结果。当 F 个叛变者都给出一个恶意的提案，并且 L 个忠诚者中有 F 个离线时，剩下的 L - F 个忠诚者此时无法分别是否混入了叛变者，仍然要确保取多数能得到正确结果，因此，L - F > F，即 L > 2F 或 N - F > 2F，所以系统整体规模 N 要大于 3F。
能确保达成共识的拜占庭系统节点数至少为 4，此时最多允许出现 1 个坏的节点。
拜占庭容错算法
拜占庭容错算法（Byzantine Fault Tolerant）是面向拜占庭问题的容错算法，解决的是在网络通信可靠，但节点可能故障和作恶情况下如何达成共识。
拜占庭容错算法最早的讨论可以追溯到 Leslie Lamport 等人 1982 年 发表的论文《The Byzantine Generals Problem》，之后出现了大量的改进工作，代表性成果包括《Optimal Asynchronous Byzantine Agreement》（1992 年）、《Fully Polynomial Byzantine Agreement for n>3t Processors in t+1 Rounds》（1998 年）等。长期以来，拜占庭问题的解决方案都存在运行过慢，或复杂度过高的问题，直到“实用拜占庭容错算法”（Practical Byzantine Fault Tolerance，PBFT） 算法的提出。
1999 年，这一算法由 Castro 和 Liskov 于论文《Practical Byzantine Fault Tolerance and Proactive Recovery》中提出。该算法基于前人工作（特别是 Paxos 相关算法，因此也被称为 Byzantine Paxos）进行了优化，首次将拜占庭容错算法复杂度从指数级降低到了多项式级，目前已得到广泛应用。其可以在恶意节点不超过总数 1/3 的情况下同时保证 Safety 和 Liveness。
PBFT 算法采用密码学相关技术（RSA 签名算法、消息验证编码和摘要）确保消息传递过程无法被篡改和破坏。
算法整体的基本过程如下：
- 首先，通过轮换或随机算法选出某个节点为主节点，此后只要主节点不切换，则称为一个视图（View）。
- 在某个视图中，客户端将请求
- 所有节点处理完成请求，将处理结果
主节点广播过程包括三个阶段的处理：预准备（Pre-Prepare）、准备（Prepare）和提交（Commit）。预准备和准备阶段确保在同一个视图内请求发送的顺序正确；准备和提交阶段则确保在不同视图之间的确认请求是保序的。
- 预准备阶段：主节点为从客户端收到的请求分配提案编号，然后发出预准备消息
<给各副本节点，其中 message 是客户端的请求消息，digest 是消息的摘要。 - 准备阶段：副本节点收到预准备消息后，检查消息。如消息合法，则向其它节点发送准备消息
- 提交阶段：广播 commit 消息，告诉其它节点某个提案 n 在视图 v 里已经处于准备状态。如果集齐至少 2f+1 个验证过的 commit 消息，则说明提案通过。
具体实现上还包括视图切换、checkpoint 等机制，读者可自行参考论文内容，在此不再赘述。
拜占庭容错类的算法因为要考虑最恶意的存在“捣乱”者的情况，在大规模场景下共识性能往往会受到影响。
新的解决思路
拜占庭问题之所以难解，在于任何时候系统中都可能存在多个提案（因为提案成本很低），并且在大规模场景下要完成最终确认的过程容易受干扰，难以达成共识。
2014 年，斯坦福的 Christopher Copeland 和 Hongxia Zhong 在论文《Tangaroa: a byzantine fault tolerant raft》中提出在 Raft 算法基础上借鉴 PBFT 算法的一些特性（包括签名、恶意领导探测、选举校验等）来实现拜占庭容错性，兼顾可实现性和鲁棒性。该论文也启发了 Kadena 等项目的出现，实现更好性能的拜占庭算法。
2017 年，MIT 计算机科学与人工智能实验室（CSAIL）的 Yossi Gilad 和 Silvio Micali 等人在论文《Algorand: Scaling Byzantine Agreements for Cryptocurrencies》中针对 PBFT 算法在很多节点情况下性能不佳的问题，提出先选出少量记账节点，然后再利用可验证随机函数（Verifiable Random Function，VRF）来随机选取领导节点，避免全网直接做共识，将拜占庭算法扩展到了支持较大规模的应用场景，同时保持较好的性能（1000+ tps）。
此外，康奈尔大学的 Rafael Pass 和 Elaine Shi 在论文《The Sleepy Model of Consensus》中还探讨了在动态场景（大量节点离线情况）下如何保障共识的安全性，所提出的 Sleepy Consensus 算法可以在活跃诚实节点达到一半以上时确保完成拜占庭共识。
2018 年，清华大学的 Chenxing Li 等在论文《Scaling Nakamoto Consensus to Thousands of Transactions per Second》中提出了 Conflux 共识协议。该协议在 GHOST 算法基础上改善了安全性，面向公有区块链场景下，理论上能达到 6000+ tps。
比特币网络在设计时使用了 PoW（Proof of Work）的概率型算法思路，从如下两个角度解决大规模场景下的拜占庭容错问题。
首先，限制一段时间内整个网络中出现提案的个数（通过工作量证明来增加提案成本）；其次是丢掉最终确认的约数，约定好始终沿着已知最长的链进行拓展。共识的最终确认是概率意义上的存在。这样，即便有人试图恶意破坏，也会付出相应的经济代价（超过整体系统一半的工作量）。
后来的各种 PoX 系列算法，也都是沿着这个思路进行改进，采用经济博弈来制约攻击者。
可靠性指标
可靠性（Availability），或者说可用性，是描述系统可以提供服务能力的重要指标。高可靠的分布式系统，往往需要各种复杂的机制来进行保障。
通常情况下，服务的可用性可以用服务承诺（Service Level Agreement，SLA SLA）、服务指标（Service Level Indicator，SLI）、服务目标（Service Level Objective，SLO）等方面进行衡量。
几个 9 的指标
完美的可靠性是不存在的。很多领域里谈到服务的高可靠性，通常都会用“几个 9”的指标来进行衡量。
“几个 9”的指标，其实是概率意义上粗略反映了系统能提供服务的可靠性指标，最初是电信领域提出的概念。
下表给出不同指标下，每年允许服务出现不可用时间的参考值。
| 指标 | 概率可靠性 | 每年允许不可用时间 | 典型场景 |
|---|---|---|---|
| 一个 9 | 90% | 1.2 个月 | 简单测试 |
| 二个 9 | 99% | 3.6 天 | 普通单点 |
| 三个 9 | 99.9% | 8.6 小时 | 普通集群 |
| 四个 9 | 99.99% | 51.6 分钟 | 高可用 |
| 五个 9 | 99.999% | 5 分钟 | 电信级 |
| 六个 9 | 99.9999% | 31 秒 | 极高要求 |
| 七个 9 | 99.99999% | 3 秒 | N/A |
一般来说，单点的服务器系统至少应能满足两个 9；普通企业信息系统三个 9 就肯定足够了（大家可以统计下自己企业内因系统维护每年要停多少时间），系统能达到四个 9 已经是领先水平了（参考 AWS 等云计算平台）。电信级的应用一般需要能达到五个 9，这已经很厉害了，一年里面最多允许出现五分钟左右的服务不可用。六个 9 以及以上的系统，就更加少见了，要实现往往意味着极高的代价。
两个核心时间
一般地，描述系统出现故障的可能性和故障出现后的恢复能力，有两个基础的指标：MTBF 和 MTTR。
- MTBF：Mean Time Between Failures，平均故障间隔时间，即系统可以无故障运行的预期时间。
- MTTR：Mean Time To Repair，平均修复时间，即发生故障后，系统可以恢复到正常运行的预期时间。
MTBF 衡量了系统发生故障的频率，如果一个系统的 MTBF 很短，则往往意味着该系统可用性低；而 MTTR 则反映了系统碰到故障后服务的恢复能力，如果系统的 MTTR 过长，则说明系统一旦发生故障，需要较长时间才能恢复服务。
一个高可用的系统应该是具有尽量长的 MTBF 和尽量短的 MTTR。
提高可靠性
那么，该如何提升可靠性呢？有两个基本思路：一是让系统中的单个组件都变得更可靠；二是干脆消灭单点。
IT 从业人员大都有类似的经验，普通笔记本电脑，基本上是过一阵可能就要重启下；而运行 Linux/Unix 系统的专用服务器，则可能连续运行几个月甚至几年时间都不出问题。另外，普通的家用路由器，跟生产级别路由器相比，更容易出现运行故障。这些都是单个组件可靠性不同导致的例子，可以通过简单升级单点的软硬件来改善可靠性。
然而，依靠单点实现的可靠性毕竟是有限的。要想进一步的提升，那就只好消灭单点，通过主从、多活等模式让多个节点集体完成原先单点的工作。这可以从概率意义上改善服务对外整体的可靠性，这也是分布式系统的一个重要用途。
本章小结
分布式系统是计算机学科中十分重要的一个领域。随着集群规模的不断增长，所处理的数据量越来越大，对于性能、可靠性的要求越来越高，分布式系统相关技术已经变得越来越重要，起到的作用也越来越关键。
分布式系统中如何保证共识是个经典问题，无论在学术上还是工程上都存在很高的研究价值。令人遗憾地是，理想的（各项指标均最优）解决方案并不存在。在现实各种约束条件下，往往需要通过牺牲掉某些需求，来设计出满足特定场景的协议。通过本章的学习，读者可以体会到在工程应用中的类似设计技巧。
实际上，工程领域中不少问题都不存在一劳永逸的通用解法；而实用的解决思路，都在于合理地在实际需求和条件限制之间进行灵活的取舍（trade-off）。