Practical Byzantine Fault Tolerance

来自论文Practical Byzantine Fault Tolerance

本文旨在进行Byzantine faults的容错,文章开门见山提出了新算法的优势:可工作在异步环境(如Internet),响应时间可以获得比之前算法超过一个数量级的提升。当然肯定会有limitation伴随,我们试着找出它们。

一开始文章就告诉我们有一个问题还没能解决:fault-tolerant privacy。

?Normal-Case Operation

提出了Buffered requests,可以减少系统负载沉重时的message traffic和CPU overheads,不过这似乎并不是本文的重点,因此被忽略了。

模型采取了Client -> Primary -> Backups的流程,即Client先将请求发给Primary,再由Primary通过一个三阶段协议广播给Backups。先来看一看这个三阶段:pre-prepare, prepare, commit。

在pre-prepare阶段,primary会给请求分配一个序号n,然后向所有的backups发送一个prepare message with m piggybacked,并将这个message加到它的log中。这个message的形式是

v指的是发送信息所在的view,m是client的request message,d是m的摘要。

但请求并不包含在pre-prepare信息中,避免信息过大。那Primary发送这个信息的目的何在?如果Backup i接受到这个信息后,就会进入prepare阶段,它会想其他所有的replicas发送一个信息如下,

并将此信息记录在自己的log中,如果没接收到,就什么也不做。一个replica(包括primary)接收这些prepare messages,如果它们的signatures是正确的,它们的view number等于这个replica当前的view,并且它们的序号在h和H之间,那么就将这些信息加到它的log中。之后就是commit阶段,这个replica会向其它replicas发送信息:

,同样当这个信息合理时,replicas会将它们插入到自己的log中。

Pre-prepare和prepare阶段的目的在于保证没有出错的replicas在一个view中对一个全序的请求序列达成一致。Commit阶段之后就可以确保让每个non-faulty replicas以相同的次序执行请求并给client发一个回复。下面是这个过程的流程:

?Non-Determinism

对于文件的修改时间,如果以每台机器上的local clock来定就会出现分歧,出现non-determinism,所以就需要一种机制让所有的replicas选择同一个值作为修改时间,我们又不能让client提前选择这个值,因为它并不清楚它提出的请求与其它clients提出的请求是如何被安排顺序的。最终这事就交给了primary,由它选出non-determinism值,然后经过三阶段协议让non-faulty replicas在其上达成一致。

?Reducing Communication

我们都知道,最后所有的replicas都会将各自执行的结果返回给client,如果回复很多,势必会带来较大的网络带宽消耗和CPU overhead,这里采取的优化措施是让一个replica返回完整的结果,而其它replicas返回结果的一个摘要,不过这个摘要能用来验证结果的正确与否。

?Cryptography

文章的一个改进是在发送view-change和new-view 这些不经常发送的信息时使用传统的digital signature,而对于频繁发送的其它信息时使用MACs,这会消除主要的性能瓶颈。

?Implementation

Snfsd在memory mapped file中直接执行文件系统操作,这样保持住了locality,而且它使用写时拷贝来减少与维护checkpoints有关的空间和时间overhead。

?Related Work

以前大多数的有关复制技术的工作都忽略了Byzantine故障,也都假设了一个同步系统模型,所以论文的主要工作就为这两个目的而来。传统的Viewstamped replication和大名鼎鼎的Paxos也只能容忍异步系统中的良性错误,它们对fault tolerance的支持并不是很完备。其实要容错拜占庭故障需要很复杂的使用密码鉴别技术的协议,并要有pre-prepare阶段,以及view-change来选择primary。也许是本文的一个advantage:通过view changes选择出一个新的primary,而不是选择一个不同的replicas集合来形成一个新的view。

之前也有过一些一致性协议能容错Byzantine故障,不过是在异步系统中,而且它们并没有提供一个完整的解决方案来进行状态机复制,而且并不能马上用于实践,而本文的算法既进行了正常情况下的Byzantine故障容错,也考虑了primary出错的情况。

而且通过与类似模型Rampart和SecureRing的比较,本文的模型在速度上要快一个数量级。在异步系统中,这两个模型为了检查出哪个replica出错所使用的failure detectors技术不会准确,所以它们在异步系统中会出现误判,而本文的模型可以做到。更重要的是,这两个模型会将故障的replicas排除出group,同时因为误判也会将没有故障的replicas排除出组。而本文提出的模型不会将replicas排除出group,所以就不用担心这个问题。

Phalanx也是一个可以用于异步环境的Byzantine故障容错模型,不过本文的模型要快于它,因为本文的模型由于使用MACs而不是public key cryptography在关键路径上有较少的信息延迟。

?Conclusions

作为一名读者我感觉本文提出的模型的advantages有:

(i)实现了Byzantine故障的容错

(ii)它是第一个能在一个异步环境(如Internet)正确工作的模型,并且相比于之前的算法在性能上提高了一个数量级还多

(iii)将模型用在了NFS中,实现了BFS,并且采取了一些列优化措施:用MACs代替public-key signatures,减少信息的数量和大小,还有一个incremental checkpoint-management技术

(iiii)当出现了software errors时,使用这个算法的系统仍然正常工作,当然如果所有的replicas都出现了这个software error,也是无能为力的,但对于在不同replicas中独立发生的错误,包括nondeterministic software errors这些很难检测的错误,本文的算法还是能mask掉的。

再来说一下本文算法的limitations:

减少实现算法所需要资源的数量,如减少replicas的数量,减少copies of the state的数量。

时间: 2024-11-10 13:00:59

Practical Byzantine Fault Tolerance的相关文章

Flink Program Guide (9) -- StateBackend : Fault Tolerance(Basic API Concepts -- For Java)

State Backends 本文翻译自文档Streaming Guide / Fault Tolerance / StateBackend ----------------------------------------------------------------------------------------- 使用Data Stream API编写的程序通常以多种形式维护状态: ·  窗口将收集element或在它被触发后聚合element ·  Transformation方法可能会

VMware Fault Tolerance 概述及功能

VMware Fault Tolerance - 为您的应用程序提供全天候可用性 通过为虚拟机启用 VMware Fault Tolerance,最大限度地延长数据中心的正常运行时间,减少停机管理成本.基于 vLockstep 技术的 VMware Fault Tolerance 可使应用程序实现零停机.零数据丢失,同时消除了传统硬件或软件集群解决方案的成本和复杂性. 1.消除因硬件故障造成的停机VMware Fault Tolerance 是一项前沿技术,它通过创建实际上与主实例保持同步的虚拟

Apache Flink fault tolerance源码剖析(四)

上篇文章我们探讨了Zookeeper在Flink的fault tolerance中发挥的作用(存储/恢复已完成的检查点以及检查点编号生成器). 这篇文章会谈论一种特殊的检查点,Flink将之命名为--Savepoint(保存点). 因为保存点只不过是一种特殊的检查点,所以在Flink中并没有太多代码实现.但作为一个特性,值得花费一个篇幅来介绍. 检查点VS保存点 使用数据流API编写的程序可以从保存点来恢复执行.保存点允许你在更新程序的同时还能保证Flink集群不丢失任何状态. 保存点是人工触发

Apache Flink fault tolerance源码剖析(一)

因某些童鞋的建议,从这篇文章开始结合源码谈谈Flink Fault Tolerance相关的话题.上篇官方介绍的翻译是理解这个话题的前提,所以如果你想更深入得了解Flink Fault Tolerance的机制,推荐先读一下前篇文章理解它的实现原理.当然原理归原理,原理体现在代码实现里并不是想象中的那么直观.这里的源码剖析也是我学习以及理解的过程. 作为源码解析Flink Fault Tolerance的首篇文章,我们先暂且不谈太有深度的东西,先来了解一下:Flink哪里涉及到检查点/快照机制来

Apache Flink fault tolerance源码剖析完结篇

这篇文章是对Flinkfault tolerance的一个总结.虽然还有些细节没有涉及到,但是基本的实现要点在这个系列中都已提及. 回顾这个系列,每篇文章都至少涉及一个知识点.我们来挨个总结一下. 恢复机制实现 Flink中通常需要进行状态恢复的对象是operator以及function.它们通过不同的方式来达到状态快照以及状态恢复的能力.其中function通过实现Checkpointed的接口,而operator通过实现StreamOpeator接口.这两个接口的行为是类似的. 当然对于数据

Apache Flink fault tolerance源码剖析(三)

上一篇文章我们探讨了基于定时任务的周期性检查点触发机制以及基于Akka的actor模型的消息驱动协同机制.这篇文章我们将探讨Zookeeper在Flink的Fault Tolerance所起到的作用. 其实,Flink引入Zookeeper的目的主要是让JobManager实现高可用(leader选举). 因为Zookeeper在Flink里存在多种应用场景,本篇我们还是将重心放在Fault Tolerance上,即讲解Zookeeper在检查点的恢复机制上发挥的作用. 如果用一幅图表示快照机制

Fault Tolerance(FT)

vSphere Fault Tolerance通过创建和维护与主虚拟机相同,并且可在发生故障切换时随时替换主虚拟机的辅助虚拟机,来确保虚拟机的连续可用性,其实就是一为某一个虚拟机创建一个完全相同的副本.可以为虚拟机启用vSphere Fault Tolerance.比获得比vSphere HA所提供的级别更高的可用性和数据保护,从而确保业务连续性.Fault Tolerance时基于ESXi主机平台构建的(使用VMware vLockstep技术),它通过在单独主机上一虚拟锁步方式运行相同的虚拟

Flink Program Guide (7) -- 容错 Fault Tolerance(DataStream API编程指导 -- For Java)

false false false false EN-US ZH-CN X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt

Apache Flink fault tolerance源码剖析(五)

上一篇文章我们谈论了保存点的相关内容,其中就谈到了保存点状态的存储.这篇文章我们来探讨用户程序状态的存储,也是在之前的文章中多次提及的state backend(中文暂译为状态终端). 基于数据流API而编写的程序经常以各种各样的形式保存着状态: 窗口收集/聚合元素(这里的元素可以看作是窗口的状态)直到它们被触发 转换函数可能会使用key/value状态接口来存储数据 转换函数可能实现Checkpointed接口来让它们的本地变量受益于fault tolerant机制 当检查点机制工作时,上面谈