从分布式一致性算法到区块链共识算法(一)

从分布式一致性算法到区块链共识算法(一)

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

一致性问题

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

一致性要求

  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张图片

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

应用场景

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

你可能感兴趣的:(共识算法,区块链,共识算法,区块链)