分布式一致性带约束的一致性FLP 不可能性和CLP原理的知识汇总（初谈）

Posted 2021-04-24 区块链兄弟

▲点击蓝字，轻松关注

文章整理：小链
区块链兄弟——技术专业问答先行者，区块链爱好者聚集地

本文约3000字，阅读（观看）需要22分钟

分布式一致性

什么是分布式一致性，简言之一个规范的分布式的一致性算法应该满足：

带约束的一致性

做过分布式系统的读者应该能知道：绝对理想的一致性很难达成。除非不发生任何故障，所有节点之间的通信无需任何时间，这个时候其实就等价于一台机器了。实际上，越强的一致性要求往往意味着越弱的性能。

很多时候，人们发现对一致性可以适当放宽一些要求，在一定约束下实现一致性，从弱到强分别有如下几种：

1.顺序一致性（Sequential Consistency）：Leslie Lamport 1978 年提出，是一种较弱的约束，保证所有进程自身执行的实际结果跟指定的指令顺序一致。例如，某进程先执行A，后执行 B，则实际得到的结果就应该为 A, B ，而不能是 B, A ，所有其它进程也应该看到这个顺序，但不保证什么时候能看到。顺序一致性实际上只限制了各进程内指令的偏序关系，不在进程间进行排序。

2.线性一致性（Linearizability Consistency）：Maurice P. Herlihy 与 Jeannette M. Wing在 1990 年共同提出，在顺序一致性前提下加强了进程间的操作排序，形成唯一的全局顺序（系统等价于是顺序执行，所有进程看到的所有操作的序列顺序都一致），是很强的原子性保证。但是很难实现，基本上要么依赖于全局的时钟或锁（原子钟是个简单粗暴但有效的主意），要么性能比较差。

FLP 不可能性

FLP 不可能原理又是什么？在网络可靠，存在节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性算法。 理解这一原理的一个不严谨的例子是：

三个人在不同房间，进行投票（投票结果是 0 或者 1）。三个人彼此可以通过电话进行沟通，但经常会有人时不时地睡着。比如某个时候，A 投票 0，B 投票 1，C 收到了两人的投票，然后 C 睡着了。A 和 B 则永远无法在有限时间内获知最终的结果。如果可以重新投票，则类似情形每次在取得结果前发生：（FLP 原理实际上说明对于允许节点失效情况下，纯粹异步系统无法确保一致性在有限时间内完成。

这岂不是意味着研究一致性问题压根没有意义吗？

先别这么悲观，学术界做研究，考虑的是数学和物理意义上最极端的情形，很多时候现实生活要美好的多（感谢这个世界如此鲁棒！）。例如，上面例子中描述的最坏情形，总会发生的概率并没有那么大。工程实现上多试几次，很大可能就成功了。
学术告诉你什么是不可能的；工程则告诉你，付出一些代价，我可以把它变成可能。这就是工程的魅力。

那么，退一步讲，在付出一些代价的情况下，我们能做到多少？

回答这一问题的是另一个很出名的原理：CAP 原理。

学术上告诉你去赌场赌博从概率上总会是输钱的；工程则告诉你，如果你接受最终输钱的话，中间说不定偶尔能小赢几笔呢！？

CLP原理

分布式一致性告诉我们，计算系统不可能同时确保一致性（Consistency）、可用性（Availablity）和分区容忍性（Partition）。

1、一致性（Consistency）：任何操作应该都是原子的，发生在后面的事件能看到前面事件发生导致的结果；
2、可用性（Availablity）：在有限时间内，任何非失败节点都能应答请求；
3、分区容忍性（Partition）：网络可能发生分区，即节点之间的通信不可保障。

比较直观地理解，当网络可能出现分区时候，系统是无法同时保证一致性和可用性的。要么，节点收到请求后因为没有得到其他人的确认就不应答，要么节点只能应答非一致的结果。

好在大部分时候网络被认为是可靠的，因此系统可以提供一致可靠的服务；当网络不可靠时，系统要么牺牲掉一致性（大部分时候都是如此），要么牺牲掉可用性。

应用，既然 CAP 不可同时满足，则设计系统时候必然要弱化对某个特性的支持。

不保证一致性
对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才更新成功，期间不保证一致性。例如网站静态页面内容、实时性较弱的查询类数据库等。

不保证可用性
对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。Paxos、Raft 等算法的设计目标。

不保证分区容忍性
现实中，网络分区出现概率减小，但较难避免。网络通过双通道等机制增强可靠性，达到高稳定的网络通信。    

---

热文推荐

• 
  

• 
  

---

---

区块链兄弟——技术专业问答先行者，区块链爱好者聚集地

请点击“阅读原文”参与讨论，赚取积分兑换知识大礼包