分布式事务管理(数据库)

时间：2022-12-20 10:30:02 | 来源：信息时代

时间：2022-12-20 10:30:02 来源：信息时代

    分布式事务管理 : 在分布式环境下采用进程模型和服务器模型及有关协议实现对分布式事务的有效管理。分布式事务管理的目标就是追求高效、可靠和并发地执行事务。具体可描述为:维护分布式事务的ACID性质;提高系统的性能,包括CPU、内存等的系统资源的使用效率和数据资源的使用效率,减少控制报文传送的次数,加速事务的响应速度,降低系统运行开销; 提高系统可靠性和可用性,当系统的一部分或者局部发生故障时,系统仍能正常运转,而不是整个系统瘫痪。
1. 分布式事务
在分布式数据库系统中,任何一个应用的请求最终将转化成对数据库的存取操作序列,将该操作序列定义为一个或几个事务。因此,分布式事务是指分布式数据库应用中的事务。一个分布式事务是一个应用中不可分割的操作序列,是用户对数据库存取操作序列执行的最小单位,也遵循ACID四个特性。由于分布式系统的特性,一个分布式事务在执行时将被分解为若干和各场地上的计算机相关的操作序列,称之为子事务。子事务也可定义为: 一个分布式子事务是在某个场地上操作的集合。分布式事务是典型的嵌套类型的事务。例如,实现两个账户间的转账操作的事务: 设有一账户关系ACCOUNT{Acc_No,Amount},其中,Acc_No、Amount分别为账号和金额。该关系用于存放账户的金额,要求实现: 完成从贷方账号(From_Acc)到借方账号(To_Acc)的转账操作,转账金额为transfer amount。
假设: 贷方账户和借方的账目分别存在不同场地上,则分布执行程序说明如下:
(1)有两个进程:根代理(协调进程)ROOT和代理子进程(AGENT1)。
(2)贷款账目在根代理所在的场地上,借款账目存在另一场地上。
(3)根代理进程完成贷款处理。
(4)借款处理时,由ROOT创建的代理子进程(AGENT1)将参数传给AGENT1,之后由AGENT1完成借款处理。
(5) ROOT负责全局事务的启动、提交或终止处理。AGENT1发生故障,ROOT将不产生任何效果,即贷款账目或借款账目均保持转账前的状态。
2.分布式事务实现模型
为完成各个场地的子事务,有两种实现模型:
(1)进程模型: 在相应的场地上创建子进程。即全局事务必须为每一子事务在相应的场地上创建一个代理者进程,也称局部进程或子进程。同时,为协调各子事务的操作,全局进程还要启动一个协调者进程,来控制和协调各代理者间的操作。
通常,发出分布式事务的场地称为事务的源场地。在源场地上,每个事务有一个根代理(也称协调者进程),负责创建、启动和协调其他进程。为完成事务的操作,在各场地上创建的进程,称为事务的代理进程,简称代理。进程模型如图1所示。子代理完成各场地上的子事务; 根代理负责创建、启动和协调其他进程,以完成全局事务的操作。
(2)服务器模型: 每个场地上创建有事务服务器进程,用于执行子事务。事务通过服务请求,申请服务器为其服务。服务器可交替地为多个事务服务。服务器模型如图2所示。

图2 服务器模型图

3.分布式事务提交协议
在一个分布式事务的执行过程中,全局事务将被分解为多个场地上的子事务执行。为完成各个场地的子事务,全局事务必须为每一子事务在相应的场地上创建一个代理者进程,也称局部进程或子进程。同时,为协调各子事务的操作,全局进程还要启动一个协调者进程,来控制和协调各代理者间的操作。协调者是在事务的各个代理中指定的一个特殊代理,负责决定所有子事务的提交或废弃。参与者是除协调者之外的其他代理,负责各个子事务的提交或废弃。
分布式事务的提交要求所有子事务均正确提交才能提交。为实现分布式事务的提交,普遍采用两段提交(two-phase-commitment,2PC)协议。除了基本的2PC协议外,还有分布式的2PC、层次的2PC和线性的2PC协议。针对2PC协议的阻塞特性,又提出了非阻塞的提交(3PC)协议。
(1)基本的两阶段提交(2PC)协议: 基本的2PC协议是为了实现分布式事务提交而采用的协议。其基本内容是,把全局事务的提交分为决定和执行两个阶段(见图3)。

图3 基本的2PC协议示意图

决定阶段: 协调者向各个参与者发prepare命令,然后等待回答; 若所有的参与者返回ready信息,则该事务满足提交条件。如果至少有一个事务返回abort消息,则该事务不能提交。
执行阶段: 在事务具备提交条件的情况下,协调者向各个参与者发commit命令,各个参与者执行提交。否则,协调者向各个参与者发出abort命令,各个参与者执行废弃,取消对数据库的修改。各参与者返回ack确认信息,通告协调者事务执行结束。基本的2PC协议也可用图3直观地显示。
(2)非阻塞分布式事务提交(3PC)协议: 事务的阻塞是指一个场地上可结束的事务(提交和废弃)的执行,只有等到允许该事务结束的消息到来后才能完成。例如,在分布式数据库事务处理的2PC协议中,一参与者在等待协调者的回答时,由于协调者场地出现故障而没有接收到消息,这时,参与者等待超时,重新向协调者发“准备提交”请求,要求协调者给予命令。该种情况下,事务处于阻塞状态,只有等到协调者场地恢复正常,事务提交过程才能正常执行。若协调者场地不能恢复正常,事务就一直处于挂起状态,并占用一定的系统资源。降低了事务的可用性。
3PC协议是在2PC协议基础上,增加了一个预提交阶段。在3PC协议中,第二阶段为“协调者向参与者发“准备提交”命令,则参与者接收命令后发“准备就绪”给协调者; 第三阶段为: 当协调者收到所有参与者发来的“准备就绪”命令后,再向参与者发“提交”命令。参与者收到提交命令后,即可进行提交。
在3PC协议中,避免事务进入阻塞状态的策略是在参与者进行提交之前,已经知道其他参与者已经进入“准备提交”状态。这时,即使协调者场地发生故障,在没有收到“提交”命令情况下,每个参与者也可自行决定进行提交和废弃,不必进入阻塞状态。
3PC协议的工作过程为:
第一阶段: 协调者向所有的参与者发“开始提交”报文,当收到所有参与者发回的“同意提交”报文后,进入第二阶段;
第二阶段: 协调者向所有的参与者发“准备提交”报文,当所有参与者已经准备好提交,发回“准备就绪”报文,进入第三阶段; 否则,进行废弃处理。
第三阶段:协调者收到所有的参与者发回的“准备就绪”报文后,向所有参与者发“提交”报文,所有参与者收到提交报文后,即可进行提交。
4.分布式事务管理参考模型

图4 分布式事务管理参考模型

分布式事务管理参考模型如图4所示。局部事务由本地事务管理器执行,分布式事务由分布式事务管理器与局部事务管理器协同完成。具体介绍如下:
GTM(全局事务管理): 负责处理全局事务调度以及将全局事务划分为各子事务等。
DTM(分布事务管理): 负责管理分布式事务,调度子事务的执行,保证分布式事务的原子性。
LTM(局部事务管理):负责管理DTM交付的子事务的执行,保证子事务的原子性。
根代理向DTM发出事务开始、提交和废弃的命令,由DTM之间协调分布式事务的执行。根代理与DTM的接口命令原语有: 事务开始命令(begin_transaction)、事务提交命令(commit)和事务废弃命令(abort)。
LTM之间不需要进行通信联系,它们执行上层DTM发来的命令原语。DTM与LTM的接口命令原语有:局部事务开始命令(local_begin)、局部事务提交命令(local_commit)、局部事务废弃命令(local_abort)和局部创建代理命令(local_creat)。