引言

随着互联网的快速发展,人们对于互联网的依赖性越来越强,同时这也意味着黑客的攻击能够获得更高的收益以及造成更大的破坏力。与此同时,软件自己也会出现错误,恶意攻击和软件的错误都会导致故障节点出现任意的行为。 Leslie Lamport在1982年描述了拜占庭将军问题,生动地描述了分布式系统中出现任意行为节点后的共识问题。并且证明了将军总数大于3f,背叛者为f或者更少时,忠诚的将军可以达成行动上的一致。Barbara Liskov[1]在1999年提出了实用拜占庭容错,即PBFT算法,该算法的容错数量也是在3f+1节点中可以容忍f个错误节点,并且解决了原始拜占庭算法效率不高以及基于同步假设的问题。FLP不可能定理是Michael J. Fischer[2]等人在1985年提出的,该定理证明了在异步系统中,哪怕只有一个错误进程,分布式系统中都不能实现一个确定性的共识算法。CAP定理由Eric Brewer[3]在1998年提出,该定理是分布式系统的一个基本定理,它指出了分布式系统中,最多具有一致性、可用性、分区容错这三个特性中的两个,因此分布式系统设计需要做出取舍。本文分析了PBFT算法是怎样绕开FLP不可能定理从而实现确定性的共识算法,以及PBFT算法在CAP中式如何取舍的,最后分析了PBFT算法中的定时器机制对异步网络的影响。

FLP与CAP定理

Michael J. Fischer等在《Impossibility of Distributed Consensus with One Faulty Process》一文中,证明了在一个异步的分布式系统中,即使只有一个节点出现错误,也会导致系统存在不能达成共识的可能性,因此称具有一个错误进程的分布式共识算法是不可能的。

文章在证明时对系统做出了如下假设:

异步的分布式系统;

如果节点出现故障,则只会沉默;

消息传递可靠,能够正确且准确地一次传递所有消息;

系统不对节点地传递速度和延迟时间进行假设,并且不使用基于超时的算法,因此节点不能够判断其他节点是否发生故障或者只是运行较慢。

文章通过证明三个引理,得出了最后的结果:

引理Ⅰ 在任何一个状态下连续执行两个操作,不论顺序如何,得到的状态都是相同的。

引理Ⅱ 任何算法的初始状态都是一个不确定的状态

引理Ⅲ 从一个不确定的状态执行一些操作之后,仍然可能得到一个不确定的状态。

这里提到的不确定的状态,是指在这个状态下向后执行的结果仍然不能确定。引理Ⅰ用来证明了引理Ⅱ和Ⅲ,通过引理Ⅱ和Ⅲ可以得知,任何算法都是由不确定的状态开始执行,并且存在执行完仍然是不确定的状态的可能性。因此可以构建无限次事件序列的运行,导致系统永远都不会做出任何决定,这样就证明了确定性共识算法的不可能性。

可以通过一个例子来更好地理解:战场上有五个将军ABCDE,某一时刻,AB认为此刻应该出兵,DE认为此刻应该按兵不动,而C将军此时因为种种原因出现了故障,无法表达自己的意见,各位将军互相传送消息之后,会发现出现平票的情况,因此无法做出决定,而下一时刻C从故障中回归正常,并且认为应该出兵,但B却出现了故障,这种情况下仍然无法做出决定,如果系统的状态一直在这两种情况之间切换,那么就永远无法达成共识。如图1所示:

图1 错误节点导致的故障

然而,PBFT算法实现了系统的共识,接下来讨论它是如何绕过FLP不可能定理实现确定性共识的。

Barbara Liskov在提出PBFT时对系统做了如下假设:

异步的分布式系统;

节点传输的信息可能被丢失、延迟、重放、乱序;

每个节点的失效都是独立发生的,不会影响其他节点;

使用加密算法来防止欺骗和重播;

攻击者可以操控多个失效节点,并且能够延迟正确节点的通信,但是不能够无限期地延迟正确节点。算力不足以破解加密算法,因此不能伪造签名以及反推消息内容。

与此同时,文章中还提到:算法不依赖同步来提供安全性。因此,它必须依靠同步来提供活性;否则,它可以用于在异步系统中实现一致性,这是不可能的。这句话的理论依据其实就是FLP不可能定理,然而PBFT假设的系统模型是异步的,这里依靠的同步与假设的异步模型是否存在冲突呢?

我们可以注意到,FLP不可能定理中一个很关键的条件就是异步系统,PBFT算法同样假设是异步网络,但是为了绕开FLP不可能定理,在客户端和背景节点中加入了定时器机制,从而产生了超时系统,这就打破了FLP定理中异步且不使用基于超时算法的条件,将异步网络变成了不完全的异步网络,或者说弱同步网络,从而实现了确定性的共识,我们将在后文对定时器进行讨论。

CAP定理,又被称作布鲁尔定理,是分布式系统中的一个基本定理。它指出:任何分布式系统中,最多具有一致性、可用性、分区容错这三个特性中的两个。也就是说,三个特性无法兼顾,必须有所取舍。如图2所示:

图2 CAP定理示意图

这里的C是指Consistency即一致性,即访问系统中所有节点得到的数据应该是一样的(定理中的一致性指的是强一致性,即数据更新完,访问任何的节点看到的数据都要完全一致);A是指Availability即可用性,所有节点都保持高可用性,这里的高可用包括不能出现延迟,如果说节点由于等待数据同步而阻塞请求,那么其就不满足高可用性,就是说任何没有故障的服务器必须在有限的时间内返回合理的结果;P是指Partition tolerance即分区容忍性,这里的分区指的是网络意义上的分区,由于网络是不可靠的,所有节点之间很可能出现无法通讯的情况,在节点不能通信时,要保证系统可以继续正常服务。以实际效果而言,分区相当于对通信的时限要求。。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,这时就必须要在C和A中做出选择。

CAP定理告诉我们,在设计系统时不要将精力浪费在如何设计出能够满足三者的完美的分布式系统,而是要通过合理地取舍实现需求。虽然CAP定理定义是三个要素中只能取两个,但是在分布式环境中,因为网络无法做到完全可靠,从而就会产生故障,因此分区是一个必然的现象。如果选择CA而放弃P,那么在发生分区现象时,为了保证C,系统需要禁止写入,这又与A冲突。因此分布式系统理论上不可能选择CA,只能选择CP或者AP。

同理,PBFT的目标就是在具有拜占庭节点的分布式系统中实现容错,因此分区容错P是必须要保证的。与此同时,PBFT算法通过pre-prepare、prepare、commit的互相确认过程,保证了系统的一致性C。但是单纯从系统回复客户端信息的速度来看,这种行为实际上是减慢了系统对信息的处理速度,增加了系统回复客户端所需的时间,是对可用性A做出了牺牲。同时,在拥有3f+1节点系统中,如果错误节点的数量大于f,那么系统就不能够继续执行客户端的请求,从这个角度来看也是牺牲了可用性而保证了一致性。

定时器

前文中我们提到,PBFT的定时器机制使其在异步网络中绕过了FLP不可能定理,从而实现了确定性的共识算法。接下来我们来讨论定时器设计的巧妙之处。

PBFT算法中有两类定时器,分别是客户端和背景节点所拥有。

客户端定时器在其发送请求后就开始计时,如果在定时器的时限内没有收到回复,就将请求广播至所有节点。通过这个机制,可以解决三种导致系统运行出现异常的可能性:

1)客户端的请求并未发送至主节点;

2)主节点未将请求广播至背景节点;

3)节点返回消息时消息丢失。

可以看出,情况1和3都是客户端与节点网络的连接出现了异常,而情况2实际上是主节点出现了故障。当出现这三种情况时,客户端将会把消息向全部节点重播,背景节点收到广播消息时会把消息发送给主节点并启动定时器。如果是情况1,那么主节点将会将请求向背景节点分发,背景节点在时限内收到了请求,然后正常执行;如果是情况2,那么背景节点不会在时限内收到主节点分发的请求,因此质疑主节点是否出现了错误;在情况3中,因为节点会存储已经执行过的请求,因此只需要将之前的执行结果再发送一次。

背景节点的定时器则是在怀疑主节点错误从而需要发送视图切换请求时工作。通过这个机制,可以解决的异常为:

1主节点未将请求广播至背景节点

2节点在互相确认信息的阶段中未能在有限时间达成共识

3背景节点广播视图切换请求后,在有限时间内没有完成试图变更

当发生情况1时,首先察觉到的是客户端定时器,客户端定时器超时后,将消息广播给全部节点,此时背景节点收到消息后将消息转发给主节点并启动自己的计时器,如果在规定时间内没有收到主节点转发的请求,此时就认为主节点出现了错误,然后触发视图切换;在正常执行阶段,如果节点不能够在有限时间内达成共识,节点计时器就会超时,这就是情况2,这种情况并不一定意味着主节点发生了错误,也可能是网络原因导致视图中没有足够的节点达成共识,此时背景节点的定时器超时,就会触发视图切换;当背景节点广播视图切换请求后同样会启动一个定时器,如果在时限内视图切换没有完成,或者新视图中的请求没有在该时间间隔内完成,就会触发新的视图变更。

显而易见,客户端定时器代表了客户对于网络可用性的要求,而背景节点定时器的引入使网络中的各个节点变得更加积极了,每个背景节点只能在定时器所规定的时间内,容忍当前工作的停滞,一旦等待时间过长,就会对当前视图产生质疑并申请视图切换,从而使自己摆脱停滞状态。这就使得异步网络各个节点中虽然不同步,但是仍然可以保证网络中有足够多的节点参与工作,当节点不足以达成共识时快速跳转至下一视图。定时器的设计使得维护系统活性的方式从需要同步假设并且互相主动检测其他节点是否死亡转化为了节点检测自己是否长时间无事可做从而对整个网络发出请求,更加有利于分布式网络在网络状态不稳定时保持各个节点的活性,从而保证网络的活性。

结论

PBFT作为一个分布式系统的算法,显然要遵守FLP不可能定理和CAP定理。为了实现算法的确定性,对FLP不可能定理条件中的异步系统进行了改动,引入定时器使异步网络变为弱同步网络。同时,定时器引发的视图切换还可以保证系统的活性。PBFT算法的要求是达成分布式系统的中的一致性,因此在CAP的选择中选择了一致性和分区容错性而在一定程度上舍弃了可用性。

PBFT中的定时器设计巧妙地优化了异步网络中的活性,并且这种设计在网络中不需要额外的消息传输来确认节点的存活情况,节约了网络成本。同时PBFT视图切换的思想在AS6802时钟同步中的应用,体现出了视图切换这种动态选择主节点的方式要优于传统的静态分配主节点的选取方案,能够更好地保证系统的活性。

当然,PBFT也有其缺点所在,由于PBFT需要保证各个节点之间的频繁通信,因此需要有对节点数量的限制,所以可扩展性较弱;同时,由于节点需要许可后加入,因此它的去中心化程度较弱。

时至今日,PBFT 算法仍然是分布式系统中历久不衰的静待你,学习它的思想对我们学习分布式网络有很大的帮助。

参 考 文 献

[1] Miguel Castro;Barbara Liskov.Practical Byzantine Fault Tolerance[A].OSDI '99: Proceedings of the third symposium on Operating systems design and implementation[C],1999

[2] Michael J. Fischer;Nancy A. Lynch;Michael S. Paterson.Impossibility of distributed consensus with one faulty process[J].Journal of the ACM,1985,Vol.32(2): 374-382

[3] Fox, Armando;Brewer, Eric A..Harvest, yield, and scalable tolerant systems[A].7th Workshop on Hot Topics in Operating Systems (HotOS-VII)[C],1999

[4] Gilbert, S.*;Lynch, N.*.Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services[J].ACM SIGACT News,2002,Vol.33(2): 51-59

PBFT中的FLP不可能定理及CAP定理相关推荐

  1. 分布式系统中的FLP不可能原理、CAP理论与BASE理论

    前言 分布式系统是由多个不同的服务节点组成,节点与节点之间通过消息传递进行通信和协调.根据消息传递的不同,分布式系统的运行模型可以分为异步模型系统 和同步模型系统. 1.同步与异步 同步和异步关注的是 ...

  2. 分布式--CAP定理

    原文网址:分布式--分布式架构_IT利刃出鞘的博客-CSDN博客 简介 本文介绍分布式的CAP定理. CAP定理概述 说明 一个分布式系统不可能同时满足一致性(C:Consistency).可用性(A ...

  3. java基础巩固-宇宙第一AiYWM:为了维持生计,架构知识+分布式微服务+高并发高可用高性能知识序幕就此拉开(三:注册中心、补充CAP定理、BASE 理论)~整起

    架构知识+分布式微服务+高并发高可用高性能知识序幕就此拉开(一:总览篇) 网关开了个头 你请求来了,我网关把你拦截住,验明正身,加以控制,协助你调用服务,完成请求的调用.但是这个过程中,为了解耦和或者 ...

  4. 【分布式系统】CAP定理是什么?

    目录 分布式系统CAP理论概述 分布式系统 分布式系统CAP中的"C" 一致性 (Consistency) 分布式系统CAP中的"A" 可用性 (Availab ...

  5. 区块链笔记:区块链概念、相关对比、技术特点、CAP定理、FLP定理、价值网络

    什么是区块链 对于区块链这个技术名词出现在很多文章里面,有很多解释.站在技术角度来说,它是指一种数据的记录格式,任何系统都要记录数据,区块链对于其他的数据库或者工具有什么不一样的地方呢? 记录数据的方 ...

  6. 概率论与数理统计中的算子半群 第一讲 Banach-Steinhaus定理2 Banach-Steinhaus定理的应用

    概率论与数理统计中的算子半群 第一讲 Banach-Steinhaus定理2 Banach-Steinhaus定理的应用 上一讲我们介绍了Banach-Steinhaus定理: Banach-Stei ...

  7. 分布式工作笔记001---分布式系统中CAP 定理的含义

    JAVA技术交流QQ群:170933152 分布式系统(distributed system)正变得越来越重要,大型网站几乎都是分布式的. 分布式系统的最大难点,就是各个节点的状态如何同步.CAP 定 ...

  8. 关于分布式存储系统中-CAP原则(CAP定理)与BASE理论比较

    CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性). Availability(可用性).Partition tolerance(分区容错性),三者不可得兼. CA ...

  9. 为什么PBFT中需要2f+1

    文章目录 0. 写在前面 1. Prepare阶段为何需要2f+1? 2. Commit阶段为何需要2f+1? 参考文献 0. 写在前面 关于PBFT中为什么需要2f+1个Prepare/Commit ...

最新文章

  1. 《R语言编程艺术》——2.5 使用all()和any()
  2. [Medical Image Processing] 2. Image Binary -【OTSU Algorithm Entropy Method】
  3. 简单mongo的副本集搭建
  4. nyoj_66_分数拆分_201312012122
  5. 前端错误捕获终级方案
  6. drool 7.x 属性 : lock-on-active
  7. golang切片类型
  8. 12.04 安装svn
  9. 利用函数求数组中的最大值
  10. 讲python现状的文章_用 Python 分析 Python 工作现状
  11. 新建samba配置步骤
  12. ruoyi(若依)框架使用说明(前后端分离)
  13. ASP.Net中控件的EnableViewState属性 (转)
  14. 2022年起重机械指挥考试题库及模拟考试
  15. Google高级搜索命令
  16. java实现求调和数列的和,即:1/1 + 1/2 + ... + 1/n
  17. 项目管理学习总结(20)——小团队管理与大团队管理
  18. 20种硬件工程师必知必会基础元器件|最新更新至8.13
  19. 一个老工程师的工作经历和思考
  20. 【安全狐】NmapMasscan扫描工具使用详讲

热门文章

  1. uglifyjs报错 webpack_UglifyJs打包压缩问题引起的思考
  2. Java中的startsWith()方法
  3. 软件R的安装和使用(视窗电脑)
  4. Flutter组件--AppBar相关属性
  5. matlab中fmincon函数应用实例,matlab中fmincon函数的使用
  6. 【D3js】d3.select(this)获取到的 DOM对象的数据结构
  7. JavaScript 事件(下)
  8. 0916文件上传-基础及过滤方式
  9. 精通WordPress设计与开发:第1章 你的 第一篇WordPress帖子
  10. GLSL 与布丁晃动艺术