分布式数据库系统及其应用

第4章 分布式数据库中的事务管理和恢复 分布式事务概述 分布式事务的执行和恢复 两阶段提交协议 分布式数据库中的数据更新 分布式事务增强数据库一致性 总结

事务是访问或更新各种数据项的最小逻辑工作单位。 它是一个操作序列 它可以使数据库从一个一致状态到另外一个一致状态 事务必须保证数据库的一致性 1.1 分布式事务定义和特性 1 分布式事务概述 事务概念 事务是访问或更新各种数据项的最小逻辑工作单位。 它是一个操作序列 它可以使数据库从一个一致状态到另外一个一致状态 事务必须保证数据库的一致性 事务执行期间数据库可能不一致

当事务提交（commit）时数据库必须是一致的 1.1 分布式事务定义和特性 1 分布式事务概述 事务概念 当事务提交（commit）时数据库必须是一致的 数据库可能临时不一致 数据库一致 数据库一致 事务T结束 事务T开始 事务T的执行

分布式事务 集中式 分布式 1 分布式事务概述 1.1 分布式事务定义和特性 事务和操作数据在一个站点上 不存在传输费用 操作数据分布在不同的站点上 事务也在多个站点上执行 分布式事务是集中式事务的扩充 站点和通信链路故障都可能导致错误发生 分布式事务的恢复要比集中式事务复杂的多

事务分类: 全局事务 局部事务 1 分布式事务概述 1.1 分布式事务定义和特性 分布式数据库中的事务 通常由一个主事务和在不同站点上执行的子事务组成 主事务：负责事务的开始、提交和异常终止 子事务：完成对相应站点上的数据库的访问操作 局部事务 仅访问或更新一个站点上的数据的事务

ACID特性 1 分布式事务概述 1.1 分布式事务定义和特性 分布式事务特性 原子性（Atomicity） 事务的操作要么全部执行，要么全部不执行，保证数据库一致性状态。 一致性（Consistency） 事务的正确性，串行性，并发执行的多个事务，其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同。 持久性（Durability） 当事务提交后，其操作的结果将永久化，而与提交后发生的故障无关。

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

从账号A向账号B转账 $50: 2. A := A – 50 3. write(A) 4. read(B) 5. B := B + 50 1.1 分布式事务定义和特性 1 分布式事务概述 分布式事务特性举例 从账号A向账号B转账 $50: 1. read(A) 2. A := A – 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B)

一致性要求: 事务执行后A 和 B账号的总金额不变 1.1 分布式事务定义和特性 1 分布式事务概述 分布式事务特性举例 一致性要求: 事务执行后A 和 B账号的总金额不变 原子性要求: 如果事物在第3步和第6步之间故障，系统应该保证事务对数据库的修改没有产生，否则将导致不一致性。

持久性要求: 一旦用户通知说事务已经完成（即$50 转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此。 1.1 分布式事务定义和特性 1 分布式事务概述 分布式事务特性举例 持久性要求: 一旦用户通知说事务已经完成（即$50 转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此。

独立性要求 如果在第 3步和第6步之间，允许其他事务访问被修改的数据库的中间结果，那么它将见到一个不一致的数据库 1.1 分布式事务定义和特性 1 分布式事务概述 分布式事务特性举例 独立性要求 如果在第 3步和第6步之间，允许其他事务访问被修改的数据库的中间结果，那么它将见到一个不一致的数据库 (也就是说， A + B 的和少于它的正确值） 当然事务的串行执行将不会出现这种情况，但是数据库中事务并行执行的优点就损失了

Begin Transaction原语：开始一个事务 T1[] T2[] : 子事务或操作序列 : Tn[] 1.2 分布式事务结构和事务状态 1 分布式事务概述 分布式事务的一般结构 Begin Transaction原语：开始一个事务 T1[] T2[] : 子事务或操作序列 : Tn[] Commit原语：事务成功完成的结束 Rollback或Abort原语：事务失败的结束

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

1.2 分布式事务结构和事务状态 1 分布式事务概述 分布式事务的状态

进程：系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成的 过程：不可并行执行的操作序列 1.2 分布式事务结构和事务状态 1 分布式事务概述 进程相关定义 进程：系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成的 过程：不可并行执行的操作序列 事务代理（Agent）：应用在各个Site上执行的若干进程，称作应用在该Site上的代理。代理可以执行应用程序员写的程序，也可以执行系统的原语函数，不同代理间通过报文实现通讯 根代理（Root Agent） 应用启动Site上的代理。根代理所在的Site称作原发Site。一般，根代理负责发系统原语，只有根代理可以请求创建新代理。

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

事务在两个账户之间执行“基金汇兑”操作。 如果汇兑的金额小于转出帐号现有金额，就撤销 如果大于等于就提交 全局关系 1.2 分布式事务结构和事务状态 1 分布式事务概述 转账应用 事务在两个账户之间执行“基金汇兑”操作。 如果汇兑的金额小于转出帐号现有金额，就撤销 如果大于等于就提交 全局关系 Account (Account-number, Amount) 假设账户分布在网络的不同站点上。

全局级转帐事务 FUND_TRANSFER: read (terminal,$AMOUNT,$FROM_ACC,$TO_ACC); begin_transaction; select AMOUNT into $FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC; if $FROM_AMOUNT-$AMOUNT<0 then abort else begin update ACCOUNT set AMOUNT = AMOUNT-$AMOUNT where ACCOUNT_NUMBER = $FROM_ACC; set AMOUNT = AMOUNT+$AMOUNT where ACCOUNT_NUMBER = $TO_ACC; commit end

转账应用处理流程 ROOT_AGENT AGENT 输入：汇出金额和转入/转出帐号 接收来自根代理的信息 事务开始：检查转出帐号中是否 有足够的转出资金？ 更新转入帐号存款余额 否 更新转出帐号存款余额 创建AGENT1 向代理1送消息：转入帐号，金额 发送执行消息给根代理 (成功或失败) 等待来自AGENT1的消息 是 否 转账应用处理流程 成功？ 提交事务：成功结束 撤消事务：失败结束

ROOT_AGENT; 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-$AMOUNT<0 then abort else begin update ACCOUNT set AMOUNT = AMOUNT-$AMOUNT where ACCOUNT_NUMBER = $FROM_ACC; create AGENT; send to AGENT($AMOUNT,$TO_ACC); commit/*这里省略了等待消息和判别*/ end AGENT; receive from ROOT_AGENT($AMOUNT,$TO_ACC); update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT=$TO_ACC; send to ROOT_AGENT(‘SUCCESS’/’FALL’)

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

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

抽象模型 2 分布式事务的执行与恢复 2.1 分布式事务管理的抽象模型 站点 1 本地事务管理器 LTM1 分布式事务管理器 DTM1 LTM: Local Transaction Manager DTM: Distributed Transaction Manager 抽象模型 站点 1 本地事务管理器 LTM1 分布式事务管理器 DTM1 站点 2 本地事务管理器 LTM2 分布式事务管理器 DTM2 站点 n 本地事务管理器 LTMn 分布式事务管理器 DTMn

事务管理 2 分布式事务的执行与恢复 2.1 分布式事务管理的抽象模型 DTM功能 保证分布式事务ACID特性， Log原语： Local Begin-Trans, Local-Commit, Local-Abort 事务管理 DTM功能 保证分布式事务ACID特性， 特别是原子性，使每一站点的子事务都成功执行，或者都不执行。 通过向各站点发begin-transaction,commit或者abort,create原语来实现的 负责协调由该站点发出的所有分布式事务的执行 启动分布式事务的执行 将分布式事务分解为子事务，并将其分派到恰当的站点上执行 决定分布式事务的终止（子事务都提交或者都撤销） 支持分布式事务执行位置透明性 实现了对网络上各站点的各子事务的监督和管理 完成对整个分布式事务执行过程的调度和管理 保证分布式数据库系统的高效率

维护一个用于恢复的日志，代替DTM把分布事务的执行与恢复信息记入日志 2.1 分布式事务管理的抽象模型 2 分布式事务的执行与恢复 Log原语： Local Begin-Trans, Local-Commit, Local-Abort 事务管理 LTM功能 保证本地事务的ACID特性 维护一个用于恢复的日志，代替DTM把分布事务的执行与恢复信息记入日志 参与适当的并发控制模式，以协调在该站点上执行的事务的并发执行。接收并遵从本Site上DTM发来的Log原语，记入Log并执行之

是指协调分布式事务中各成员DBMS执行其子事务的通用方法，有三种: 2.2 分布式事务执行的控制模型 2 分布式事务的执行与恢复 分布式事务执行的控制模型 是指协调分布式事务中各成员DBMS执行其子事务的通用方法，有三种: 主从模型：主、从控制器，LTM之间无通信 三角模型：LTM之间可以传递数据，避免了主从之间不必要的传输 层次控制模型：LTM还可再创建Agent，控制其它LTM执行，比前两种复杂

主从控制模型 分布式事务 管理器 命令 命令 命令 回答 回答 回答 局部事务 管理器 局部事务 管理器 局部事务 管理器 数据库 数据库

分布式事务 管理器 命令 命令 回答 回答 临时数据 局部事务 管理器 局部事务 管理器 数据库 数据库 三角控制模型

分布式事务 管理器 局部事务 数据库 命令 回答 …… … 层次控制模型

故障类型 事务故障 系统故障 2 分布式事务的执行与恢复 2.3 分布式数据库系统中的故障 由非预期的、不正常的程序结束所造成的故障，即事务没有执行到Commit或显示Rollback语句的故障，如：计算溢出、完整性破坏、操作员干预、输入输出错误、死循环等） 处理方法：内存、磁盘上信息没有损失，使用Log做Rollback 系统故障 造成系统停止运行的任何事件，要求系统重启动，如CPU出错、缓冲区满、系统崩溃等 处理方法：内存、I/O Buffer内容皆丢失，DB没有破坏，恢复时，搜索Log，确定Rollback的事务。

介质故障： 以上三种可以统称为站点故障. 2 分布式事务的执行与恢复 2.3 分布式数据库系统中的故障 辅助存储器介质遭破坏 处理方法：如数据丢失, 日志无损失，从某个Dump状态开始执行已提交事务；数据与日志都丢失 不可能完全恢复 以上三种可以统称为站点故障.

但是当某个Dmax之后, x还没收到y的Ack, 则可能发生: (a) Message 或 Ack 信息丢失 2.3 分布式数据库系统中的故障 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 分布式事务的执行与恢复 2.3 分布式数据库系统中的故障 a) 是否是所在Site故障, 还是系统响应过慢，还是网络流量过大 b) 若是故障, 是通讯故障, 还是 y 站点故障? c) 如果是报文故障，是报文丢失还是应答丢失 对上述故障, 其恢复程序可以有不同级别: 一级: 仅处理Site故障 二级: Site故障及Message故障 三级: Site故障及Message故障, 还包括网络分割

事务恢复 事务状态转移跟踪（操作） 2 分布式事务的执行与恢复 2.4 事务故障恢复的基本概念 当发生故障时，保证事务原子性的措施称为事务故障恢复，简称事务恢复 主要依靠日志来实现 事务状态转移跟踪（操作） Begin_transaction：标记事务开始执行 Read & write：表示事务对某个数据项进行读写 End_transaction：表示读写操作已完成，标记事务执行结束 Commit_transaction：表示事务已经成功结束，任何改变已不可更改 Rollback (abort)：表示事务没有成功结束，撤销事务对数据库所作的任何改变

2 分布式事务的执行与恢复 2.4 事务故障恢复的基本概念 PARTIALLY COMMITTED ACTVE COMMITED FAILED TERMINATED BEGIN TRANSACTION READ/ WRITE END TRANSACTION COMMIT ABORT

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

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

日志 Log：记录所有对DB的操作 事务标识：每个事务给定一个惟一性的标识符 Log记录项 : 写动作：写Log比写数据优先 2.4 事务故障恢复的基本概念 2 分布式事务的执行与恢复 日志 Log：记录所有对DB的操作 事务标识：每个事务给定一个惟一性的标识符 Log记录项 : [start_transaction, T], [write_item, T, x, 旧值, 新值] [read_item, T, x] [commit, T] [abort, T] 写动作：写Log比写数据优先 Log存储：一般磁盘，还会定期备份到磁带上

Log举例 2 分布式事务的执行与恢复 2.4 事务故障恢复的基本概念 Log Write Output <start,T0> <write,T0, A, 1000, 950> <write,T0, B, 2000, 2050> A = 950 B = 2050 <commit,T0 > <start,T1 > <write,T1, C, 700, 600> C = 600 BB, BA <commit, T1 > BC 注: BX 表示含有X的存储块.

数据访问 2 分布式事务的执行与恢复 2.4 事务故障恢复的基本概念 x Y A B x1 y1 缓冲区 缓冲块 A 缓冲块 B input(A) output(B) read(X) write(Y) 磁盘 T1工作区 T2 工作区 主存 x2

档案库 一天要产生大量的Log Log划分为两部分 2 分布式事务的执行与恢复 2.4 事务故障恢复的基本概念 一部分是当前活动的联机部分，存储在磁盘上 另一部分是档案存储部分，存储在磁带上

2 分布式事务的执行与恢复 2.4 事务故障恢复的基本概念 日志 缓冲区 主存 日志 档案库 稳定 日志 局部恢复 管理器 …… 读/写 fetch/ flush 读/写 稳定 DB 数据库 缓冲区 (易变数据库) 读/写 数据库缓冲区 管理器 读/写 DB 档案库 数据库、日志和档案库的存储模式

检查点（Checkpoint） 设置一个周期性（时间/容量）操作点 a) Log Buffer内容写入Log数据集 2.4 事务故障恢复的基本概念 2 分布式事务的执行与恢复 检查点（Checkpoint） 设置一个周期性（时间/容量）操作点 a) Log Buffer内容写入Log数据集 b) 写检查点Log信息：当前活动事务表, 每个事务最近一次Log记录在Log文件中的位置 c) DB Buffer内容写入DB d) 将本次检查点Log项在Log文件中的地址记入“重启动文件”

事务本身也会发生故障，也是主要通过日志来实现恢复 恢复原则 2.5 事务故障的恢复 2 分布式事务的执行与恢复 事务本身也会发生故障，也是主要通过日志来实现恢复 恢复原则 孤立和逐步退出事务的原则 undo 事务已对DB的修改 ( 不影响其他事务的可排除性局部故障，如事务操作的删除、超时、违反完整性原则、资源、限制和死锁等) 成功结束事务原则 Redo 已成功事务的操作 夭折事务原则 撤销全部事务, 恢复到初态，两种做法：利用数据备份和Undo

本地事务恢复 (与集中式恢复相同) 2 分布式事务的执行与恢复 2.5 事务故障的恢复 本地事务恢复 (与集中式恢复相同) 从“重启动文件” 读出最近Checkpoint的地址, 并定出Checkpoint在Log文件中的位置 创建Redo表（初态为空）, Undo表(即Checkpoint相应内容中的活动事务表) 检查得出Undo事务（向前检索，遇到begin transaction的log记录，其对应的事务）与Redo事务（向前检索，遇到commit的log记录，其对应事务） 反向检索Log, 将Undo表中事务, 直到遇到对应的Begin Trans 正向检索Redo事务的Log记录, 并执行之, 直到对应的Commit记录

2 分布式事务的执行与恢复 2.5 事务故障的恢复 利用日志进行事务恢复的过程 (3) 故障 发生 c0 c1 活动事务表 (5) (2) 日志数据集 (5) (2) (4) UNDO REDO 重启动文件 地址 (1) 利用日志进行事务恢复的过程

T1 可以忽略 (因为有检查点，更新已经被写入磁盘) T2 和 T3 redo. T4 undo 2.5 事务故障的恢复 2 分布式事务的执行与恢复 Checkpoints 举例 Tc Tf T1 T2 T3 T4 checkpoint system failure T1 可以忽略 (因为有检查点，更新已经被写入磁盘) T2 和 T3 redo. T4 undo

分布式事务恢复参考模型 2.5 事务故障的恢复 2 分布式事务的执行与恢复 Root Agent Agent Agent 全局事务 分布式事务管理器(DTM) DTM- Agent DTM- Agent DTM- Agent 局部事务 管理器 (LTM) 站点1的 LTM 站点2的 LTM 站点n的 LTM 分布式事务恢复参考模型

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

分布式事务执行和恢复举例 8 1 3 6 4 5 7 2 Root Agent Agent1 DTM-Agent DTM-Agent LTM . Begin Transaction Create Agent1 Send to Agent1 Receive... 8 1 3 DTM-Agent 6 DTM-Agent Local Create Local-begin . Local-begin Send Create Req 4 5 7 LTM LTM 2 Write Begin -transaction in Local Log …………. Write Begin -transaction in Local Log

基本思想 两类代理 3 两阶段提交协议 3.1 基本思想和内容 将本地原子性提交行为的效果扩展到分布式事务, 保证了分布式事务提交的原子性, 并在不损坏Log的情况下, 实现快速故障恢复, 提高DDB系统的可靠性. 第一阶段：表决阶段 第二阶段：执行阶段 两类代理 协调者(Coordinator)：提交和撤销事务的决定权，一般是总代理 参与者(Participants)：负责在本地数据库中执行写操作，并且向协调者提出提交和撤销子事务的意向

3.1 基本思想和内容 3 两阶段提交协议 协调者 参与者 日志 命令 应答 ... ... 2PC中协调者和参与者的关系

3 两阶段提交协议 3.1 基本思想和内容 表决阶段 执行阶段 目的是形成一个共同的决定 首先，协调者给所有参与者发送“准备”消息，进入等待状态 其次，参与者收到“准备”消息后，检查是否能够提交本地事务 如能，给协调者发送“建议提交”消息,进入就绪状态 如不能，给协调者发送“建议撤销”消息，可以单方面撤销 第三，协调者收到所有参与者的消息后，他就做出是否提交事务的决定， 只要有一个参与者投了反对票，就决定撤销整个事务，发送“全局撤销”消息给所有参与者，进入撤销状态 否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，进入提交状态 执行阶段 实现表决阶段的决定，提交或者撤销

两阶段提交协议的活动 协调者 参与者 初始 初始 准备 no 准备提交？ 写abort到日志 写begin_commit到日志 撤消 提交 等待 写ready到日志 全局撤消 有要求撤消的？ 写abort到日志 就绪 no 全局提交 消息类型？ 写commit到日志 abort commit 写abort到日志 写commit到日志 ACK 提交 撤消 撤消 提交 写end_of_transt到日志 ACK

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

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

集中式 协调者 参与者 协调者 参与者 协调者 2 2 3 3 1 1 1 4 4 5 5 准备 建议撤消/提交 全局撤消/提交 提交/撤消 第一阶段 第二阶段

分层式 协调者 参 与 者 协调者 参 与 者 协调者 3 3 2 2 2 2 1 4 1 4 1 5 5 准备 建议撤消/提交 参 与 者 协调者 参 与 者 协调者 3 3 2 2 2 2 1 4 1 4 1 5 5 准备 建议撤消/提交 全局撤消/提交 提交/撤消 第一阶段 第二阶段

线性式 第一阶段 准备 建议提交/撤消 建议提交/撤消 建议提交/撤消 1 2 3 4 n 全局提交/撤消 全局提交/撤消 全局提交/撤消 第二阶段

分布式 协调者 协调者 协调者+参与者 1 2 2 1 3 3 4 4 … … n n 全局撤消/提交 可独立做决定 准备 建议撤消/提交 第一阶段

3 两阶段提交协议 3.2 两阶段提交协议和故障恢复 站点故障 a> 参与者在将“Ready”记录入Log之前故障 此时协调者(C)达到超时，Abort发生。站点（P）恢复时，重启动程序将执行Abort，不必从其他站点获取信息。 b> 当将“Ready”写入Log后，站点故障 此时所有运行的站点都将正常结束事务（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后故障 无任何动作发生

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

网络分割 3 两阶段提交协议 3.2 两阶段提交协议和故障恢复 站点假设分成两组：协调者组和参与者组。 一组是协调者，一组是参与者。于是从协调者看是参与者组故障，结果同1.a>, 1.b>。 从参与者组看是协调者站点故障，动作如1.c>, 1.d>。

协调者 参与者 1.a> 1.b> 1.c> 1.d> 1.e> 初始 初始 2. b> 准备 no 准备提交？ 写abort到日志 写begin_commit到日志 2.a>撤消 1.b> 1.c> 2.a> 提交 等待 写ready到日志 2.c>全局撤消 有要求撤消的？ 写abort到日志 就绪 no 1.d> 全局提交 消息类型？ 写commit到日志 abort commit 写abort到日志 写commit到日志 ACK 提交 撤消 撤消 提交 1.e> 写Complete到日志 ACK 2.d>

多站点数据更新 方法 ：站点A上有事务T对X更新, X在B1,…Bn和C1,…Cm上有副本, 则也要对这些副本更新 问题 4.1 多站点数据更新 4 分布式数据库中的数据更新 多站点数据更新 方法 ：站点A上有事务T对X更新, X在B1,…Bn和C1,…Cm上有副本, 则也要对这些副本更新 问题 多个站点同时更新不现实(每一个站点某一时刻与站点A连通的概率小于1） 对未连通站点上的副本更新增多时出错, 更新的顺序也不一定是连通顺序

4 分布式数据库中的数据更新 4.1 多站点数据更新 站点A 要更新X 站点B1 站点B2 站点Bn 站点C1 站点C2 站点Cm 说明： 都有副本； (2)但只有站点 B1,B2,…,Bn 与站点A连通而站点 C1,C2,…,Cm 与站 点A暂时未连通。

主文本更新 思想：指定主副本, 修改只对主副本进行, 修改辅助副本时, 也按在主副本上执行的更新顺序执行 问题 4 分布式数据库中的数据更新 4.2 主文本更新 4 分布式数据库中的数据更新 主文本更新 思想：指定主副本, 修改只对主副本进行, 修改辅助副本时, 也按在主副本上执行的更新顺序执行 问题 修改传播必须在短时间内完成, 否则将获得“过时”数据 主副本不可用, 引得其他副本也不可用

4 分布式数据库中的数据更新 4.2 主文本更新 网络 T1 T1在T2之前 站点A 站点B1 T2 站点B5 站点B2 未连通 站点B4 X主 文本 站点B2 X辅 站点B1 站点B3 站点B5 站点B4 T1 T2 T1在T2之前 未连通

移动主文本法 移动文本法的问题 4 分布式数据库中的数据更新 4.2 主文本更新 若初次更新在辅文本上进行，然后再把更新引向该数据的主站点 如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新 待原主文本站点连通后，系统将自动把它改为辅文本，并按记录要求执行更新 如果初次更新在主文本上进行，但主文本站点与网络未接通，则此次更新操作失败，事务被撤销，因为无法传播更新 移动文本法的问题 网络分割成很多部分时，更新处理会不一致 网络分割成W1,W2，W1中X更新为R, W2中X更新为S,网络连通时，使用R还是S来恢复X呢？

快照(Snapshot) 4 分布式数据库中的数据更新 4.3 快照方法 与视图相似, 是导出的关系 快照的数据是实际存放在数据库中的，视图不是 周期地更新 用于某些需要“冻结”数据的应用

例子 特点 4 分布式数据库中的数据更新 4.3 快照方法 快照不考虑数据的辅助副本, 只关心主文本和这个主本上定义的多个快照 Define Snapshot HP-Book as SELECT * FROM Book WHERE Price>$100 REFRESH Every day 特点 快照不考虑数据的辅助副本, 只关心主文本和这个主本上定义的多个快照 快照与视图一样可以定义为一个或多个主副本的部分或全部 快照可以完成复杂的查询, 但又不阻止更新 查询操作可使用快照，也可使用主文本，对更新操作还是在主文本上进行

业务规则约束 例子 5 分布式事务增强数据库一致性 5.1 业务规则的一致性 有效性约束: 域约束，数据项的取值范围 数据依赖约束: 实体完整性和引用完整性 例子 取现金时 一个账户的存款余额必须大于零 转账时 一个账户的存款余额必须大于零. 事务结束时,两账户中存款总和, 必须与事务开始时两账户存款之和相同 定期利息计算 事务执行后, 所有账户存款之和比事务开始前各账户存款总和大于10%（假定利息是总额的10%）

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

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

例子 5.2 冗余数据的一致性 5 分布式事务增强数据库一致性 site1 site2 T2: Read(x) x=x-20 write (x) T1: Read(x) x=x*1.1 write(x) 设数据x在两个站点都有副本. 两个事务分别执行, 这样两个事务的执行会产生不同的结果. 设置x=50, T2T1的执行顺序得到 x=33 (x-20)*1.1=(50-20)*1.1 T1T2的执行顺序得到 x=35 (x*1.1)-20=50*1,1) 数据库管理员要使得包含冗余的站点以相同的顺序执行事务，来保证数据的一致性

异步复制器 5 分布式事务增强数据库一致性 5.2 冗余数据的一致性 冗余数据绝对保持一致是不可能的, 一般允许对冗余数据的修改有暂时的不一致. 复制数据库的应用 向分站点发送只读数据 在一个周期结束时从分站点对中心站点复制这个周期内改变过的数据 复制数据并建立决策支持系统 建立关键数据的备份副本

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

不同复制器的差别 何时把主副本上的数据用到辅助副本上 5 分布式事务增强数据库一致性 5.2 冗余数据的一致性 数据驱动: 在主副本上由更新Trans所做的更新, 立即复制, 传输和应用于辅助副本。HP的Allbase/Replicate,Open Ingres Replicator和Sybase Replication Server采用这种方法 计时驱动: 更新事务在主副本上的更新, 在用户定义的区间应用于辅助副本.IBM的Data Propagator/Replicational, Oracle Simple Snapshot属于这一类方法 应用程序驱动: 由应用中的事件引发系统获取文件或队列对辅助副本进行修改。Prism Warehouse Manager采用这种方法

分布式事务概述（定义、特性和结构等） 分布式事务的执行与恢复 事务管理抽象模型 事务恢复 2PC协议 分布式数据库中的数据更新 总 结 分布式事务概述（定义、特性和结构等） 分布式事务的执行与恢复 事务管理抽象模型 事务恢复 2PC协议 分布式数据库中的数据更新 分布式事务增强数据库一致性