分布式系统 Distributed Systems 第 12 讲 协调和协定 Lecture12 Coordination and Agreement 王晓阳、张 奇 复旦大学 计算机科学技术学院

目录 12.1 简介 12.2 分布式互斥 12.3 选举 12.4 组通信中的协调与协定 12.5 共识与相关问题 12.6 小结 12.4.1 基本组播 12.4.2 可靠组播 12.4.3 有序组播 12.5 共识与相关问题 12.5.1 系统模型和问题定义 12.5.2 同步系统中的共识问题 12.5.3 同步系统中的拜占庭将军 问题 12.5.4 异步系统的不可能性 12.6 小结

12.1 简介 本章主要目的是介绍分布式系统中的进程如何协调它们的动作或对 一个或多个值达成协定。 考虑故障以及在设计算法时如何处理故障 本章主要目的是介绍分布式系统中的进程如何协调它们的动作或对 一个或多个值达成协定。 与第11讲一样，一个重要的差别是所研究的分布式系统的是异步的还是 同步的。 考虑故障以及在设计算法时如何处理故障 不容许故障的算法 针对良性故障的算法 如何容许随机故障 在异步分布式系统中，即使良性故障条件下，也不可能保证一组进 程能对一个共享值达成协定。

12.1 简介 12.2节将研究分布式互斥问题 12.3节介绍如何“选举”一组进程中的一个来完成特定任务 这是在内核和多线程应用中避免竞争条件的问题在分布式系统中的扩展 12.3节介绍如何“选举”一组进程中的一个来完成特定任务 例如：进程与一个指定的时间服务器同步 12.4节介绍组播通信中的协调和协定 研究组播的可靠性和排序语义 12.5节从更一般的角度讨论协定问题，主要形式是共识和拜占庭协 议

12.1 简介 故障假设和故障检测器 本章假设每对进程都可通过可靠的通道连接 还假设进程故障不隐含对其他进程的通信能力的威胁 尽管底层网络组件可能出现故障，但进程使用能屏蔽故障的可靠通信协议 还假设进程故障不隐含对其他进程的通信能力的威胁 意味着没有进程依赖于其他进程来转发消息 注意: 一个可靠的通道最终将消息传递到接收者的输入缓冲区。 在同步系统中，我们假设在必要的地方有硬件冗余，以便在出现底层故障时，可靠通道不 仅最终能传递每个消息，而且能在指定的时间内完成传递工作 在某个时间间隔内，一些进程之间的通信可能成功，而另一些进程之间 的通信则被延迟。

Figure 15.1 A network partition Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

12.1 简介 故障假设和故障检测器 复杂的网络拓扑结构和独立的路由选择意味着连接可能是非对称的 (asymmetric) 进程p到进程q可以通信，但反之不行 连接还可能是非传递的 进程p到进程q，以及进程q到进程r都可以通信，但是进程p到进程r不能通信 因此，可靠性假设要包括任何有故障的链接或路由器最终会被修复或避 开的内容。 除非特别说明，本章只假定进程在崩溃时出故障 这个假设对许多系统已经足够 12.5节，将介绍如何对待随机（拜占庭）故障的情况 不论何种故障，一个正确的进程是在所考虑的运行中任何点都没有故障的进程 注意：正确性应用于整个运行，而不是运行的一部分

12.1 简介 故障假设和故障检测器 故障检测器（failure detector） 用于处理有关某个进程是否已出现故障的查询 故障检测器通常是由每个进程中的一个对象实现的，此对象与其他 进程的对应部分一起执行一个故障检测算法 每个进程中的这个对象叫做本地故障检测器（local failure detector）

12.1 简介 故障假设和故障检测器 不可靠故障检测器（unreliable failure detector） 当给出一个进程标识时，一个不可靠故障检测器会产生两个值： Unsuspected：表示检测器最近已收到表明进程没有故障的证据 例如：最近从该进程收到一个消息，但是进程可能在此后出现的了错误 Suspected：表示故障检测器有迹象表明进程可能出现故障了 例如：在多于最长沉默时间里没有收到来自进程的消息 这样的怀疑也可能是错的 可靠的故障检测器（reliable failure detector） 能够精确检测进程故障的检测器 对于进程的问询，可以给出： Failed：表示检测器确定进程已崩溃

12.1 简介 故障假设和故障检测器 不可靠故障检测器实现 每个进程p向其他所有进程发送消息”p is here”，并且每隔T秒发送一次 故障检测器用最大消息传输时间D秒，作为评估值 如果进程q的本地故障检测器在最后一次T+D秒内没有收到”p is here”消 息，则向q报告p是Suspected 但是如果后来收到”p is here”消息，则向q报告p是OK 注意：需要讨论的是T和D的选取问题

12.2 分布式互斥 分布式进程常常需要协调它们的动作 如果一组进程共享一个或一组资源，那么访问这些资源时，常需要互斥 来防止干扰并保证一致性 在操作系统领域中常见的临界区问题 在分布式系统中需要一个仅基于消息传递的分布式互斥问题解决方案 在某些情况下，管理共享资源的服务器也提供互斥机制。另外一些 情况下，则需要一个单独的用于互斥的机制 考虑多个用户更新一个文本文件的情况 保证更新一致性的简单方法：要求编辑器在更新之前锁住文件，一次只 允许一个文件用户访问文件

12.2 分布式互斥 互斥算法 考虑无共享变量的N个进程pi，（i=1，2，….，N）的系统 这些进程只在临界区访问公共资源 假设： 只有一个临界区 系统是异步的 进程不出故障 消息传递是可靠的 任何消息被完整的恰好发送一次

12.2 分布式互斥 互斥算法 执行临界区的应用层协议： 对互斥的基本要求： enter 0 resourceAccesses 0 exit 0 对互斥的基本要求： ME1：安全性，在临界区（CS）一次最多有一个进程执行 ME2：活性，进入和离开临界区的请求最终成功执行 隐含既无死锁也无饥饿问题 ME3：顺序，如果一个进入CS的请求发生在先，那么进入CS时仍按此 顺序

12.2 分布式互斥 互斥算法 互斥算法性能的评价标准： 消耗的带宽，与每个entry和exit所发送的消息量成正比 算法对系统吞吐量的影响 一个进程离开临界区和下一个进程进入临界区之间的同步延迟（synchronization delay）来 衡量这个影响

12.2 分布式互斥 中央服务器算法 使用一个服务器来授予进入临界区的许可 Figure 15.2 Server managing a mutual exclusion token for a set of processes

12.2 分布式互斥 满足安全性和活性要求，但不满足顺序要求。 性能 带宽消耗 客户延迟 同步延迟 性能瓶颈 enter():2个消息，即请求消息和授权消息 exit(): 1个消息，即释放消息 客户延迟 消息往返时间导致请求进程延迟 同步延迟 1个消息的往返时间 性能瓶颈 服务器

12.2 分布式互斥 基于环的算法 Figure 15.3 A ring of processes transferring a mutual exclusion token

12.2 分布式互斥 满足安全性和活性要求，但不满足顺序要求。 性能 带宽消耗 客户延迟 由于令牌的传递，会持续消耗带宽 Min: 0个消息，正好收到令牌 Max: N个消息，刚刚传递了令牌 同步延迟 Min: 1个消息，进程依次进入临界区 Max: N个消息，一个进程连续进入临界区，期间无其他进程进入临界区

12.2 分布式互斥 使用组播和逻辑时钟的算法 基本思想 进程进入临界区需要所有其它进程的同意 并发控制 组播+应答 采用Lamport时间戳避免死锁

12.2 分布式互斥 初始化： state:=RELEASED; 为了进入临界区： state:=WAITED; 组播请求给所有进程; Wait until (接收到的应答数=(N－1)); state:=HELD; 在pj(i≠j)接收一个请求<Ti,pi> if (state = HELD or (state = WANTED and (T, pj) < (Ti, pi))) then 将请求放入pi队列,不给出应答; else 马上给pi应答; end if 为了退出临界区： state := RELEASED; 对已进入队列的请求给出应答; 请求处理在此被延期

12.2 分布式互斥 示例 　p1、p2并发请求进入临界区

12.2 分布式互斥 满足安全性、活性和顺序要求。 性能 带宽消耗 客户延迟 同步延迟 　　enter(): 2(N－1)，即(N－1)个请求、 (N－1)个应答 客户延迟 　　 1个消息往返时间 同步延迟 　　 1个消息的传输时间

12.2 分布式互斥 基本思想 Maekawa投票算法 进程进入临界区需要部分其它进程的同意 每个进程pi关联到一个选举集Vi Vi  {p1, p2, …, pn} pi  Vi Vi Vj   | Vi |= K,To be fair, K  每个进程pj包括在选举集Vi中的 M个集合中，M = K 选举的过程

12.2 分布式互斥 Maekawa算法伪码 On initialization state := RELEASED; voted := FALSE; For pi to enter the critical section state := WANTED; Multicast request to all processes in Vi; Wait until (number of replies received = K); state := HELD; On receipt of a request from pi at pj if (state = HELD or voted = TRUE) then queue request from pi without replying; else send reply to pi; voted := TRUE; end if For pi to exit the critical section state := RELEASED; Multicast release to all processes in Vi; On receipt of a release from pi at pj if (queue of requests is non-empty) then remove head of queue – from pk, say; send reply to pk; voted := TRUE; else voted := FALSE; end if Maekawa算法伪码

12.2 分布式互斥 Maekawa算法会产生死锁 三个进程p1、p2和p3，且V1={p1, p2}， V2={p2, p3}， V3={p3, p1}。 若三个进程并发请求进入临界区，考虑下列情况： 　　1. p1应答了自己，但延缓p2； 2. p2应答了自己，但延缓p3； 　　3. p3应答了自己，但延缓p1。 p1 p2 p3 Voted=TRUE

12.2 分布式互斥 Maekawa算法改进后可满足安全性、活性和顺序性 进程按发生在先顺序对待请求队列 性能 - 带宽消耗 　进程按发生在先顺序对待请求队列 性能 - 带宽消耗 　　 　: 即进入需要　个消息，退出需要　个消息 - 客户延迟 　　 1个消息往返时间 　 - 同步延迟 　　 较差，1个往返时间，非单个消息的往返时间

12.3 选举 基本概念 选举算法(election algorithm) 选择一个唯一的进程来扮演特定角色的算法 　　选择一个唯一的进程来扮演特定角色的算法 召集选举(call the election) 　　一个进程启动了选举算法的一次运行 参加者(participant) 　　进程参加了选举算法的某次运行 非参加者(non-participant) 　　进程当前没有参加任何选举算法 进程标识符 　　唯一且可按全序排列的任何有用的数值 为什么需要选举算法：中央服务器算法变种的例子，

12.3 选举 每个进程pi有一个变量electedi ，用于表示当选进程的标识符。 当进程第一次成为选举参与者时，变量值为 基本要求 　　参与的进程pi有electedi =或electedi = P E2：活性 所有进程pi都参加并且最终置electedi ≠或进程pi崩溃 性能评价 带宽消耗 回转时间 　从启动算法到终止算法之间的串行消息传输的次数

12.3 选举 基于环的选举算法 目的 　在异步系统中选举具有最大标识符的进程作为协调者 基本思想 　按逻辑环排列一组进程

12.3 选举 算法 最初，每个进程标记为选举中的非参与者 任何进程可以开始一次选举 将自身标记为参与者 idmsg = idlocal , 发送 选举消息{elect, idmsg}至邻居 非参与者转发选举消息 发送 {elect, MAX(idlocal, idmsg)}至邻居 当 idlocal=idmsg时，该进程成为协调者 将自身标记为非参与者 idcoordinator = idlocal, 发送当选{elected, idcoordinator }至邻居 参与者转发选举结果消息 记录idcoordinator

12.3 选举 基于环的选举算法示例 选举从进程17开始。到目前为止，所遇到的最大的进 程标识符是24。参与的进程用深色表示。

12.3 选举 基于环的选举算法的性能 最坏情况 最好情况 不具备容错功能 启动选举算法的逆时针邻居具有最大标识符，共计需要3N－1 个消息，回转时间为3N－1 最好情况 回转时间为2N 不具备容错功能

12.3 选举 霸道算法 假设 同步系统，使用超时检测进程故障 通道可靠，但允许进程崩溃 每个进程知道哪些进程具有更大的标识符 每个进程可以和所有具有更大标识符的进程通信

12.3 选举 霸道算法 3种类型的消息 一个进程通过超时发现协调者已经出现故障，并开始 一个选举，几个进程可能同时观察到此现象 选举消息，用于宣布选举 应答消息，用于回复选举消息 协调消息，用于宣布当选进程的身份 一个进程通过超时发现协调者已经出现故障，并开始 一个选举，几个进程可能同时观察到此现象 采用同步系统，因此可以构造一个可靠的故障检测器

12.3 选举 霸道算法 进程P在发现协调者失效后启动一次选举，将选举消息发送给具有更大 标识符的进程，并等待应答。 若进程P 在时间T内没有收到回答消息，则认为自己为协调者，并给所有具有 较小标识符的进程发送协调者消息。 若进程P 收到回答消息，则等待协调者消息；若消息在一段时间内没有到达， 则启动一次新的选举算法。 进程收到协调者信息后，设置 electedi = idcoordinator 进程收到选举消息，回送一个应答消息，并开始另一次选举，除非它已 经开始了一次选举 进程如果知道自己具有最大标识符，则会决定自己是协调者，并向其他 进程宣布

12.3 选举 霸道算法示例 p4、p3相继出现故障

12.3 选举 霸道算法示例性能 最好情况 = N－2 标识符次大的进程发起选举 发送N－2个协调者消息 回转时间为1个消息 最坏情况 = O(N2) 标识符最小的进程发起选举

12.4 组播通信中的协调与协定 组播/广播 组播面临的挑战 组播：发送一个消息给进程组中的每个进程。 广播：发送一个消息给系统中的所有进程。 组播面临的挑战 效率 　 - 带宽使用 - 总传输时间 传递保证 　 - 可靠性 - 顺序 进程组管理 　进程可任意加入或退出进程组

12.4 组播通信中的协调与协定 系统模型 multicast(g, m)操作 1个进程发送消息给进程组g的所有成员 系统包含一组进程，它们可以通过一对一的通道可靠地进行通信。 进程在崩溃时才出现故障 multicast(g, m)操作 　1个进程发送消息给进程组g的所有成员 deliver(m)操作 　 传递由组播发送的消息到调用进程

12.4 组播通信中的协调与协定 系统模型 开放组和封闭组 封闭组 开放组

12.4.1 基本组播 基本组播 简单实现 多线程 确认爆炸(ack-implosion) 一个正确的进程最终会传递消息 原语: B-multicast、B-deliver 可靠组播，与IP组播不同 简单实现 B-multicast(g,m)：对每个进程p∈g，send(p,m) 进程p receive(m)时：p执行B-deliver(m) 多线程 利用线程来并发执行send操作 确认爆炸(ack-implosion) 确认从许多进程几乎同时到达 组播进程丢弃部分确认消息导致重发现象 可靠的一对一操作

12.4.2 可靠组播 可靠组播 性质 有效性(validity) 协定(agreement)——具有原子性 完整性(integrity) 　　一个正确的进程p传递一个消息m至多一次 有效性(validity) 　　如果一个正确的进程组播消息m，那么它终将传递m。 协定(agreement)——具有原子性 　　如果一个正确的进程传递消息m，那么在group(m)中的其它正 确的进程终将传递m。

12.4.2 可靠组播 用B-multicast实现可靠组播

12.4.2 可靠组播 算法评价 满足有效性 一个进程的最终将B-deliver消息到它自己。 满足完整性 　　B-multicast中的通信通道具有完整性 遵循协定 　　每个正确的进程在B-deliver消息后都B-multicast该消息到其它进程 效率低 　　每个消息被发送到，每个进程|g|次。

12.4.2 可靠组播 用IP组播实现可靠组播 特点 基于IP组播 IP组播通信通常是成功的 捎带确认 在发送给组中的消息中捎带确认 　　在发送给组中的消息中捎带确认 否认确认 　　进程检测到它们漏过一个消息时，发送一个单独的应答消息。

12.4.2 可靠组播 算法 Sgp: 进程为它属于的组g维护的序号，初始化为0。 　Rgp: 进程记录来自进程q并且发送到组g的最近消息的序号。 　R-multicast 一个消息到组g: 捎带Sgp和确认，即<q, Rgq >; Sgp = Sgp +1 　R-deliver 一个消息: 1. 当且仅当m.S = Rgp +1传递消息； Rgp = Rgp +1 2. 若m.S <= Rgp, 则该消息已传递，直接丢弃。 3. 若m.S > Rgp +1或对任意封闭的确认<q, Rgq >有m.R > Rgq, 则漏掉了一 个或多个消息,将消息保留在保留队列中,并发送否认确认。

12.4.2 可靠组播 Figure 15.10 The hold-back queue for arriving multicast messages

12.4.2 可靠组播 算法评价 完整性 通过检测副本和IP组播性质实现 有效性 仅在IP组播具有有效性时成立 协定 进程无限组播消息时成立 　　进程无限组播消息时成立 某些派生协议实现了协定

12.4.2 可靠组播 统一性质 统一 无论进程是否正确都成立的性质 统一协定 　　无论进程是否正确都成立的性质 统一协定 　　如果一个进程传递消息m，不论该进程是否正确还 是出故障，在group(m)中的所有正确的进程终将传递 m。

12.4.2 可靠组播 符合统一协定的算法示例 若颠倒这两行，则算法不满足统一协定

12.4.3 有序组播 有序组播 FIFO排序 因果排序 全排序 如果一个正确的进程发出multcast(g,m)，然后发出multicast(g,m’)，那么 每个传递m’的正确的进程将在m’前传递m。 因果排序 如果multcast(g,m) → multicast(g,m’) ，那么任何传递m’的正确进程将在 m’前传递m。 全排序 如果一个正确的进程在传递m’前传递消息m，那么其它传递m’的正确 进程将在m’前传递m。

12.4.3 有序组播 Notice the consistent ordering of totally ordered messages T1 and T2, the FIFO-related messages F1 and F2 and the causally related messages C1 and C3 – and the otherwise arbitrary delivery ordering of messages. Figure 15.11 Total, FIFO and causal ordering of multicast messages

12.4.3 有序组播 Figure 15.12 Display from bulletin board program os.interesting Item From Subject 23 A.Hanlon Mach 24 G.Joseph Microkernels 25 A.Hanlon Re: Microkernels 26 T.L’Heureux RPC performance 27 M.Walker Re: Mach end Figure 15.12 Display from bulletin board program

12.4.3 有序组播 实现FIFO排序 基于序号实现 FO-multicast/FO-deliver 算法 　与基于IP组播的可靠组播类似，即采用Sgp、 Rgq和 保留队列

12.4.3 有序组播 为组播消息指定全排序标识符 TO-multicast/TO-deliver 使用顺序者的全排序算法 实现全排序 　1. 组成员p的算法 　初始化：rg:=0; 为了给组g发TO-multicast消息： 　 B-multicast(g∪{sequencer(g)},<m,i>);　 在B-deliver(Morder=<“order”,I,s>)时，其中g=group(Morder) Wait until <m,i>在保留队列中并且S=rg; To-deliver m; //在从保留队列删除它之后 rg=S+1;　

12.4.3 有序组播 使用顺序者的全排序算法(续) 基于顺序者的算法缺点：顺序者会成为瓶颈 2. 顺序者g的算法 初始化：sg:=0; 在B-deliver(<m,i>)时，其中g=group(Morder) 　　B-multicast(g,<“orer”,I,sg>); sg:=sg+1;　 基于顺序者的算法缺点：顺序者会成为瓶颈

12.4.3 有序组播 全排序的ISIS算法 2 1 1 消息 2 建议的序号 P 3 4 3 协定的序号

12.4.3 有序组播 全排序的ISIS算法 Agq: 进程迄今为止 从组g观察到的最大的协定序号 Pgq : 进程自己提出的最大序号 进程p组播消息m到组g的算法： 　　1. p B-multicasts <m, i>到g， 其中i 是m的一个委员的标识符 　　2. 每个进程： (1) Pgq = max(Agq, Pgq)+1; (2)把 Pgq添加到消息 m，并 把m放入保留队列; (3)用序号Pgq 回答p 3. P收集Pgq,选择最大的数a作为下一个协定序号，然后 B- multicast<i,a> 到g 4. g中的每个进程q置Agq: = max(Agq, a), 并把a附加到消息上。

12.4.3 有序组播 全排序的ISIS算法 1. 正确的进程最终会对同一组序号达成一致； 2. 序号是单调递增的； 　　1. 正确的进程最终会对同一组序号达成一致； 　　2. 序号是单调递增的； 　　3. 不保证因果或FIFO序； 　　4. 比基于顺序者的组播有更大的延迟

12.4.3 有序组播 实现因果排序 向量时间戳 CO-multicast CO-deliver 每个进程维护自己的向量时间戳 　每个进程维护自己的向量时间戳 CO-multicast 在向量时间戳的相应分量上加1，附加时间戳到消息 CO-deliver 　根据时间戳递交消息

12.4.3 有序组播 使用向量时间戳的因果排序算法 CO-deliver m; //在把它从保留队列删除后 对组成员pi (i=1,2,…,N)的算法 初始化： 　 Vig[j]:=0 (j=1,2,…M); 为了给组g发CO-multicast消息m: Vig[j]=Vig[j]+1; B-multicast(g,<Vig,m>); 在B-deliver(<Vig,m>)来自pj(i≠j)的一个消息时，其中g=group(m); 将<Vig,m>放入保留队列,直到Vig[j]=Vig[j]+1和Vig[j]=Vig[j]+1 (k ≠j); CO-deliver m; //在把它从保留队列删除后 　　Vig[j]=Vig[j]+1;

12.4.3 有序组播 组重叠 全局FIFO排序 全局的因果排序 　　如果一个正确的进程发出multicast(g,m)，然后发出 multicast(g’,m’)，则两个消息被发送到g∩g’的成员。 全局的因果排序 　　如果multicast(g,m) → multicast(g’,m’) ，则g∩g’中的任何传 递m’的正确进程将在m’前传递m。

12.4.3 有序组播 进程对的全排序 如果一个正确的进程在传递发送到g’的消息m’前传递 了发送到g的消息m，则g∩g’中的任何传递m’的正确 进程将在m’前传递m。 全局的全排序 令“<”是传递事件之间的排序关系。我们要求“〈”遵 守进程对的全排序，并且无环。

12.5 共识和相关问题 简介 分布式系统中的协定问题 共识问题 故障模型 一个或多个进程提议了一个值后，应达成一致意见 互斥：哪个进程可以进入临界区 全排序组播：组播消息的顺序 拜占庭将军：进攻还是撤退 共识问题 一个或多个进程提议了一个值后，应达成一致意见 共识问题、拜占庭将军和交互一致性问题 故障模型 进程崩溃故障、拜占庭进程故障

12.5.1 系统模型和问题定义 共识问题定义 符号 　 - pi: 进程i - vi: 进程pi的提议值 　 - di: 进程pi的决定变量

12.5.1 系统模型和问题定义 3个进程的共识问题示例 1 P (崩溃) 共识算法 v =proceed =abort d

12.5.1 系统模型和问题定义 共识算法的基本要求 终止性 协定性 完整性 每个正确的进程最终设置它的决定变量 　　每个正确的进程最终设置它的决定变量 协定性 　　如果pi和pj是正确的且已进入决定状态，那么di=dj ，其中 i,j=12,…N。 完整性 　　如果正确的进程都提议了同一个值，那么处于决定状态的任 何正确进程已选择了该值。

12.5.1 系统模型和问题定义 算法 - 每个进程组播它的提议值 - 每个进程收集其它进程的提议值 　 - 每个进程组播它的提议值 - 每个进程收集其它进程的提议值 　 - 每个进程计算V = majority (v1, v2, …, vN) 　　majority()函数为抽象函数，可以是max()、min()等等 算法分析 　 - 终止性 　由组播操作的可靠性保证 　 - 协定性和完整性 　　由majority()函数定义和可靠组播的完整性保证　

12.5.1 系统模型和问题定义 拜占庭将军问题 问题描述 - 3个或更多的将军协商是进攻还是撤退 - 一个或多个将军可能会叛变 　 - 3个或更多的将军协商是进攻还是撤退 - 一个或多个将军可能会叛变 　 - 所有未叛变的将军执行相同的命令 与共识问题的区别 　　每个进程(将军)都提议一个值 算法要求 　 - 终止性 - 协定性　 　 - 完整性

12.5.1 系统模型和问题定义 交互一致性 就一个值向量达成一致 - 决定向量: 向量中的每个分量与一个进程的值对应 算法要求 - 终止性 　 - 决定向量: 向量中的每个分量与一个进程的值对应 算法要求 　 - 终止性 每个正确进程最终设置它的决定变量 - 协定性 所有正确进程的决定向量都相同　 　 - 完整性 如果进程pi是正确的,那么所有正确的进程都把vi作 为他们决定向量中饿第i个分量.

12.5.1 系统模型和问题定义 共识问题与其它问题的关联 目的 重用已有的解决方案 问题定义 - 共识问题C Ci(v1,v2,…vN): 返回进程pi的决定值 - 拜占庭将军BG BGi(j,v): 返回进程pi的决定值,其中pj是司令,它建议 的值是v　 　 - 交互一致性问题IC ICi(v1,v2,…,vN)[j]: 返回进程pi的决定向量的第j个分 量

12.5.1 系统模型和问题定义 从BG构造IC - 将BG算法运算N次,每次都以不同的进程pi作为司令 - ICi(v1,v2, …, vN )[j] = BGi(j,v), (i, j = 1, 2, …, N) 从IC构造C 　 - Ci(v1,v2, …, vN ) = majority(ICi(v1,v2, …, vN )[1],…, ICi(v1,v2, …, vN )[N]) 从C构造BG - 司令进程pj把它提议的值v发送给它自己以及其余进程 - 所有的进程都用它们收到的那组值v1,v2, …, vN作为参数 运行C算法 - BGi(j,v) =Ci(v1,v2, …, vN ), (i = 1, 2, …, N)

12.5.2 同步系统中的共识问题 同步系统中的共识问题 故障假设 N个进程中最多有f个进程会出现崩溃故障 算法 对pi∈g的进程算法: 算法进行到f+1轮 初始化: valusesi1:={vi}; Valuesi0={}; 在第r轮(1≤r ≤f+1) B-multicast(g,Valuesir－Valuesir-1); //仅发送还没有发送的值 Valuesir+1:=Valuesir; While(在第r轮) { 在B-deliver(Vj)来自pj的消息时: Valuesir+1:=Valuesir+1∪Vj;} 在(f+1)轮之后 将d赋成min(Valuesif+1);

12.5.2 同步系统中的共识问题 算法分析 终止性质 由同步系统保证 协定性和完整性 假设pi得到的值是v,而 pj不是 Pk1在把v传送给pi后,还没来得及传送给 pj就崩溃了 Pk2在把v传送给pi后,还没来得及传送给 pj就崩溃了 … Pk(f+1)在把v传送给pi后,还没来得及传送给 pj就崩溃了 但我们假设至多有f个进程崩溃 因此,pi和pj的值相同 因此,min(Valuesif+2)相同

12.5.3 同步系统中的拜占庭将军问题 随机故障假设 - N个进程中最多有f个进程会出现随机故障 N≤3f - 无解决方法 N≥3f+1 - Lamport于1982给出了解决算法

12.5.3 同步系统中的拜占庭将军问题 三个拜占庭将军 p (司令) 1:v 2:1:v 3:1:u 1:x 1:w 2:1:w 有故障的进程用灰色表示

12.5.3 同步系统中的拜占庭将军问题 三个进程的不可能性 - 如果存在一个解决方法, 在左边的场景中,根据完整性 条件,p2选择1:v - 由于p2不能分别这两个场景,因此p2在右边的场景中选 择1:w - 根据对称性, p3在右边的场景中选择1:x - 与协定定义矛盾 三个进程实现拜占庭协定 - 对发出的消息使用数字签名

12.5.3 同步系统中的拜占庭将军问题 对于N≤3f的不可能性 - n1,n2,n3 将N个将军分成3组，n1+n2+n3=N且n1,n2,n3 ≤N/3 - p1, p2,p3 让进程p1,p2,p3分别模仿n1,n2,n3个将军 - 根据对称性, p3在右边的场景中选择1:x - 若存在一个解决方法，即达成一致且满足完整性条件 - 与三个进程的不可能性结论矛盾

12.5.3 同步系统中的拜占庭将军问题 对一个有错进程的解决方案 - 假设N=4,f=1 - 正确的将军通过两轮消息取得一致 第一轮，司令给每个中尉发送一个值 第二轮，每个中尉将收到的值发送给与自己同级的 每个中尉执行majority()函数

12.5.3 同步系统中的拜占庭将军问题 ４个拜占庭将军示例 p 左边： d2 = majority(v, u, v) = v， (司令) 2 3 1:v 2:1:v 3:1:u 有故障的进程用灰色显示 4 4:1:v 3:1:w 1:w 1:u 2:1:u 左边： d2 = majority(v, u, v) = v， 　　　 d4 = majority(v, v, w) = v 右边： d2 = d3 ＝d4＝majority(u, v, w) = 

12.5.3 同步系统中的拜占庭将军问题 性能讨论 - 衡量标准 - Lamport算法 - Fischer和Lynch于1982年证明 进行了多少轮消息传递？ 发送了多少消息，消息的长度是多少？ - Lamport算法 f+1轮转 O(Nf+1)条消息 - Fischer和Lynch于1982年证明 如果允许出现拜占庭故障，那么任何确定性的解决共识问题的算法至少需要f+1轮消息传 递。

12.5.4 异步系统的不可能性 没有算法能够保证达到共识 - 无法分辨一个进程是速度很慢还是已经崩溃 故障屏蔽 - 屏蔽发上的所有进程故障 使用故障检测器达到共识 - 在仅依靠消息传递的异步系统中，不存在完美的故 障检测器，甚至是最弱的故障检测器。 使用随机化达到共识 - 引入一个关于进程行为的可能性元素。

Question?