分布式系统之10、容错性

第七章容错性一、容错性简介根本概念故障使用冗余掩盖故障1、根本概念容错即意味着系统能在故障发生的状况下连续供给效劳。几个相关概念可用性：系统可以工作，即可被使用牢靠性：指系统可以无故障地持续运行安全性：系统在偶然消失故障的状况下可以正确操作而不会造成任何灾难。可维护性：系统发生故障后，恢复的难易程度2、故障可以分为临时的、间歇的和长久的。可以进一步分为以下类型：故障类型说明崩溃性故障服务器停机，但停机之前工作正常遗漏性故障

接收遗漏

发送遗漏服务器不能响应来到的请求

服务器不能接收消息

服务器不能发送消息定时故障服务器未能按时响应响应故障

值故障

状态转换故障服务器响应不正确

响应值不正确

服务器偏离了正确的控制流随意性故障服务器可能在随意的时间产生随意的响应3、使用冗余掩盖故障分布式系统容错的目的对其他进程或客户隐蔽故障〔故障透亮性〕容错手段：使用冗余掩盖故障三种冗余方法：信息冗余：添加额外的位以使错误的位恢复。时间冗余：屡次重复一个操作，适合临时性或间歇性故障。物理冗余：物理上添加备份二、分布式系统的进程容错进程组公平组和等级组组成员的治理1、进程组进程组把多个一样的进程组织到一个规律的组中当组中某个成员进程患病故障而不能工作时，组中其他成员可以接收它目的允许把进程的集合作为规律上单一的对象来处理，增加系统的容错性进程组进程组特性组本身可以是动态的组成员可以是动态的一个进程可以附属于多个组类型：公平组和等级组2、公平组和等级组公平组对应分布式概念全部成员地位都是一样的全部打算都是共同作出的等级组对应集中式概念一般有一个协调者进程，其他则是工作者组内关系和动作由协调者做打算公平组和简洁等级组公平组和等级组公平组没有单独故障点决策效率低等级组有单个故障点决策效率高。3、组成员治理根本问题参加与离开组成员故障处理使用组治理效劳器〔集中式方法〕全部进程要参加或者离开组都向它申请优点：直接，高效，易于实现缺点：单一失败点分布式方法进程参加和离开组需要给全部成员发恳求，共同作出打算当成员发生故障崩溃时，需要通过一些协议来重建组三、牢靠的点对点通信与容错分布式系统通信的牢靠性设计的重点在于掩盖崩溃性故障遗漏性故障随便性故障—通过重复消息的形式排解。对于点到点通信，如TCP通信，崩溃性故障只能由分布式系统重新建立连接。在RPC调用中，有5种失败形式：客户不能定位效劳器客户到效劳器的恳求消息丧失效劳器在收到恳求之后崩溃从效劳器到客户的响应消息丧失客户在发送恳求之后崩溃1、RPC通信失败RPC通信失败2、客户无法定位效劳器与恳求丧失客户端不能定位效劳器由应用程序抛出特别来处理恳求消息丧失超时重发机制3、效劳器崩溃两种状况，但对客户来说，都是超时执行之后崩溃执行之前崩溃三种处理方式在效劳器重启之前等待并再次尝试操作马上放弃并报告失败什么都不保证4、应答消息丧失也是依靠客户端的超时重发机制处理 问题：转帐另一种方法： 为每个客户恳求配一个序列号，这样效劳器就能区分客户的新恳求与重发的恳求，当效劳器收到重发的恳求时，不执行重复操作5、客户崩溃最大问题：孤儿进程的产生RPC调用中，客户进程与它调用的效劳器计算之间是父子关系，当客户崩溃后，驻留在效劳器中连续运行的计算变得毫无意义，而且没有进程等待它、需要它。这个计算就变成了孤儿〔Orphan〕。客户崩溃孤儿会引起很多问题：首先，它的计算毫无意义，由于已经没人需要它的结果孤儿铺张系统资源，包括计算、存储和其他资源当客户恢复并重发恳求时，孤儿返回的结果则会引起混淆客户崩溃第一种方法是消灭在RPC调用之前写日志客户在崩溃中恢复后依据日志杀死孤儿缺点：代价高，每个RPC都需要写日志孤儿本身有可能进展RPC调用而产生后代，杀死孤儿后，其后代成为更难跟踪处理的孤儿。客户崩溃其次种方法是再生对时间分段并编号当客户重启时，向全部机器播送声明一个新时期开头其他机器收到该消息后，杀死全部与这个客户有关的远程计算但对于播送不能到达的地方，孤儿还有可能存活客户崩溃最终一种方法是到期每个RPC都被给定一个期限T来工作到期后如不能完毕就需要申请宽期否则被认为抛弃子女，与其相关的远程计算将被当作孤儿杀死四、牢靠的组通信与容错1、根本的牢靠多播方法多播：发送到进程组的消息被传送到组中全部成员。多播面临的问题：通信期间，有进程参加组通信期间组中有成员崩溃最简洁解决方法：对进程组每个成员建立点到点的连接一种简洁有效的方法如下页图示。简洁的牢靠多播2、牢靠多播的可扩展性简洁方法致命问题 当承受者数量浩大时，大量的反响消息将漂浮发送者，引起反响拥塞。解决方法一：只在消息丧失时反响 问题：发送者只好永久在历史缓存器中保存消息，由于不知道消息是否送达。而且即使否认反响照旧可能拥塞。牢靠多播的可扩展性方法二：无等级反响掌握承受者不发送成功确认当丧失消息时向组中其他成员多播其否认反响而其他成员假设也丧失了消息，则在收到这个丧失反响后不再向发送者发送丧失反响保证了只有一个重发恳求送往发送者。无等级反响抑止牢靠多播的可扩展性无等级反响的实际应用中还是有困难：首先要确保只有一个重发恳求发送到发送者，需要全部承受者对反响进展准确的调度，这在散布在广域网中的进程组是难事。其次多播反响有可能中断其他成功接收消息的进程。牢靠多播的可扩展性方法三：分等级反响掌握接收进程组的成员数量特别大承受组被划分为很多子组，这些子组组织成树的形式，包含发送者的子组构成了树的根在每个子组内，可以选用任意一种牢靠多播方案每个子组都指定一个本地协调者，负责处理子组的接收，以及本地的重发本地协调者具有自己的历史缓存分等级的牢靠多播牢靠多播的可扩展性