分布式共识的工作原理,Part-2:共识问题与 FLP 不可能定理

Part-1:分布式系统的定义及属性


在分布式系统中,达成共识意味着什么

目前,我们已经知道分布式系统有以下特性:

  • 进程的并发性
  • 全局时钟缺失
  • 组件可能出错
  • 消息需时传递

接下来我们会聚焦分布式系统中,“达成共识”究竟是什么意思。首先有一件很重要的事情得重申一下,“分布式计算有数百种软硬件架构”;而最常见的形式称为复制状态机。

复制状态机

复制状态机是一种确定性状态机,它在许多计算机上存有副本,但整个系统就像单个状态机那样运行。任何一台计算机都有出错的可能,但状态机依然能正常运行。

-作者制图-

在复制状态机中,如果出现一个有效事务(transaction),则事务的输入集会使得系统的状态转变为下一个状态。事务对数据库进行原子性的操作,这意味着操作要么整个完成,要么等于完全没发生。在复制状态机内维护的事务集合又称为“事务日志”;从一个有效状态转变为下一个有效状态的逻辑,称为“状态转变逻辑”。

-作者制图-

换言之,复制状态机是一个分布式计算机的集合,这些计算机都有相同初值。每一次状态的转变方式、下个状态是什么,都由相关的进程决定。所谓“达成共识”,意思是全体计算机都同意某个输出的值

反过来说,“达成共识”也意味着让系统中每一台计算机的事务日志保持一致(也就是它们“达成了共同目标”)。合格的复制状态机,即使发生以下情况,仍必须不断将新的事务接收进日志(即“提供有效服务”):

  1. 有些计算机发生故障。
  2. 网络不可靠,消息可能出现延迟、传送失败,或排序混乱。
  3. 没有全局时钟来确定事务顺序。

朋友们,这就是所有共识算法的基本目标。

6

-作者制图-

共识问题的定义

只要能满足以下条件,我们就说某算法可以实现分布式共识:

  1. Agreement(一致性) :所有非故障节点,都会选择相同的输出值。
  2. Termination(可终止性):所有非故障节点,最终都选定了某些输出值,不再反悔。

注意:不同的算法会满足上述条件的不同变体。举例来说,某些算法会将 Agreement 拆分为一致性和总体性;一些算法还加入了有效性(validity)、完整性(integrity),或效率的概念。这些细微的区别不在本文讨论范围。

广义来说,共识算法一般会假设系统中有三种角色:

  1. 提案者(Proposers):常被称为领导者或协调者。
  2. 接收者(Acceptors):进程,监听提案者的请求并给出响应值。
  3. 学习者(Learners):系统里的其他进程,接收最终决定的值。

因此,正常情况下,我们能通过三个步骤定义来共识算法:

第一步:选举 Elect

  • 所有进程推举出某个进程(领导者)来做决策。
  • 领导者提出下一个有效的输出值。

第二步:投票 Vote

  • 非故障进程会监听领导者进程提出的值,并验证这个值。然后将它作为下一个有效值提出。

第三步:决定 Decide

  • 非故障节点必须就单个正确的值达成共识。如果这个值收到满足某个阈值条件的投票数,那么全体进程就会同意这个值为最终共识值。
  • 如果没有达到条件,则重新进行上面步骤。

7

8

9

10

11

-作者制图-

值得注意的是,每个共识算法都会有些许不同,比如:

  • 术语(如,轮次(round)、阶段(phase))
  • 投票如何进行的,以及
  • 决定最终值的标准(例如:验证条件)。

尽管如此,如果我们能以通用的过程构造共识算法,并保证满足上述的基本条件,那我们就有了一个能够达成共识的分布式系统。

你以为非常简单,对吧?

FLP 不可能定理

......并非如此,说不定你已经预见到了!

回想一下,我们是如何描述同步系统和异步系统之间的区别的:

  • 同步通信情况下,消息会在固定时间范围内发送。
  • 异步通信情况下,无法保证消息的传递。

这个差异非常重要。

在同步通信环境下有可能达成共识,因为我们能够假设消息传递需要的最长时间。因此在同步消息系统,我们允许不同的节点轮流成为提案者、进行多数投票,并跳过那些没有在最长等待时间内提交提案的节点。

但正如我们前面提到的,跳脱出可控(即消息延时可以预测)的环境(比如,具有同步原子钟的数据中心之类的可控环境),假设操作发生在同步通信环境里是不切实际的

事实上,多数时候我们无法假设同步通信,所以我们的设计必须面向异步通信环境。

在异步通信环境中,因为我们无法假设一个最大的消息传递时间,想要达成 termination 条件是非常困难的。回忆下,要达成共识的其中一项条件是“可终止性”,也就是说每个非故障节点最终都必须选定某组相同的输出值,而不能永远迟疑不决。

这也就是大家熟知的“ FLP 不可能性 ”。它是怎么得到这个名字的?我很高兴你这么问了。

1985年,研究员 Fischer、Lynch 和 Paterson (FLP)在他们的论文《Impossibility of Distributed Consensus with One Faulty Process》中描述了为什么在异步通信环境下,单个进程故障也会导致共识无法达成。

简单来说,因为进程可能在任何时间出错,所以也有可能发生在正好会影响共识达成的时间点。

-亮点自寻-

这个结果对分布式计算领域带来重大打击,但即使如此,科学家仍在不断尝试避开 FLP 不可能性问题的方法。

抽象一点来说,有两个方法能够避开 FLP 不可能性问题:

  1. 使用同步性假设
  2. 使用非确定性机制

(未完)


Part-3:使用同步假设的共识算法
Part-4:非确定性共识算法


原文链接: https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95
作者: Preethi Kasireddy

  • 6
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
什么是共识算法背景分布式系统集群设计中面临着一个不可回避的问题,一致性问题对于系统中的多个服务节点,给定一系列操作,如何试图使全局对局部处理结果达成某种程度的一致?这个一致性问题大致有如下的场景:节点之间通讯不可靠的,延迟和阻塞节点的处理可能是错误的,甚至节点自身随时可能宕机节点作恶举例说明,就比如有两家电影院同时售卖总量一定的电影票,在这样的场景下,要如何设计方式来保证两家电影院协调同步不出现超卖或者错卖的问题呢?共识算法,就是解决对某一提案(目标,投票等各种协作工作),大家达成一致意见的过程比如上述的买票问题,就可以有如下的设计:1.每次卖票打电话给其他电影院,确认当前票数2.协商售卖时间,比如一三五A卖,二四六B卖3.成立个第三方存票机构,它统一发票通过以上的设计,可以看出一个很重要的解决一致性算法的解决思路,即:将可能引发不一致的并行操作进行串行化,就是现在计算机系统里处理分布式一致性问题基础思路和唯一秘诀著名的共识设计理论FLP可能性原理  共识算法的理论下限提出该定理的论文是由 Fischer, Lynch 和 Patterson 三位作者于 1985 年发表,该论文后来获得了 Dijkstra(就是发明最短路径算法的那位)奖。FLP 原理认为对于允许节点失效情况下,纯粹异步系统无法确保一致性在有限时间内完成。三人三房间投票例子三个人在不同房间,进行投票(投票结果是 0 或者 1)。三个人彼此可以通过电话进行沟通,但经常会有人时不时地睡着。比如某个时候,A 投票 0,B 投票 1,C 收到了两人的投票,然后 C 睡着了。A 和 B 则永远无法在有限时间内获知最终的结果。如果可以重新投票,则类似情形每次在取得结果前发生带入到计算机领域就是说,即便在网络通信可靠情况下,一个可扩展的分布式系统的共识问题的下限是无解。即可靠性的下限是0%CAP  分布式系统领域的重要原理CAP 原理最早由 Eric Brewer 在 2000 年,ACM 组织的一个研讨会上提出猜想,后来 Lynch 等人进行了证明• C(一致性):所有的节点上的数据时刻保持同步,即数据一致• A(可用性):每个请求都能在一定时间内接受到一个响应,即低延迟• P(分区容错):当系统发生分区时仍然可以运行的定理:任何分布式系统只可同时满足二点,没法三者兼顾。即数据一致,响应及时,可分区执行不可能同时满足。举个例子:一个分布式网路上,某一个节点有一组依赖数据A,当网络无延迟,无阻塞时,依赖于X的操作可正常进行。但网络无延迟阻塞在现实世界中是没法100%保证的,那么当网络异常时,必然会产生分布式系统的分区和孤岛,那当一个执行操作在A分区之外时,如果要保证P,即当系统发生分区时仍可运行,就需要在分布式系统中多个节点有X的备份数据,以应对分区情况。则这时候就需要在C,A之间做出选择。假如选择C,即要保证数据在分布式网络中的一致性,那么就需要在X每次改动时,需要将全网节点的X数据同步刷新成最新的状态,那么在等待数据刷新完成之前,分布式系统是不可响应X的依赖操作的,即A的功能缺失假如选择A,即要突出低延迟的实时响应。那么在响应的时候,可能全节点的X数据并没有同步到最新的状态,则会导致C的缺失。上面看上去有些绕,那么你只要记住这句话,CAP原理在分布式网络系统的应用讨论,其实就是讨论在允许网络发生故障的系统中,该选择一致性还是可靠性?如果系统重视一致性,那么可以基于ACID原则做系统设计即 Atomicity(原子性)、Consistency(一致性)、Isolation(隔离性)、Durability(持久性)。ACID 原则描述了对分布式数据库的一致性需求,同时付出了可用性的代价。• Atomicity:每次操作是原子的,要么成功,要么不执行;• Consistency:数据库的状态是一致的,无中间状态;• Isolation:各种操作彼此互相不影响;• Durability:状态的改变是持久的,不会失效相应的有一个BASE原则,(Basic Availiability,Soft state,Eventually Consistency)则强调了可用性。经典的共识算法设计业内,针对节点异常的情况,会有两种分类1.故障的,不响应的节点,成为非拜占庭错误2.恶意响应的节点,称为非拜占庭错误Paxos 最早的共识算法  非拜占庭算法的代表Paxos有三种角色:• proposer:提出一个提案,等待大家批准为结案。客户端担任该角色;• acceptor:负责对提案进行投票。往往是服务端担任该角色;• learner:被告知结案结果,并与之统一,不参与投票过程。即普通节点系统运行由proposer驱动,当合法提案在一定时间内收到1/2以上投票后达成共识。 

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

web3.0前沿技术研究者

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值