分布式数据库中的事务管理和恢复课件1.ppt

1、1.1.分布式事务概述分布式事务概述2.2.分布式事务的执行和恢复分布式事务的执行和恢复3.3.两阶段提交协议两阶段提交协议4.4.分布式数据库中的数据更新分布式数据库中的数据更新5.5.分布式事务增强数据库一致性分布式事务增强数据库一致性6.6.总结总结分布式数据库中的事务管理和恢复分布式数据库中的事务管理和恢复 第第4章章事务概念 事务是访问或更新各种数据项的最小逻辑工作单位。它是一个操作序列 它可以使数据库从一个一致状态到另外一个一致状态 事务必须保证数据库的一致性 事务执行期间数据库可能不一致1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述 当事务提

2、交（commit）时数据库必须是一致的事务T开始事务T结束事务T的执行数据库一致数据库一致数据库可能临时不一致1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述事务概念分布式事务 集中式 事务和操作数据在一个站点上 不存在传输费用 分布式 操作数据分布在不同的站点上 事务也在多个站点上执行 分布式事务是集中式事务的扩充 站点和通信链路故障都可能导致错误发生 分布式事务的恢复要比集中式事务复杂的多1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述 事务分类:全局事务 通常由一个主事务和在不同站点上执行的子事务组成 主事务：负责事

3、务的开始、提交和异常终止 子事务：完成对相应站点上的数据库的访问操作 局部事务 仅访问或更新一个站点上的数据的事务1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述分布式数据库中的事务分布式数据库中的事务 ACID特性 原子性（原子性（Atomicity）事务的操作要么全部执行,要么全部不执行,保证数据库一致性状态 一致性（一致性（Consistency）事务的正确性，串行性，并发执行的多个事务,其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同.持久性（持久性（Durability）当事务提交后,其操作的结果将永久化,而与提交后发生的故障无关 1.1

4、 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述分布式事务特性分布式事务特性 隔离性（Isolation）虽然可以有多个事务同时执行，但是单个事务的执行不应该感知其他事务的存在，因此事务执行的中间结果应该对其他并发事务隐藏 此外，分布式数据库系统中还要考虑数据传送、通信原语和控制报文等。全局事务的主事务和子事务全部成功提交，才能改变数据库状态，有一个失败，其他子事务操作都要撤销。1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述分布式事务特性分布式事务特性 从账号A向账号B转账$50:1.read(A)2.A:=A 50 3.wr

5、ite(A)4.read(B)5.B:=B+50 6.write(B)1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述分布式事务特性举例分布式事务特性举例 一致性要求:事务执行后A 和 B账号的总金额不变 原子性要求:如果事物在第3步和第6步之间故障,系统应该保证事务对数据库的修改没有产生,否则将导致不一致性1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述分布式事务特性举例分布式事务特性举例 持久性要求:一旦用户通知说事务已经完成（即$50 转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此1.

6、1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述分布式事务特性举例分布式事务特性举例 独立性要求 如果在第 3步和第6步之间,允许其他事务访问被修改的数据库的中间结果,那么它将见到一个不一致的数据库(也就是说，A+B 的和少于它的正确值）当然事务的串行执行将不会出现这种情况，但是数据库中事务并行执行的优点就损失了1.1 分布式事务定义和特性分布式事务定义和特性1 1 分布式事务概述分布式事务概述分布式事务特性举例分布式事务特性举例Begin Transaction原语：开始一个事务 T1 T2 :子事务或操作序列 :TnCommit原语：事务成功完成的结束Rol

7、lback或Abort原语：事务失败的结束1.2 分布式事务结构和事务状态分布式事务结构和事务状态1 1 分布式事务概述分布式事务概述分布式事务的一般结构分布式事务的一般结构 活动 从事务开始执行的初始状态始，事务执行中保持该状态 部分提交 事务的最后一个语句执行后进入该状态.失败 一旦发现事务不能正常执行时进入该状态一旦发现事务不能正常执行时进入该状态 夭折 当事务被回滚后，数据库恢复到事务开始执行前当事务被回滚后，数据库恢复到事务开始执行前的状态。的状态。事务夭折后有两种选择 重启动 仅当没有内部逻辑错误时 杀死 提交 当事务成功执行后.1.2 分布式事务结构和事务状态分布式事务结构和事务

8、状态1 1 分布式事务概述分布式事务概述分布式事务的状态分布式事务的状态1.2 分布式事务结构和事务状态分布式事务结构和事务状态1 1 分布式事务概述分布式事务概述分布式事务的状态分布式事务的状态 进程：系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成的 进程说明：定义进程的行为模式，数据和数据上的操作，功能等 进行执行：按模式来启动这个进程，执行其中的操作 过程：不可并行执行的操作序列 事务代理（Agent）：应用在各个Site上执行的若干进程，称作应用在该Site上的代理。代理可以执行应用程序员写的程序，也可以执行系统的原语函数，不同代理间通过报文实现通讯 根代理（

9、Root Agent）应用启动Site上的代理。根代理所在的Site称作原发Site.一般，根代理负责发系统原语，只有根代理可以请求创建新代理。1.2 分布式事务结构和事务状态分布式事务结构和事务状态1 1 分布式事务概述分布式事务概述进程相关定义进程相关定义 为了协调执行分布式应用的全局操作，分驻于不同站点的诸事务代理必须进行协调，有如下规定：每一应用都有一个负责启动整个事务的总代理（或称根代理）只有总代理才能发出全局有效的事务开始、提交和撤消原语 只有总代理才能请求建立新的事务代理 各站点上的子事务都执行成功，总代理才能决定提交该事务，否则总代理将决定撤销该事务1.2 分布式事务结构和事务

10、状态分布式事务结构和事务状态1 1 分布式事务概述分布式事务概述进程协作进程协作转账应用事务在两个账户之间执行“基金汇兑”操作。如果汇兑的金额小于转出帐号现有金额，就撤销如果大于等于就提交全局关系 Account(Account-number,Amount)假设账户分布在网络的不同站点上。1.2 分布式事务结构和事务状态分布式事务结构和事务状态1 1 分布式事务概述分布式事务概述全局级转帐事务FUND_TRANSFER:read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;select AMOUNT into$FROM_AMOUN

11、T from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC;if$FROM_AMOUNT-$AMOUNT0 then abortelse begin update ACCOUNT set AMOUNT=AMOUNT-$AMOUNT where ACCOUNT_NUMBER=$FROM_ACC;update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT_NUMBER=$TO_ACC;commitend输入：汇出金额和转入/转出帐号事务开始：检查转出帐号中是否 有足够的转出资金？更新转出帐号存款余额创建AGENT1向

12、代理1送消息：转入帐号，金额等待来自AGENT1的消息成功？提交事务：成功结束撤消事务：失败结束ROOT_AGENTAGENT接收来自根代理的信息更新转入帐号存款余额发送执行消息给根代理(成功或失败)是否否转账应用处理流程ROOT_AGENT;read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;select AMOUNT into$FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC;if$FROM_AMOUNT-$AMOUNT0 then abortelse begin

13、 update ACCOUNT set AMOUNT=AMOUNT-$AMOUNT where ACCOUNT_NUMBER=$FROM_ACC;create AGENT;send to AGENT($AMOUNT,$TO_ACC);commit/*这里省略了等待消息和判别*/endAGENT;receive from ROOT_AGENT($AMOUNT,$TO_ACC);update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT=$TO_ACC;send to ROOT_AGENT(SUCCESS/FALL)转账事务的两个代理分布式事务管理

14、问题分布式事务管理问题处理数据项的多个副本 分布式事务处理负责保持同一数据的多个副本之间的一致性。当某个副本所在站点发生故障时，负责生成与该数据其他副本一致的拷贝，以便于及时恢复。单个站点的故障 一个站点或多个站点故障时，DDBMS继续与其他正常运行的站点一起继续工作 当故障站点恢复时，DDBMS协同故障站点的DBMS，必须使得该站点与系统连接时，局部数据库与其他站点同步通信网络的故障 必须能够处理两个或者多个站点间的通信网络故障分布式提交 如果提交分布式事务过程中有一个站点发生故障，提交就会产生问题 两阶段提交协议用于解决这一问题1.3 分布式事务管理的问题和目标分布式事务管理的问题和目标1

15、 1 分布式事务概述分布式事务概述分布式事务管理目标分布式事务管理目标 目的：事务能有效、可靠、并发的执行 除了策略之外，效率的几个重要方面 CPU和主存的使用 控制报文 响应时间 可用性 目标 维护事务的ACID性质 获得最小的主存和CPU开销，降低报文数目，加快响应时间 获得最大限度的可靠性和可用性1.3 分布式事务管理的问题和目标分布式事务管理的问题和目标1 1 分布式事务概述分布式事务概述抽象模型抽象模型LTM:Local Transaction Manager DTM:Distributed Transaction Manager2.1 分布式事务管理的抽象模型分布式事务管理的抽象模

16、型2 2 分布式事务的执行与恢复分布式事务的执行与恢复本地事务管理器 LTM1本地事务管理器 LTM2本地事务管理器 LTMn分布式事务管理器 DTM1分布式事务管理器 DTM2分布式事务管理器 DTMn站点 n站点 2站点 1事务管理事务管理 DTM功能 保证分布式事务ACID特性，特别是原子性，使每一站点的子事务都成功执行，或者都不执行。通过向各站点发begin-transaction,commit或者abort,create原语来实现的 负责协调由该站点发出的所有分布式事务的执行 启动分布式事务的执行 将分布式事务分解为子事务，并将其分派到恰当的站点上执行 决定分布式事务的终止（子事务都

17、提交或者都撤销）支持分布式事务执行位置透明性 实现了对网络上各站点的各子事务的监督和管理 完成对整个分布式事务执行过程的调度和管理 保证分布式数据库系统的高效率Log原语：Local Begin-Trans,Local-Commit,Local-Abort2.1 分布式事务管理的抽象模型分布式事务管理的抽象模型2 2 分布式事务的执行与恢复分布式事务的执行与恢复事务管理事务管理 LTM功能 保证本地事务的ACID特性 维护一个用于恢复的日志，代替DTM把分布事务的执行与恢复信息记入日志 参与适当的并发控制模式，以协调在该站点上执行的事务的并发执行。接收并遵从本Site上DTM发来的Log原语，

18、记入Log并执行之Log原语：Local Begin-Trans,Local-Commit,Local-Abort2.1 分布式事务管理的抽象模型分布式事务管理的抽象模型2 2 分布式事务的执行与恢复分布式事务的执行与恢复分布式事务执行的控制模型分布式事务执行的控制模型 是指协调分布式事务中各成员DBMS执行其子事务的通用方法，有三种:主从模型：主、从控制器，LTM之间无通信 三角模型：LTM之间可以传递数据，避免了主从之间不必要的传输 层次控制模型：LTM还可再创建Agent，控制其它LTM执行，比前两种复杂2.2 分布式事务执行的控制模型分布式事务执行的控制模型2 2 分布式事务的执行与恢

19、复分布式事务的执行与恢复分布式事务管理器局部事务管理器局部事务管理器局部事务管理器数据库数据库数据库命令命令命令回答回答回答主从控制模型分布式事务管理器局部事务管理器局部事务管理器数据库数据库命令命令回答回答临时数据三角控制模型分布式事务管理器局部事务管理器数据库命令命令回答回答局部事务管理器局部事务管理器局部事务管理器局部事务管理器局部事务管理器命令命令命令命令回答回答回答回答数据库数据库数据库数据库数据库层次控制模型 故障类型 事务故障 由非预期的、不正常的程序结束所造成的故障，即事务没有执行到Commit或显示Rollback语句的故障，如：计算溢出、完整性破坏、操作员干预、输入输出错误

20、、死循环等）处理方法：内存、磁盘上信息没有损失，使用Log做Rollback 系统故障 造成系统停止运行的任何事件，要求系统重启动，如CPU出错、缓冲区满、系统崩溃等 处理方法：内存、I/O Buffer内容皆丢失，DB没有破坏，恢复时，搜索Log,确定Rollback的事务。2.3 分布式数据库系统中的故障分布式数据库系统中的故障2 2 分布式事务的执行与恢复分布式事务的执行与恢复 介质故障：辅助存储器介质遭破坏 处理方法：如数据丢失,日志无损失，从某个Dump状态开始执行已提交事务；数据与日志都丢失 不可能完全恢复以上三种可以统称为站点故障.2.3 分布式数据库系统中的故障分布式数据库系统

21、中的故障2 2 分布式事务的执行与恢复分布式事务的执行与恢复通讯故障报文故障 报文错 报文失序 报文丢失 报文延迟网络分割故障（网络断连）通讯发生,既有某个报文Message从Site x 发往Site y,正常情况:(a)在某时间段Dmax 之内,x 站点收到y发回的应答信息(Ack)(b)y收到的Message是一个合适的次序(c)Message本身的信息是正确的 但是当某个Dmax之后,x还没收到y的Ack,则可能发生:(a)Message 或 Ack 信息丢失 (b)网络分割,即网络不通2.3 分布式数据库系统中的故障分布式数据库系统中的故障2 2 分布式事务的执行与恢复分布式事务的执

22、行与恢复 问题可以进一步分为:a)是否是所在Site故障,还是系统响应过慢，还是网络流量过大b)若是故障,是通讯故障,还是 y 站点故障?c)如果是报文故障，是报文丢失还是应答丢失 对上述故障,其恢复程序可以有不同级别:一级:仅处理Site故障二级:Site故障及Message故障三级:Site故障及Message故障,还包括网络分割2.3 分布式数据库系统中的故障分布式数据库系统中的故障2 2 分布式事务的执行与恢复分布式事务的执行与恢复 事务恢复 当发生故障时，保证事务原子性的措施称为事务故障恢复，简称事务恢复 主要依靠日志来实现 事务状态转移跟踪（操作）Begin_transaction

23、：标记事务开始执行 Read&write：表示事务对某个数据项进行读写 End_transaction：表示读写操作已完成，标记事务执行结束 Commit_transaction：表示事务已经成功结束，任何改变已不可更改 Rollback(abort)：表示事务没有成功结束，撤销事务对数据库所作的任何改变2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复ACTIVEPARTIALLYCOMMITTEDCOMMITEDFAILEDTERMI

24、NATED BEGIN TRANSACTION READ/WRITE END TRANSACTIONCOMMITABORTABORT 事务的提交点 当事务T所有的站点数据库存取操作都已成功执行；所有操作对数据库的影响都已记录在日志中。到达提交点 提交点后事务就成为已提交的事务，并假定其结果以永久记录在数据库中 事务在日志中写入提交记录commit,T 在系统发生故障时，需要扫描日志，检查日志中写入start_transaction,T,但没有写入commit,T的所有事务T 恢复时必须回滚这些事务以取消他们对数据库的影响 此外，还必须对日志中记录的已提交子事务的所有写操作进行恢复。2.4 事务

25、故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复 事务的提交点相关操作 日志文件保存到磁盘上 一般先将文件的相关块，从磁盘拷贝到主存的缓冲区，然后更新，再写回磁盘 缓冲区中会经常存在一个或多个日志文件块，写满后一次性写回磁盘 系统崩溃时，主存中的信息会丢失，这些信息无法利用 因此，事务到达提交点之前，未写到磁盘的日志必须写入，称为事务提交前强制写日志。2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复 日志 Log：记录所有对DB的操作 事务标识：每个事务给定一个具有惟一性的标识符 Log记录项:

26、start_transaction,T,write_item,T,x,旧值,新值 read_item,T,x commit,T abort,T 写动作：写Log比写数据优先 Log存储：一般存在盘上,还会定期备份到磁带上2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复Log举例举例Log Write Output A=950 B=2050 C=600 BB,BA BC注:BX 表示含有X的存储块.2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复数据访问数据访问xYABx1y1 缓冲区

27、缓冲块 A 缓冲块 Binput(A)output(B)read(X)write(Y)磁盘 T1工作区T2 工作区主存x22.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复 档案库档案库 一天要产生大量的Log Log划分为两部分 一部分是当前活动的联机部分，存储在磁盘上 另一部分是档案存储部分，存储在磁带上2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复日志缓冲区数据库缓冲区(易变数据库)局部恢复管理器数据库缓冲区管理器主存取出读/写读/写日志档案库DB档案库稳定日志稳定DB读/写读

28、/写2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复数据库、日志和档案库的存储模式数据库、日志和档案库的存储模式 检查点（Checkpoint）设置一个周期性（时间/容量）操作点a)Log Buffer内容写入Log数据集b)写检查点Log信息：当前活动事务表,每个事务最近一次Log记录在Log文件中的位置c)DB Buffer内容写入DBd)将本次检查点Log项在Log文件中的地址记入“重启动文件”2.4 事务故障恢复的基本概念事务故障恢复的基本概念2 2 分布式事务的执行与恢复分布式事务的执行与恢复 事务本身也会发生故障，也是主要通过

29、日志来实现恢复 恢复原则 孤立和逐步退出事务的原则 undo 事务已对DB的修改 (不影响其他事务的可排除性局部故障，如事务操作的删除、超时、违反完整性原则、资源、限制和死锁等)成功结束事务原则 Redo 已成功事务的操作 夭折事务原则 撤销全部事务,恢复到初态，两种做法：利用数据备份和Undo 2.5 事务故障的恢复事务故障的恢复2 2 分布式事务的执行与恢复分布式事务的执行与恢复 本地事务恢复 (与集中式恢复相同)从“重启动文件”读出最近Checkpoint的地址,并定出Checkpoint在Log文件中的位置 创建Redo表（初态为空）,Undo表(即Checkpoint相应内容中的活动

30、事务表)检查得出Undo事务（向前检索，遇到begin transaction的log记录，其对应的事务）与Redo事务（向前检索，遇到commit的log记录，其对应事务）反向检索Log,将Undo表中事务,按log记录的操作，做Undo，直到遇到对应的Begin Trans 正向检索Redo事务的Log记录,并执行之,直到对应的Commit记录2.5 事务故障的恢复事务故障的恢复2 2 分布式事务的执行与恢复分布式事务的执行与恢复重启动文件UNDOREDO活动事务表故障发生地址c0c1(1)(3)(5)(2)(4)日志数据集利用日志进行事务恢复的过程2.5 事务故障的恢复事务故障的恢复2

31、2 分布式事务的执行与恢复分布式事务的执行与恢复Checkpoints 举例 T1 可以忽略(因为有检查点，更新已经被写入磁盘)T2 和 T3 redo.T4 undoTcTfT1T2T3T4checkpointsystem failure2.5 事务故障的恢复事务故障的恢复2 2 分布式事务的执行与恢复分布式事务的执行与恢复分布式事务恢复参考模型RootAgentAgentAgentDTM-Agent站点1的LTMDTM-AgentDTM-Agent站点2的LTM站点n的LTM全局事务分布式事务管理器(DTM)局部事务 管理器 (LTM)2.5 事务故障的恢复事务故障的恢复2 2 分布式事务

32、的执行与恢复分布式事务的执行与恢复 分布式事务模型 底层：本地事务管理层，LTM之间不需要进行联系，执行上层DTM代理发来的原语，实现接口1 Local begin,local commit,local abort,local create 中间层：分布式事务管理层，一组互相交换报文的本地DTM组成，实现接口2 Begin transaction,commit,abort,create 顶层：全局事务层，由总代理和其他代理组成，只有它与中间层联系2.5 事务故障的恢复事务故障的恢复2 2 分布式事务的执行与恢复分布式事务的执行与恢复.Begin Transaction.Create Agent

33、1Send to Agent1.Local-begin.Send Create ReqWriteBegin-transactionin Local LogRoot AgentDTM-AgentLTMReceive.Local CreateLocal-begin.WriteBegin-transactionin Local LogLTMDTM-Agent Agent113245678分布式事务执行和恢复举例 基本思想 将本地原子性提交行为的效果扩展到分布式事务,保证了分布式事务提交的原子性,并在不损坏Log的情况下,实现快速故障恢复,提高DDB系统的可靠性.第一阶段：表决阶段 第二阶段：执行阶段

34、 两类代理 协调者(Coordinator)：提交和撤销事务的决定权，一般是总代理 参与者(Participants)：负责在本地数据库中执行写操作，并且向协调者提出提交和撤销子事务的意向3.1 基本思想和内容基本思想和内容3 3 两阶段提交协议两阶段提交协议3.1 基本思想和内容基本思想和内容3 3 两阶段提交协议两阶段提交协议协调者 参与者日志日志日志日志命令应答.参与者 参与者2PC中协调者和参与者的关系中协调者和参与者的关系 表决阶段 目的是形成一个共同的决定 首先，协调者给所有参与者发送“准备”消息，进入等待状态 其次，参与者收到“准备”消息后，检查是否能够提交本地事务 如能，给协调

35、者发送“建议提交”消息,进入就绪状态 如不能，给协调者发送“建议撤销”消息，可以单方面撤销 第三，协调者收到所有参与者的消息后，他就做出是否提交事务的决定，只要有一个参与者投了反对票，就决定撤销整个事务，发送“全局撤销”消息给所有参与者，进入撤销状态 否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，进入提交状态 执行阶段 实现表决阶段的决定，提交或者撤销3.1 基本思想和内容基本思想和内容3 3 两阶段提交协议两阶段提交协议初始写begin_commit到日志等待有要求撤消的？写commit到日志提交写end_of_transt到日志初始准备提交？写ready到日志就绪消息类型？写

36、abort到日志写commit到日志提交撤消撤消写abort到日志写abort到日志协调者参与者nonoabortcommit准备撤消提交全局撤消全局提交ACKACK两阶段提交协议的活动 2PC协议的重要特点 允许参与者单方面撤销事务 一旦参与者确定了提交或撤销协议，它就不能再更改它的提议 当参与者处于就绪状态时，根据协调者发出的消息种类，它可以转换为提交状态或者撤销状态 协调者根据全局提交规则做出全局终止决定 协调者和参与者可能进入互相等待对方消息的状态，使用定时器，保证退出消息等待状态3.1 基本思想和内容基本思想和内容3 3 两阶段提交协议两阶段提交协议 集中式 通讯只发生在协调者和参与

37、者之间，参与者之间不交换信息 分层式 协调者是在树根的DTM代理者，协调者与参与者之间的通讯不用直接广播的方法进行，而是使报文在树中上下传播。每个DTM代理是通信树的一个内部节点，它从下层节点处收集报文或向它们广播报文。线性 参与者之间可以互相通信。系统中的站点间要排序，消息串行传递。支持没有广播功能的网络 分布式 允许所有参与者在第一阶段相互通信，从而可以独立做出事务终止决定。3.2 通信结构通信结构3 3 两阶段提交协议两阶段提交协议23451234511协调者参与者协调者协调者参与者第一阶段第二阶段准备建议撤消/提交全局撤消/提交提交/撤消集中式集中式34251511协调者参 与 者协调

38、者协调者参 与 者第一阶段第二阶段准备建议撤消/提交全局撤消/提交提交/撤消23422分层式分层式1234n第一阶段第二阶段准备建议提交/撤消建议提交/撤消建议提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消线性式线性式1n4324321n协调者协调者协调者+参与者第一阶段准备建议撤消/提交全局撤消/提交可独立做决定分布式分布式1.站点故障a 参与者在将“Ready”记录入Log之前故障此时协调者(C)达到超时，Abort发生。站点（P）恢复时，重启动程序将执行Abort，不必从其他站点获取信息。b 当将“Ready”写入Log后，站点故障此时所有运行的站点都将正常结束事务（

39、Commit/Abort)。P恢复时，因为P已Ready，所以不可判定C的最终决定。因此恢复时，重启动程序要询问C或其他站点。c 当C将“Prepare”写入Log，但“G-commit”/”G-abort”还没有写入前故障所有回答“Ready”的P等待C恢复。C重启动时，将重开提交协议，重发“Prepare”，于是P要识别重发。d C在将“G-commit”/”G-abort”写入Log后，“Complete”没有写入前故障收到命令的P正常执行，C重启动程序必须再次向所有P重发命令。以前没有收到命令的P也必须等待C恢复，P要识别两次命令。e“Complete”写入Log后故障无任何动作发生3

40、.2 两阶段提交协议两阶段提交协议和故障恢复和故障恢复3 3 两阶段提交协议两阶段提交协议2.报文丢失a 从P发出的“Ready”/“Abort”报文丢失 C达到超时，整个事务执行“G-abort”。该故障仅能被C识别，此时C认为P故障，但P并无故障，不需执行重启动程序。b “Prepare”报文丢失 P等待，C得不到回答，结果同2.ac “G-commit”/”G-abort”报文丢失 P处于不确定状态。回答“Abort”的可以确定其工作，回答“Ready”的不行。此时可以修改加入计时器，超时则申请重发命令。d “Ack”报文丢失 C超时，可重发“G-commit”/”G-abort”命令，

41、P无论是否有活动，都重发“Ack”报文3.2 两阶段提交协议两阶段提交协议和故障恢复和故障恢复3 3 两阶段提交协议两阶段提交协议3.网络分割站点假设分成两组：协调者组和参与者组。一组是协调者，一组是参与者。于是从协调者看是参与者组故障，结果同1.a,1.b。从参与者组看是协调者站点故障，动作如1.c,1.d。3.2 两阶段提交协议两阶段提交协议和故障恢复和故障恢复3 3 两阶段提交协议两阶段提交协议初始写begin_commit到日志等待有要求撤消的？写commit到日志提交写Complete到日志初始准备提交？写ready到日志就绪消息类型？写abort到日志写commit到日志提交撤消撤

42、消写abort到日志写abort到日志协调者参与者nonoabortcommit 2.b 准备2.a撤消2.a 提交2.c全局撤消全局提交ACKACK1.c1.d1.e1.a1.b2.d 多站点数据更新 方法：站点A上有事务T对X更新,X在B1,Bn和C1,Cm上有副本,则也要对这些副本更新 问题 多个站点同时更新不现实(每一个站点某一时刻与站点A连通的概率小于1）对未连通站点上的副本更新增多时出错,更新的顺序也不一定是连通顺序4.1 多站点数据更新多站点数据更新4 4 分布式数据库中的数据更新分布式数据库中的数据更新4.1 多站点数据更新多站点数据更新4 4 分布式数据库中的数据更新分布式数

43、据库中的数据更新站点A要更新X站点B1站点B2站点Bn站点C1站点C2站点Cm说明：(1)X在B1,B2,Bn 和C1,C2,Cm上 都有副本；(2)但只有站点 B1,B2,Bn 与站点A连通而站点 C1,C2,Cm 与站 点A暂时未连通。主文本更新 思想：指定主副本,修改只对主副本进行,修改辅助副本时,也按在主副本上执行的更新顺序执行 问题 修改传播必须在短时间内完成,否则将获得“过时”数据 主副本不可用,引得其他副本也不可用4.2 主文本更新主文本更新4 4 分布式数据库中的数据更新分布式数据库中的数据更新4.2 主文本更新主文本更新4 4 分布式数据库中的数据更新分布式数据库中的数据更新

44、网络网络站点AX主文本站点B2X辅文本站点B1X辅文本站点B3X辅文本站点B5X辅文本站点B4X辅文本T1T2未未连连通通T1在在T2之前之前 移动主文本法 若初次更新在辅文本上进行，然后再把更新引向该数据的主站点 如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新 待原主文本站点连通后，系统将自动把它改为辅文本，并按记录要求执行更新 如果初次更新在主文本上进行，但主文本站点与网络未接通，则此次更新操作失败，事务被撤销，因为无法传播更新 移动文本法的问题 网络分割成很多部分时，更新处理会不一致 网络分割成W1,W2，W1中X更新为R,W2中X更新为S,网络连通时，使用

45、R还是S来恢复X呢？4.2 主文本更新主文本更新4 4 分布式数据库中的数据更新分布式数据库中的数据更新 快照(Snapshot)与视图相似,是导出的关系 快照的数据是实际存放在数据库中的，视图不是 周期地更新 用于某些需要“冻结”数据的应用 4.3 快照方法快照方法4 4 分布式数据库中的数据更新分布式数据库中的数据更新 例子 Define Snapshot HP-Book as SELECT *FROM Book WHERE Price$100 REFRESH Every day 特点 快照不考虑数据的辅助副本,只关心主文本和这个主本上定义的多个快照 快照与视图一样可以定义为一个或多个主副

46、本的部分或全部 快照可以完成复杂的查询,但又不阻止更新 查询操作可使用快照，也可使用主文本，对更新操作还是在主文本上进行4.3 快照方法快照方法4 4 分布式数据库中的数据更新分布式数据库中的数据更新 业务规则约束 有效性约束:域约束，数据项的取值范围 数据依赖约束:实体完整性和引用完整性 例子 取现金时 一个账户的存款余额必须大于零 转账时 一个账户的存款余额必须大于零.事务结束时,两账户中存款总和,必须与事务开始时两账户存款之和相同 定期利息计算 事务执行后,所有账户存款之和比事务开始前各账户存款总和大于10%（假定利息是总额的10%）5.1 业务规则的一致性业务规则的一致性5 5 分布式

47、事务增强数据库一致性分布式事务增强数据库一致性 业务规则要强制执行 用户编写的事务中 由DBMS事务优化器产生的事务中 在产生的分布式执行方案中，要编入业务规则的强制条件 或者从数据字典中获取相关的业务规则，并在生产分布式事务的时候使用它 多数商用分布式DBMS的事务优化器，只加入少数几类业务规则，为了补救这种不足，需要 程序员必须编写加进业务规则的分布式事务 必须定期对数据库进行扫描，监测不一致的数据，并予以清除 找出那些没有实施的，不能由事务优化器加上的强行业务规则5.1 业务规则的一致性业务规则的一致性5 5 分布式事务增强数据库一致性分布式事务增强数据库一致性5.2 冗余数据的一致性冗

48、余数据的一致性5 5 分布式事务增强数据库一致性分布式事务增强数据库一致性 分布式数据库冗余设计的理由 提高系统的可用性和可靠性 如果用户由于某种原因无法访问某个成员数据库，它可以访问另外一个成员数据库上的相同片断 提高“读”事务的本地性 降低通信成本 例如，一个片断存放在该事务的原发站点中，那么就免除了传输请求和返回结果的花费 但是，如果事务包含对片断的更新，则其所有副本也必须做同样的更新，这时反而增加而不是降低通信成本 例子site1 site2T1:Read(x)x=x*1.1 write(x)T2:Read(x)x=x-20 write(x)设数据x在两个站点都有副本.两个事务分别执行

49、,这样两个事务的执行会产生不同的结果.设置x=50,T2T1的执行顺序得到 x=33 (x-20)*1.1=(50-20)*1.1 T1T2的执行顺序得到 x=35 (x*1.1)-20=50*1,1)数据库管理员要使得包含冗余的站点以相同的顺序执行事务，来保证数据的一致性5.2 冗余数据的一致性冗余数据的一致性5 5 分布式事务增强数据库一致性分布式事务增强数据库一致性 异步复制器 冗余数据绝对保持一致是不可能的,一般允许对冗余数据的修改有暂时的不一致.复制数据库的应用 向分站点发送只读数据 在一个周期结束时从分站点对中心站点复制这个周期内改变过的数据 复制数据并建立决策支持系统 建立关键数

50、据的备份副本5.2 冗余数据的一致性冗余数据的一致性5 5 分布式事务增强数据库一致性分布式事务增强数据库一致性 不同复制器的差别 何时在主副本上获取数据 数据驱动:当事务修改主副本时,获取有关数据修改信息,并将其写到一个获取文件或队列中。计时器驱动:由系统在用户定义的时间间隔自动获取相关数据修改信息。Oracle Simple Snapshot属于这一类方法。应用程序驱动:由应用中的事件引发系统从主副本把数据复制到获取文件或队列中。Prism Warehouse Manager采用这种方法。5.2 冗余数据的一致性冗余数据的一致性5 5 分布式事务增强数据库一致性分布式事务增强数据库一致性