从分布式一致性算法到区块链共识算法（一）_一般来讲,强一致性

从分布式一致性算法到区块链共识算法（一）

本文主要参考书籍：区块链原理、设计与应用第二版

一致性问题

一致性问题是分布式领域最为基础也是最重要的问题。 如果分布式系统能实现“一致”， 对外就可以呈现为一个完美的、可扩展的“虚拟节点”，相对物理节点具备更优越性能和稳 定性 。 这也是分布式系统希望能实现的最终目标。

一致性要求

1. 可终止性（ termination ）：一致的结果在有限时间内能完成；
2. 约同性（ agreement）：不同节点最终完成决策的结果是相同的；
3. 合法性（ validity）：决策的结果必须是某个节点提出的提案 。

带约束的一致性

要实现绝对理想的严格一致性（ strict consistency）代价很大 。 除非系统不发生任何故障，而且所有节点之间的通信无需任何时间，这个时候整个系统其实就等价于一台机器了 。
实际上，越强的一致性要求往往会造成越弱的处理性能，以及越差的可扩展性 。

一般来讲，强一致性（ strong consistency）主要包括下面两类：

1. 顺序一致性（ sequential consistency) : Leslie Lamport 在 1979 年的经典论文 《 How toMake a Multiprocessor Computer That Correctly Executes
   Multiprocess Programs 》 中提出，是一种比较强的约束，保证所有进程看到的全局执行顺序（ total order ）
   一致，并且每个进程看自身的执行顺序（ local order）跟实际发生顺序一致。 例如，某进程第 4 重分布式系统核心问题 令 37先执行
   A ，后执行 B ，则实际得到的全局结果中就应该为 A 在 B 前面，而不能反过来 。 同时所有其他进程在全局上也应该看到这个顺序 。
   顺序一致性实际上限制了各进程内指令的偏序关系，但不在进程间按照物理时间进行全局排序；
2. 线性一致性（ linearizability consistency) : Maurice P. Herlihy 与 Jeannette M. Wing 在1990 年的经典论文 《 Linearizability: A Correctness
   Condition for Concurrent Objects
   中共同提出，在顺序一致性前提下加强了进程间的操作排序，形成唯一的全局顺序（系统等价于是顺序执行，所有进程看到的所有操作的序列顺序都一致，并且跟实际发生顺序一致），是很强的原子性保证。
   但是比较难实现，目前基本上要么依赖于全 局的时钟或锁，要么通过一些复杂算法实现，性能往往不高 。

由于强一致性的系统往往比较难实现，而且很多时候，实际需求并没有那么严格需要 强一致性 。 因此，可以适当地放宽对一致性的要求，从而降低系统实现的难度 。 例如在一定约束下实现所谓最终一致性（ eventual
consistency），即总会存在一个时刻（而不是立刻），让系统达到一致的状态 。 大部分 Web 系统实现的都是最终一致性 。
相对强一致性，这一类在某些方面弱化的一致性都笼统称为弱一致性（weak consistency ） 。

FLP不可能定理

定义

FLP 不可能原理： 在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型 系统中，不存在一个可以解决一致性问题的确定性共识算法（ No completely asynchronous consensus
protocol can tolerate even a single unannounced process death ） 。

FLP 不可能原理实际上告诉人们，不要浪费时间，去为异步分布式系统设计在任意场 景下都能实现共识的算法。

正确理解

FLP不可能定理的最大适用前提是异步网络模型。何为同步、异步模型呢？

1. 所谓异步模型，是说从一个节点到另一个节点的消息延迟是有限的，但可能是无界的（finite but can be unbounded）。这就意味着如果一个节点没有收到消息，它无法判断消息到底是丢失了，还是只是延迟了。也就是说，我们无法通过超时时间来判断某个节点是否故障。
2. 所谓同步模型，是说消息传递的延迟是有限的，且是有界的。这就意味着我们可以通过经验或采样精确估算消息的最大可能延迟，从而可以通过超时时间来确定消息是否丢失、节点是否故障。
   综上所述，在分布式系统中，同步和异步这两个术语存在特殊的含义 。 同步是指系统中的各个节点的时钟误差存在上限；并且消息传递必须在一定时间
   内完成， 否则认为失败 ；同时各个节点完成处理消息的时间是一定的 。 对于同步系统，可以很容易地判断消息是否丢失 。
   异步是指系统中各个节点可能存在较大的时钟差异，同时消息传输时间是任意长的，各节点对消息进行处理的时间也可能是任意长的，这就造成无法判断某个消息迟迟没有被响应是哪里出了问题（节点故障还是传输故障？）
   。

如何规避“FLP不可能定理”

研究者们通过调整问题模型来规避“FLP 不可能定理”从而寻找工程上可行的共识算法, 比如比特币系统中通过假定网络为弱同步性, 即网络节点间可以快速同步,以及矿工在一个区块上投入有限的时间等来规避“FLP
不可能定理”。通过调整问题模型规避“FLP 不可能定理”, 使得共识算法存在“工程解”。

CAP定理

定义

分布式系统无法同时满足一致性 (Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance), 最多只能同时满足其中两个特性, 如下图所示。

1. 一致性是指分布式系统中所有节点在同一时刻持有同样的数据信息，而且任何操作应该都是原子的，发生在后面的事件能看到前面事件发生导致的结果，注意这里指的是强一致性；
2. 可用性是指系统处于服务状态, 当客户端发出请求, 服务端能在有效的时间内返回结果；
3. 分区容忍性是指允许网络中部分节点不与其他节点通信,即允许网络发生分区(不同区域之间的节点不能建立通信)。

应用场景

1. 弱化一致性
   对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才最终更新成功， 期间不保证一致性 。 例如网站静态页面内容 、 实时性较弱的查询类数据库等，简单分布式同步协议如 Gossip ，以及 CouchDB 、 Cassandra 数据库等，都是为此设计的 。
2. 弱化可用性
   对结果 一 致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务 。 MongoDB 、 Redis 、MapReduce 等是为此设计的 。 Paxos 、 Raft 等共识算法，主要处理这种情况 。在 Paxos
   类算法中，可能存在着无法提供可用结果的情形，同时允许少数节点离线 。
3. 弱化分区容忍性
   现实中，网络分区出现概率较小，但较难完全避免。 两阶段的提交算法，某些关系型 数据库及 ZooKeeper 主要考虑了这种设计。 实践中，网络可以通过双通道等机制增强可靠性，达到高稳定的网络通信。