张新洲， 周敏奇

（华东师范大学 软件学院，上海 20062）

0 引 言

随着大数据时代的到来，系统所需要承受的计算任务变得越来越复杂，因此系统在硬件技术以及软件优化方案上都有进一步的改善和提高.对于高性能计算机系统来说，为了应对日益增长的数据量规模、逐渐增强的计算复杂度，需要添加越来越多的高性能组件.随之带来的结果是，长时间的运行分布式程序，由硬件失效造成的系统终端失效概率变大，此外，当一个系统应用程序失败时，会消耗更多的恢复成本，因为集群系统中会更多的计算结果都会随之丢失.因此，分布式系统和并行系统双方对于容错机制的支持至关重要，以此来确保大规模计算环境的可用性.

本文专注于集群系统，以及在集群环境下运行的分布式应用程序.集群系统是由大量相同的、集中管理的计算节点通过以太网或者万兆网连接在一起的分布式系统.节点间采用如MPI等软件协助各个节点融入成为一个更大的、统一的集群系统；通常一些节点作为主节点用于管理和用户交互.

在集群环境中，各个节点出现故障的概率较高.任何组件的任何计算节点都有可能出现失效，包括处理器，硬盘，存储器网络接口等硬件.一个节点上的硬件或者软件故障都有可能会影响到整个系统的调度以及造成数据的丢失.第1节将概述这些故障的理论模型.

通常来说可能发生在集群系统中的故障主要有两个基本类别.第1类是集中式的组件故障，例如一个存储节点或者是一个管理软件出现了硬件故障或者软件错误最终导致系统失败.冗余技术可以用于处理这一类故障，即将数据复制到多个节点上.一旦一个节点发生故障，备份的数据可以介入，接管主要的功能，从而保证系统可用性.第2节主要讨论这一类的系统故障.

第2类故障是分布式应用在集群中运行时某个节点突然崩溃或者挂起.这可能是由于应用程序中的漏洞、该节点上的硬件故障，或者是操作系统的问题导致运行在该节点的应用程序无法继续正常工作.但是参加相同计算的其他节点可以继续工作不受影响，不同的是它们不再从故障节点接受输出.面对这样的故障，通过设置程序的检查点来定期检查应用程序的计算状态，完成系统发生故障时的恢复.同时参与计算的其它节点可能需要回滚到较早之前的检查点，使得所有的节点与出现故障的节点恢复的状态是一致的.第3节提供了回滚恢复技术和防止故障发生的详细细节.在第4节对系统设计中的接口与封装进行了阐述.

文章第5节和第6节分析了当前内存计算环境下容错技术面临的机遇和挑战，在利用内存高效加载及高速计算的同时需要克服内存的易失性.对Spark系统和Claims系统的容错技术进行了分析.最后对全文进行总结，并对未来工作进行展望.

1 错误模型

面对大数据处理，集群环境出现失败的情况数不胜数，通过故障在系统的行为方式中存在的抽象模型实现错误分类.容错技术将针对不同的错误模型进行设计和实现.本章讨论3种最常见的故障模式.

1.1 随机故障模型（拜占庭Byzantine模型）

拜占庭故障模型代表系统失败最敌对的模型.此故障模型允许失败的节点继续与系统的其余部分进行交互.节点间的行为可以是任意的和不一致的，并且失效的节点间允许进行通信继续产生输出.正确运行的节点不能自动检测出已经失效的节点，也不能得知当一个错误出现时哪些节点有可能会失效.这个模型可以被黑客表示为随机系统故障以及恶意攻击.它已经被证明无法保证一个拥有3m＋1个节点的系统中其中m个节点正在经历拜占庭失效时还能够正确运行.

1.2 故障－停止（Fail－stop）模型

故障停止故障模型比拜占庭模型要简单.该模型允许任何节点在任何时间出现故障，但是，当发生故障时它停止产生输出，与系统的其余部分交互.此外，所有其它节点自动地获知该节点失败状态.此故障模型表示是失败的常见模式，如系统挂起或崩溃，但处理粒度不细致，如无法探测到随机内存损坏原因.

Fail－stop模型认为系统组件，如个别服务，节点，通信连接等，是通过简单的停止而失败的.部署的故障检测机制仅仅对硬件错误或者灾难性的软件错误做出反应.如果一个失败的系统组件因软件错误或者系统设计错误产生了错误的输出而违背了这种假定，那么基于这种模型的冗余方案不能够保证正确性.

1.3 Fail－stutter模型

上述两种容错模型中拜占庭模型是极其广泛的，但不切实际，因此很难在实际中得到应用；而故障停止模型更加常用也更加容易进行部署，但是它过于简单，因为它未能表示出多种类型的现实世界失效.为了弥补这两种极端情况的不足，Fail－stutter模型应运而生.

Fail－stutter模型是故障停机模式的延伸.它试图维持该模型的易处理性，同时扩展了真实世界中的各种故障集合.Fail－stutter模型覆盖了故障停机模式的所有规则，同时它也允许性能故障.性能故障是指某个节点发生性能上的意外，此时处理性能急剧下降，但是仍然能够输出正确的结果.这个扩展允许模型包含诸如当遭遇非常大的流量负载时网络交换机的高延迟性能故障.尽管Fail－stutter模型拥有以上优势，但是目前还没有被社会广泛的接受.

2 集中式容错

集群系统依赖于大量集中式组件才能正常工作.主节点负责处理作业调度和节点监控，存储节点可以访问大容量的磁盘阵列.而在某些系统中还有专门的节点负责与用户进行交互，从而避免占用系统中其他节点的计算时间.这些关键的节点通常在集群中占用比较小的数量，但是它们对于整个系统至关重要，因此需要对于这些节点进行额外的关照，甚至可以提供额外的硬件支持来保证它们在遭遇系统故障时保持健壮性.

2.1 备份

对于集中式系统来说提供容错最常见的方法是复制.复制通常可以采用以下两种方式：

第1种是主动复制，第2台机器接收所有来自主节点的输入副本，并且通过所有必要的软件独立运行出一个相同的系统状态.此外，备份节点还会监视主节点的不正确行为.同时，在这些不正确的行为发生（例如系统崩溃）时，备份节点自动提升自身的优先状态，并接管该系统的关键功能.由于备份节点的系统状态已经等同于优先状态，所以这种转换所需要的时间是可以忽略掉的.这种备份的方式对于高性能并行计算集群来说是不可行的，因为这种系统需要增加一倍的节点数量开销而并不提高系统的性能.

对主服务器进行多个备份是主动复制的一个变体：所有备份机器接收全部的输入，当产生输出时，所有的副本投票决定什么是正确的输出，最终根据拜占庭算法将结果进行比较，如果一个或多个节点生成超出阈值次数的不正确输出，它们将被标记为故障并且忽略，直到它们可以通过维护程序进行修复.这种变体能够处理拜占庭故障，而之前的主动复制只能容忍故障停机模式的错误.

第2种是被动复制，在被动复制中，“冷备”机始终作为主系统的完整备份.这个系统通常保持空闲状态，但是它具有系统中所有软件的备份.如果主设备发生故障，冷备机立即接管主要职责.这可能产生服务的暂时中断，它取决于副本的空闲状态.如果在没有设置检查点机制的情况下，被动复制不适合用来维护复杂的难以恢复的系统内部状态，但是它适合用来维持小型的系统内部组件，如子系统的完整备份.

另外，被动复制更加适合在更高级别上复制系统的某一部分组件而不是将整个系统进行完整的备份.通常在架构整个系统时可以采用多个相同的内部组件，例如，一台机器装备多个CPU、多个内存以及多个主板等等，或者针对系统中最容易出现错误的组件准备多个备用组件.在系统运行中通过仔细监视每个组件的正确性，一旦出现失效，则这个失败的组件自动被禁用，用备份进行替换而不需要关闭系统，并且不中断任何系统软件.一旦正确的功能恢复正常，发生故障的组件可以后来进行热交换使用新的副本.

2.2 可靠的通讯

如之前所述，当所有系统组件的副本所接收到的输入完全相同的时候，系统组件的主动复制是可行的.虽然与集中式系统的节点进行通信可以采用多种组播通信协议来实现，但是没有必要保证所有副本上的组播都是完全一致的.如果系统不提供这种一致性的保证，那么各个备份就可以在不一致的状态下结束通信.

实际上存在多种可以提供可靠性，安全性的组播通信协议.组播通信将一个客户或一个组成员发送的消息传送给组内的所有成员.不同的应用程序要求系统中的组成员按照相应的顺序来接收和处理组播消息，以保证系统的正确运行.然而，在一个开放动态的分布系统中，网络延迟、资源竞争等各种因素可能会导致各个成员接收消息的次序不同.为保证应用的正常运行，组播通信需要解决消息次序问题.通常消息次序可以分为3种：FIFO序、因果序（Casual Order）、全序（Total Order）.FIFO序指一个组中所有的成员都按照相同的顺序接收来自同一个客户或者组成员的消息.FIFO序很容易实现，但它是实现其他通信方式的基础.因果序保证两条具有因果关系的消息m1和m2按照其因果关系传递到组内各个成员.这里因果关系是指一个成员先发送m1，然后才能发送m2，或者先接收m1，然后才能接收m2.因果序通常利用逻辑时钟实现，如Lamport逻辑时钟.

全序组通信，也被称为原子组通信（Atomic Broadcast），它能够保证一个通信组中所有的成员都按照相同的顺序接收消息.全序组通信是分布式容错系统中一个十分重要的问题，它是实现有限状态机复制协议的基础.全序组通信在静态和动态的组通信系统中的实现方式是不同的.在静态系统中，全序组通信问题一般转换成一致性（Consensus）问题，并直接利用不可靠失效检测器来解决.在动态系统中，全序组通信需要利用组成员关系服务和虚拟同步通信原语来实现.直观而言，虚拟同步通信原语能够保证在组视图发生变化时，所有组成员接收的消息集合相等.

2.3 监控

对于一个系统来说，它必须监测到主要的组件已经失效才能够自动激活备份副本.监测的最基本形式是一个简单的心跳系统，监视器进程侦听来自受监视组件的周期性消息.该消息只是表示该组件正常工作，如果监视器在预定时间内没有从组件收到消息，那么便认为该组件失效.这种形式的监控适用于故障停机模式检测故障.

复制组件之间的拜占庭模型是监控的另一种形式.各个副本会根据正确的输入输出或者各个副本的各个操作进行投票.在发生分歧的情况下，少数被认为是错误的.这种方法允许拜占庭故障检测机制，使得监控更加的强壮.然而，拜占庭共识通信成本比心跳监控的成本要高得多，因为在最坏情况下，所有节点都必须与所有其他节点通信.对于一个小规模副本，这可能是可以接受的.

当然，监控也可以通过自一致性检查的形式实现.单个节点通过周期性的自我检查来确定是否内部组件正常运行.此外，系统中的其他节点可以确定一个集中式的服务器是否会出现问题来共享信息.也可以通过检查从服务器丢失的或者格式不正确的消息进行错误检查.倘若其他节点怀疑存在问题，也可以触发服务器自诊断检查.

2.4 软件设计

管理软件可以把容错机能作为设计目的之一.细致的软件工程可以设计出能够抵抗系统故障的程序，并最大限度地减少停机时间，让故障不影响系统功能.

重新启动系统是处理各种故障的常见方式.但是它的缺点也显而易见，它会大大增加系统的停机时间，并且产生很多不必要的开销.例如重新启动不仅会重启失效的机器，正常工作的机器也会随之重新启动.因此，在架构整个系统的初期就应该设计好多层次结构，使得各个功能组件尽可能的独立.在某个层次出现失效的时候，只需要重启与之紧密相关的系统，其他功能还能正常使用，从而避免不必要的开销.

3 并行应用程序的容错

集群系统的真正价值并不在于软件管理和操作执行，而是将大规模的并行计算程序在串行的环境中有效的执行并快速地输出结果.因此，即使主节点可以抵抗任意类型的故障，系统还是需要保证分布式的应用在集群中运行时受到保护，否则，针对硬件进行的容错将毫无意义.

3.1 检查点和回滚

并行应用程序容错的最基本形式是检查点和回滚恢复.具有检查点的恢复技术是在日志文件中增加一类新的记录－－检查点记录（checkpoint），增加一个重新开始文件，并让恢复子系统在登录日志文件期间动态地维护日志.为了确保应用的可靠性，系统需要保存应用程序的状态，用以保证系统计算的完整性.回滚恢复技术是保存系统状态的一种常见形式.

并行检查点设置和恢复技术包括两部分：各进程状态的保存和恢复，以及通信通道状态的保存和恢复.前者与单进程检查点内容密切相关，而对后者的处理协议可分成两大类：检查点协议和日志协议.检查点协议中，进程只记录描述进程状态信息的检查点.日志协议中，进程不仅记录检查点，也记录事件相关的日志信息.

回滚恢复技术可分为两大类：基于检查点的回滚以及基于日志的回滚.

（1）多米诺骨牌效应

当回滚之后，一个进程根据发件人的状态记录了尚未发送的消息记录，随后便出现多米诺骨牌效应.在这种情况下，收件人的状态必须回滚到收到消息之前的状态.这种效果会产生级联效应，使得系统无限期回滚，导致巨大计算量的损失.这种效应也迫使每个进程维护多个检查点，在多米诺骨牌效应回滚的情况下存在这样的后备选项.

（2）基于检查点的回滚恢复

一般情况下，以检查点为基础的回滚恢复协议周期性地保存每个计算中涉及的进程当前计算状态.当创建检查点被激活时，系统会记录该进程的内存状态.这样，在进程出现故障的时候，进程可以根据一个中间状态进行重建.

通常来说，有3个类别的检查点作为恢复协议：协作式检查点，独立式检查点和通信引导式检查点.

在协作式（同步）检查点中，要求强制多个线程协调记录检查点用以获得一致的全局状态，只需要每个进程在稳定存储上维护一个永久性检查点，降低存储开销以及避免垃圾回收操作.它的缺点是在向外界提交输出任何结果时需要协调记录全局的检查点，导致提交输出操作有较大延迟.

独立式检查点方法中，进程具有极大的自主性来决定记录检查点的时机，例如在进程状态信息量小的时候记录.它的缺点是：1）容易产生Domino效应；2）进程可能会记录不属于全局一致状态的无用检查点，导致不必要的开销；3）每个进程要维护多个检查点，必须周期性的激活垃圾回收删除不再使用的检查点；4）不适合与外界交互频繁的应用，因为向外界输出时需要全局的协调操作，导致开销的增加.

在这种方法中，进程要记录2种检查点，一种是进程各自独立记录的，称为局部检查点，另一种是进程被强制记录的，称为强制检查点.进程根据接收到的其它进程消息捎带来的信息决定是否记录强制检查点.和协作式检查点相比，这种方法不需要交换专门的消息.

（3）基于日志的回滚恢复

日志协议把进程的执行看成非确定状态区间序列，每个区间以非确定事件的执行开始.协议假定所有的非确定事件都可以被识别，同时事件相关的信息都可以记录到稳定存储上.另外，进程也记录检查点.一个进程的状态依赖于非确定事件，但是该事件在恢复阶段不能重新生成，这样的进程称为孤立进程（orphan process）.产生孤立进程将导致系统的不一致状态.日志协议可保证在执行恢复操作时不产生孤立进程从而获得一致的全局状态.日志协议分为3种：悲观日志、乐观日志和因果日志.

悲观日志假定任何非确定事件之后都可能发生故障.最直接的实现方式是在事件影响计算结果之前，事件日志信息都已经存到稳定存储上.悲观日志导致很高的开销.可以采用特殊的硬件降低开销.例如，采用非易失性内存作为稳定存储，另外一种形式是采用专门的总线记录日志消息.也可以不采用硬件，如基于发送方消息日志把消息记录在发送方动态内存内.

乐观日志中事件日志信息以易失性日志的形式临时保存，然后周期地存放到稳定存储.它乐观地假设在发生故障之前能记录完日志.因此，应用可继续执行，不必阻塞等待日志保存到稳定存储.和悲观日志相比，乐观日志必须记录多个检查点导致垃圾回收算法相对复杂.另外可能产生孤立进程.

因果日志协议结合了乐观日志和悲观日志两者的优点.一方面，它避免了同步访问稳定存储的操作；另一方面，它允许每个进程独立地提交输出操作而不产生孤立进程.另外，在恢复时能保证进程回滚到最近的存放在稳定存储上的检查点.但这些优势的获得是以复杂的恢复协议为代价的.

3.2 虚拟线程

虚拟线程允许并行程序以超过物理处理器个数的线程数进行执行.在这样的系统中，每一个虚拟线程映射到一个物理处理器，而每一个物理处理器处理一个或多个虚拟线程的任务.虚拟线程可以从一个物理处理器迁移到另外一个物理处理器而不需要关闭整个应用进程.这项技术主要应用于负载均衡、网格计算以及系统容错.

容错应用使用这项技术的关键是迁移功能.如果一个节点出现故障，虚拟线程可以迁移到操作可正常执行的其他节点上继续运行.虽然在迁移之后，系统整体的执行速度可能会有所下降，但这是一种比系统完全失效或者暂停更优的方案.

为了处理失败停机类故障，虚拟处理器技术可与处理器复制或检查点相结合，允许在一个幸存的物理节点上对已经丢失的虚拟线程进行实时恢复.在实践中，通常使用协同检查点技术，针对大型应用程序使用磁盘中的检查点，针对小型应用程序使用内存中的检查点.

此外，虚拟处理器可以主动或被动地复制，以提供可在发生故障时接管的备份实例.系统中的应用程序根据功能的不同可以被分配给每个处理器，并且处理器可以被复制到不同程度，具体程度取决于需要保护该组件的重要级别.

4 接口与封装

虽然容错技术具有很高的学术研究价值，但是只有通过系统部署才能产生真正的价值.显然容错技术可以由程序开发人员直接实现，但是一个简单易用的软件包可以大大降低学习成本，因此从接口到合成系统是区分各种容错方案的一个关键因素.

最常见的封装容错技术是以提供软件库形式来实现相关应用程序的编程接口（API）.开发者调用特定的API函数便可以实现软件开发中容错的高效移植.目前比较成熟的容错软件接口大多采用面向对象的思想.因此在容错中可以建立容错的编程语言，从而简化开发人员根据分布式特性进行分布式程序开发的步骤，减少编程错误导致运行的错误.此外，容错还可以在操作系统级别实现.理想的情况下，应用程序将会借助系统自行运行的能力进行实时容错.

另一种可能的方法是部署中间件系统，利用系统守护进程进行系统监控以及应用程序支持.这类似于系统级别的集中式容错理念，它并不需要特殊的主机操作系统，而是利用系统级别的守护进程在后台持续运行.这些后台程序可以被配置成监视所有的应用程序并提供容错功能.

提供容错技术的最后一个方法是使用预处理器针对源代码自动生成必要的修改代码.这样做可以简化复杂的代码，不需要程序员添加额外的代码来指定某一部分作为系统的容错代码，通过自动执行预处理代码从而减少内存开销和资源浪费.

5 内存计算环境下的容错技术

随着硬件进一步发展，超大规模计算已经发展到内存计算，即将所有需要的数据全部加载到内存中然后再进行计算，充分利用内存计算的高效性.这一发展给容错又带来了前所未有的挑战，因为在享受内存高效的同时还需要解决易失性的缺点.在支持内存计算的系统中，通常需要将系统执行过程中的操作进行记录，通过阶段性的切分，将数据自适应地组织成一个完整的链条，通过这个链条对整个操作流程进行完整的备份.目前在这方面较为出色的是Berkeley的Spark系统.

Spark的核心概念是RDD（resilient distributed dataset），将数据定义为一个只读的，可分区的分布式数据集，这个数据集可以全部或者部分缓存在内存中，并且可以在多次计算之间重用.

容错方面，Spark采用Lineage机制，结合利用内存加快数据加载，提出了一套区别于其他系统在分布式环境下使用的容错方案，解决了节点实效和数据丢失的问题.为了保证系统中RDD数据鲁棒性，RDD数据集通过血统关系（Lineage）记录整个数据集演变的过程.相比于其它系统的细粒度的内存数据，RDD的Lineage记录粗粒度的特定数据变换操作，例如，filter，map，join等操作.当RDD中部分分区的数据丢失时，系统可以通过Lineage获取足够的信息来重新运算和恢复丢失的数据分区.同时，Spark将整个操作的并行过程按照不同节点之间是否交换数据（shuffle）划分成不同的Stage，当系统发生故障时，会自动回溯到最后一个执行成功的Stage，重新执行该Stage之后的所有操作.通过这种方式，以较小的性能代价保证了数据的鲁棒性，大大提高了系统容错的性能.

6 分布式容错＠CLAIMS

随着大数据时代到来，海量数据的多样性、实时性在给信息科技带来更多便利与机遇的同时也给数据分析研究领域带来前所未有的挑战.当今单台服务器节点的性能可以达到非常高的标准，不论是处理器的个数还是内存容量的大小都已经达到了前所未有的高度，如果我们依然按照传统的思维继续发展单机上的内存数据库，其性能必将受到极大的制约.因此，将内存数据库向分布式方向发展显得尤为重要.

当前，还没有较为成熟的分布式内存数据库系统以及基于这样的系统的一整套容错系统和机制.在这方面，华东师范大学数据科学与工程学院已经开展了近两年时间的研究，致力于开发集群感知的基于内存的分布式数据库系统（Cluster－Aware In－Memory System，CLAIMS），并且已经取得了不错的成果（http：／／github.com／wangli1426／Claims）.该系统设计了针对内存数据的分布式容错系统，结合hdfs的优势最大地降低了容错恢复的成本.在数据的存储端，主要是用基于日志的恢复技术，利用hdfs自身多备份的特性有效地提高存储系统的稳定性.同时，在并行内存计算的过程中加入监视线程并记录检查点，通过基于检查点的回滚机制最大限度的提高容错的效率，提升总体性能.

7 小 结

本文综述大规模高性能集群计算系统的容错技术.这些技术可以分为2类：保护集群管理的硬件和软件基础设施，保护计算节点确保应用程序长期稳定运行.

集群管理硬件和软件容错通常利用冗余，由数量相对较少的部件进行复制.当一个组件发生故障时，冗余组件接管故障部分的责任.冗余可以因此通过比较每个副本产生的产出和寻找差异可用于故障检测.

系统集群发生故障之后，使用检查点和回滚恢复技术处理故障.在应用程序中每个组件定期记录其状态形式存储检查点文件.在进行错误恢复的时候，应用程序从最新的一组检查点进行恢复.目前已有多种协议确保系统使用最高效的方式恢复到正常状态.

容错性的解决方案可以通过各种形式来实现.这包括软件库，特殊的编程语言，编译器或预处理器修改，操作系统的扩展和系统中间件的实现.每种方法都在高效性和易用性方面有自己的优势.

随着分布式计算的扩展性持续的增长，系统的可靠性变得至关重要，系统故障的预测和纠错机制在提高系统稳定性方面扮演着极其重要的角色.分布式计算变得更加的灵活和复杂.目前为了在分布式系统中及时发现故障，恢复故障，已经有各种各样的技术被提出.一旦有故障被发现，系统会自动找到故障的根源.

本篇综述通过客观的方式来描述整个分布式计算的容错领域，但是关于这方面的研究还有很多工作需要完善.

［1］ CHRISTIAN F.Understanding fault－tolerant distributed systems［J］.Communications of the ACM，1991，34（2）：58－78.

［2］ BARTLETT J，BARTLETT W，CARR R，et al.Fault tolerance in tandem computer systems［J］.Technical Report 90.5，1990.

［3］ SISTLA A P，WELCH J L.Efficient distributed recovery using message logging［C］／／Proceedings of the Eighth Annual ACM Symposium on Principles of Distributed Computing，1989：223－238.

［4］ TIAN D，WU K，LI X.A Novel Adaptive Failure Detector for Distributed Systems.In Proceedings of the 2008 International Conference on Networking Architecture and Storage（2008）ISBN：978－0－7695－3187－8.

［5］ KOLA G，KOSAR T，LIVNY M.Faults in large distributed systems and what we can do about them （2005）.

［6］ AFFAN M，ANSARI M A.Distributed fault management for computational grids［C］／／Fifth International Conference on Grid and Cooperative Computing，2006：363－368.

［7］ JALOTR P.Fault Tolerance in Distributed Systems［M］.New Jersey：Prentice Hall，1994.

［8］ HWANG S，KESSELMAN C.A flexible framework for fault tolerance in the grid［J］.Journal of Grid Computing，2003，1（3）：251－272.

［9］ WIESMANN M，PEDONE F，SCHIPER A，et al.Understanding replication in databases and distributed systems［C］／／20th IEEE International Conference on Distributed Computing Systems，2000：464－474.

［10］ SHUKRI A，NOOR M，DERIS M M.Extended Heartbeat Mechanism for Fault Detection Serrice Methodology［C］／／Grid and Distributed Computing，2009，63：88－95.

［11］ HERLIHY M，WING J.Linearizability：a correctness condition for concurrent objects［J］.ACM Transactions.on Programming.Languages and Systems，1990，12（3）：463－492.

［12］ SHYE A，BLOMSTEDT J，MOSELEY T，et al.PLR：A software approach to transient fault tolerance for multicore architectures［C］／／IEEE Transactions on Dependable and Secure Computing，2009，6（2）：135－148.

［13］ WALTERS J，CHANDHARY T.Replication－based fault tolerance for MPI applications，Ieee Transactions On Parallel and Distributed Systems，2009，20（7）：997－1010.

［14］ GORENDER S，RAYNAL M.An adaptive programming model for fault－tolerant distributed computing［C］／／IEEET Transactions on Dependable and Secure Computing，2007，4（1）：18－31.

［15］ OSRAEL J，FROIHOFER L，GOESCHKA K M，et al.A system architecture for enhanced availability of tightly coupled distributed systems［C］／／Proceedings.of 1st International.Conference.on Availability，Reliability and Security，2006.

［16］ XIONG N，CAO M，HE J.et al.A survey on fault－tolerance in distributed network systems［C］／／International Conference on Computational Science and Engineering，2009：1065－1070.

［17］ TIAN D，WU K，LI X.A novel adaptive failure detector for distributed systems［C］／／Proceedings of the 2008International Conference on Networking，Architecture，and Storage.2008：215－221.

［18］ 怀特T著Hadoop权威指南.周敏奇，王晓玲，金澈清，等译，周傲英 审校.2版.北京：清华出版社，2011.

［19］ 宫学庆，金澈清，王晓玲，等.数据密集型科学与工程：需求和挑战［J］.计算机学报，2012，35（8）：1563－1578.