分布式之flp、cap、base理论、一致性问题、共识算法

一、CAP理论

CAP理论:在一个分布式系统中,最多只能满足C、A、P中的2个。

CAP含义:

C:Consistency 一致性:同一数据的多个副本是否实时相同。all nodes see the same data at the same time

A:Availability 可用性:一定时间内,系统能返回一个明确的结果 则称为该系统可用。Reads and writes always succeed

P:Partition tolerance 分区容错性:分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。the system continues to operate despite arbitrary message loss or failure of part of the system

而通常情况下,我们都必须要满足AP,所以只能牺牲C。

牺牲一致性换取可用性和分区容错性。

牺牲一致性的意思是,把强一致换成弱一致。只要数据最终能一致就好了,并不要实时一致。

二、BASE理论

主要就是分布式系统中最CAP怎么取舍怎么平衡的一个理论

BA:Basic Available 基本可用

基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。

基本可用BA和高可用HA的区别是:

1.响应时间可以更长。

2.给部分用户返回一个降级页面。返回降级页面仍然是返回明确结果。

S:Soft State:柔性状态。同一数据的不同副本的状态,不用实时一致

E:Eventual Consisstency:最终一致性。 同一数据的不同副本的状态,不用实时一致,但一定要保证经过一定时间后最终是一致的。

三、FLP

参考:https://wohugb.github.io/blockchain_guide/distribute_system/flp/

1.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 不可能原理告诉我们,不要浪费时间,去试图为异步分布式系统设计面向任意场景的共识算法

2.在分布式系统中,同步和异步这两个术语存在特殊的含义

同步

是指系统中的各个节点的时钟误差存在上限;

并且消息传递必须在一定时间内完成,否则认为失败;

同时各个节点完成处理消息的时间是一定的。

因此同步系统中可以很容易地判断消息是否丢失。

异步

则意味着系统中各个节点可能存在较大的时钟差异;

同时消息传输时间是任意长的;

各节点对消息进行处理的时间也可能是任意长的。

这就造成无法判断某个消息迟迟没有被响应是哪里出了问题(节点故障还是传输故障?)。

不幸地是,现实生活中的系统往往都是异步系统。

3.理解这一原理的一个不严谨的例子是:

三个人在不同房间,进行投票(投票结果是 0 或者 1)。三个人彼此可以通过电话进行沟通,但经常会有人时不时地睡着。比如某个时候,A 投票 0,B 投票 1,C 收到了两人的投票,然后 C 睡着了。A 和 B 则永远无法在有限时间内获知最终的结果。如果可以重新投票,则类似情形每次在取得结果前发生:(

FLP 原理实际上说明对于允许节点失效情况下,纯粹异步系统无法确保一致性在有限时间内完成。

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

先别这么悲观,学术界做研究,考虑的是数学和物理意义上最极端的情形,很多时候现实生活要美好的多(感谢这个世界如此鲁棒!)。例如,上面例子中描述的最坏情形,总会发生的概率并没有那么大。工程实现上多试几次,很大可能就成功了。

科学告诉你什么是不可能的;工程则告诉你,付出一些代价,我可以把它变成可能。

这就是工程的魅力。

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

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

科学上告诉你去赌场赌博从概率上总会是输钱的;工程则告诉你,如果你愿意接受最终输钱的结果,中间说不定偶尔能小赢几笔呢!?

四、一致性问题

https://wohugb.github.io/blockchain_guide/distribute_system/problem/

1.定义:

在分布式系统中,一致性(Consistency,早期也叫 Agreement)是指对于系统中的多个服务节点,给定一系列操作,在协议(往往通过某种共识算法)保障下,试图使得它们对处理结果达成某种程度的一致。

如果分布式系统能实现“一致”,对外就可以呈现为一个功能正常的,且性能和稳定性都要好很多的“虚处理节点”。

注意:一致性并不代表结果正确与否,而是系统对外呈现的状态一致与否,例如,所有节点都达成失败状态也是一种一致。

2.分布式系统中一致性面临的挑战

在实际的计算机集群系统中,存在如下的问题:

  • 节点之间的网络通讯是不可靠的,包括任意延迟和内容故障;
  • 节点的处理可能是错误的,甚至节点自身随时可能宕机;
  • 同步调用会让系统变得不具备可扩展性。

3.满足一致性需要达到的条件

规范的说,理想的分布式系统一致性应该满足:

  • 可终止性(Termination):一致的结果在有限时间内能完成;
  • 共识性(Consensus):不同节点最终完成决策的结果应该相同;
  • 合法性(Validity):决策的结果必须是其它进程提出的提案。

第一点很容易理解,这是计算机系统可以被使用的前提。需要注意,在现实生活中这点并不是总能得到保障的,例如取款机有时候会是“服务中断”状态,电话有时候是“无法连通”的。

第二点看似容易,但是隐藏了一些潜在信息。算法考虑的是任意的情形,凡事一旦推广到任意情形,就往往有一些惊人的结果。例如现在就剩一张票了,中关村和西单的电影院也分别刚确认过这张票的存在,然后两个电影院同时来了一个顾客要买票,从各自“观察”看来,自己的顾客都是第一个到的……怎么能达成结果的共识呢?记住我们的唯一秘诀:核心在于需要把两件事情进行排序,而且这个顺序还得是大家都认可的

第三点看似绕口,但是其实比较容易理解,即达成的结果必须是节点执行操作的结果。仍以卖票为例,如果两个影院各自卖出去一千张,那么达成的结果就是还剩八千张,决不能认为票售光了。

4.带约束的一致性

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

一般的,强一致性(Strong 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 前面,而不能反过来。同时所有其它进程在全局上也应该看到这个顺序。顺序一致性实际上限制了各进程内指令的偏序关系,但不在进程间按照物理时间进行全局排序。
  • 线性一致性(Linearizability Consistency):Maurice P. Herlihy 与 Jeannette M. Wing 在 1990 年经典论文《Linearizability: A Correctness Condition for Concurrent Objects》中共同提出,在顺序一致性前提下加强了进程间的操作排序,形成唯一的全局顺序(系统等价于是顺序执行,所有进程看到的所有操作的序列顺序都一致,并且跟实际发生顺序一致),是很强的原子性保证。但是比较难实现,目前基本上要么依赖于全局的时钟或锁,要么通过一些复杂算法实现,性能往往不高。

强一致的系统往往比较难实现。很多时候,人们发现实际需求并没有那么强,可以适当放宽一致性要求,降低系统实现的难度。例如在一定约束下实现所谓最终一致性(Eventual Consistency),即总会存在一个时刻(而不是立刻),系统达到一致的状态,这对于大部分的 Web 系统来说已经足够了。这一类弱化的一致性,被笼统称为弱一致性(Weak Consistency)。

五、共识算法

1.定义

实际上,要保障系统满足不同程度一致性,往往需要通过共识算法来达成。

共识算法解决的是对某个提案(Proposal),大家达成一致意见的过程。提案的含义在分布式系统中十分宽泛,如多个事件发生的顺序、某个键对应的值、谁是领导……等等,可以认为任何需要达成一致的信息都是一个提案。

注:实践中,一致性的结果往往还需要客户端的特殊支持,典型地通过访问足够多个服务节点来验证确保获取共识后结果。

2.问题挑战

实际上,如果分布式系统中各个节点都能保证以十分强大的性能(瞬间响应、高吞吐)无故障的运行,则实现共识过程并不复杂,简单通过多播过程投票即可。

很可惜的是,现实中这样“完美”的系统并不存在,如响应请求往往存在时延、网络会发生中断、节点会发生故障、甚至存在恶意节点故意要破坏系统。

一般地,把故障(不响应)的情况称为“非拜占庭错误”恶意响应的情况称为“拜占庭错误”(对应节点为拜占庭节点)

3.常见算法

针对非拜占庭错误的情况,一般包括 Paxos、Raft 及其变种。

对于要能容忍拜占庭错误的情况,一般包括 PBFT 系列、PoW 系列算法等。从概率角度,PBFT 系列算法是确定的,一旦达成共识就不可逆转;而 PoW 系列算法则是不确定的,随着时间推移,被推翻的概率越来越小。