您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 人事档案/员工关系 > 分布式事务管理与恢复
1第十章分布式事务管理与恢复2事务概念•事务是访问或更新各种数据项的程序执行单元.•事务必须保证数据库的一致性•事务执行期间数据库可能不一致3事务概念-续•当事务提交(commit)时数据库必须是一致的DataBaseConsistentConsistentT4事务概念-续•两个问题:–故障各种软硬件故障–并发执行多个事务同时执行5事务性质•ACID–原子性(Atomicity)事务的操作要么全部执行,要么全部不执行–一致性(Consistency)并发执行的多个事务,其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同.–持久性(Durability)当事务提交后,其操作的结果将永久化,而与提交后发生的故障无关6事务性质-续–独立性(Isolation)虽然可以有多个事务同时执行,但是单个事务的执行不应该感知其他事物的存在,因此事务执行的中间结果应该对其他并发事务隐藏•一对事务Ti和Tj的执行,看起来好像是或者Ti在Ti执行结束之后才开始执行,或者Tj,是在Ti执行结束之后才开始执行7举例•从账号A向账号B转账$50:1.read(A)2.A:=A–503.write(A)4.read(B)5.B:=B+506.write(B)8举例-续•一致性要求事务执行后A和B账号的总金额不变•原子性要求如果事务在第3步和第6步之间故障,系统应该保证事务对数据库的修改没有产生,否则将导致不一致性9举例-续•持久性要求一旦用户通知说事务已经完成(即$50转账成功),那么由该事务对数据库的修改就必须保证是永久的,即使是发生故障也如此10举例-续•独立性要求如果在第3步和第6步之间,允许其他事务访问被修改的数据库的中间结果,那么它将见到一个不一致的数据库(也就是说,A+B的和少于它的正确值)当然事务的串行执行将不会出现这种情况,但是数据库中事务并行执行的优点就损失了11事务状态•活动从事务开始执行的初始状态始,事务执行中保持该状态•部分提交事务的昀后一个语句执行后进入该状态.•失败一旦发现事务不能正常执行时进入该状态•夭折当事务被回滚后,数据库恢复到事务开始执行前的状态。事务夭折后有两种选择–重启动仅当没有内部逻辑错误时–杀死•提交当事务成功执行后.12事务状态-续活动部分提交失败提交夭折13SQL中的事务定义•数据操作语言中包含说明一组操作组成一个事务的结构.•SQL中,事务隐含的开始.•SQL中,如下语句结束事务:–Commitwork提交当前的事务,开始一个新的事务.–Rollbackwork是当前的事务夭折.14SQL中事务定义-续•SQL-92中事务一致性级别:–Serializable缺省–Repeatableread–Readcommitted–Readuncommitted15分布式事务•分布式事务是由若干个不同Site上的子事务组成的事务•事务的ACID性质此时事务的原子性、一致性、持久性、独立性等都要将每个Site上的子事务考虑在内16分布式事务结构BeginTrans....Abort/CommitBeginTransT1[]T2[]...Tn[]Abort/Commit17事务代理•事务代理(Agent):某一应用在各个Site上执行的若干进程,称作应用在该Site上的代理。代理可以执行应用程序员写的程序,也可以执行系统的原语函数,不同代理间通过报文实现通讯•根代理(RootAgent):应用启动Site上的代理。根代理所在的Site称作原发Site.一般,根代理负责发系统原语,只有根代理可以请求创建新代理。18转账应用事务在两个账户之间执行“基金汇兑”操作。全局关系Account(Account-number,Amount)假设账户分布在网络的不同站点上。19全局级转帐事务FUND_TRANSFER:read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;selectAMOUNTinto$FROM_AMOUNTfromACCOUNTwhereACCOUNT_NUMBER=$FROM_ACC;if$FROM_AMOUNT-$AMOUNT0thenabortelsebeginupdateACCOUNTsetAMOUNT=AMOUNT-$AMOUNTwhereACCOUNT_NUMBER=$FROM_ACC;updateACCOUNTsetAMOUNT=AMOUNT+$AMOUNTwhereACCOUNT_NUMBER=$TO_ACC;commitend20输入:汇出金额和转入/转出帐号事务开始:检查转出帐号中是否有足够的转出资金?更新转出帐号存款余额创建AGENT1向代理1送消息:转入帐号,金额等待来自AGENT1的消息成功?提交事务:成功结束撤消事务:失败结束ROOT_AGENTAGENT接收来自根代理的信息更新转入帐号存款余额发送执行消息给根代理(成功或失败)是否否转账应用处理流程21ROOT_AGENT;read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;selectAMOUNTinto$FROM_AMOUNTfromACCOUNTwhereACCOUNT_NUMBER=$FROM_ACC;if$FROM_AMOUNT-$AMOUNT0thenabortelsebeginupdateACCOUNTsetAMOUNT=AMOUNT-$AMOUNTwhereACCOUNT_NUMBER=$FROM_ACC;createAGENT;sendtoAGENT($AMOUNT,$TO_ACC);commit/*这里省略了等待消息和判别*/endAGENT;receivefromROOT_AGENT($AMOUNT,$TO_ACC);updateACCOUNTsetAMOUNT=AMOUNT+$AMOUNTwhereACCOUNT=$TO_ACC;sendtoROOT_AGENT(‘SUCCESS’/’FALL’)转账事务的两个代理22事务管理目标•目的事务能有效、可靠、并发的执行•效率的几个重要方面–CPU和主存的使用–控制报文–响应时间–可用性•目标–维护事务的ACID性质–获得昀小的主存和CPU开销,降低报文数目,加快响应时间–获得昀大限度的可靠性和可用性23事务管理•DTM功能–保证分布式Trans的特征,特别是原子性–支持分布式Trans执行的位置传递•LTM功能–保证本地Trans的特征–代替DTM把分布Trans的执行与恢复信息记入Log–接收并遵从本Site上DTM发来的Log原语,记入Log并执行之DTMLTMSiteLog原语:LocalBegin-Trans,Local-Commit,Local-Abort24分布式Trans执行的控制模型•主从模型LTM之间无通信•三角模型LTM之间有通信•层次控制模型LTM之间有通信,并且LTM还可再创建Agent,控制其它LTM执行25分布式事务管理器局部事务管理器局部事务管理器局部事务管理器数据库数据库数据库命令命令命令回答回答回答主从控制26分布式事务管理器局部事务管理器局部事务管理器数据库数据库命令命令回答回答临时数据三角控制27分布式事务管理器局部事务管理器数据库命令命令回答回答局部事务管理器局部事务管理器局部事务管理器局部事务管理器局部事务管理器命令命令命令命令回答回答回答回答数据库数据库数据库数据库数据库…………层次控制28故障类型•事务故障由非预期的、不正常的程序结束所造成的故障,即事务没有执行到Commit或显示Rollback语句的故障,如:溢出、死循环等内存、磁盘上信息没有损失,使用Log做Rollback•系统故障造成系统停止运行的任何事件,要求系统重启动内存、I/OBuffer内容皆丢失,DB没有破坏,恢复时,搜索Log,确定Rollback的Trans。设置检查点29故障类型-续•介质故障辅助存储器介质遭破坏–数据丢失,日志无损失从某个Dump状态开始执行已提交事务–数据与日志都丢失不可能完全恢复•通讯故障前三种统称为站点故障.30通讯故障•通讯发生,既有某个报文Message从Sitex发往Sitey,正常情况:(a)在Dmax之后,x站点收到y发回的应答信息(Ack)(b)y收到的Message是一个合适的次序(c)Message本身的信息是正确的但是当某个Dmax之后,x还没收到y的Ack,则可能发生:(a)Message或Ack信息丢失(b)网络分割,及网络不通SitexSiteymessageAck31通讯故障-续问题可以进一步分为:a)是否是所在Site故障,还是系统慢下来了?b)若是故障,是通讯故障,还是y站点故障?c)Message是否已到达y站点?对上述故障,其恢复程序可以有不同级别:一级:仅处理Site故障二级:Site故障及Message故障三级:Site故障及Message故障,还包括网络分割SiteSiteSiteSiteSiteSiteSite32恢复算法•恢复算法是保证系统故障后数据库仍保持一致性,以及保证事务原子性和持久性的技术•恢复算法有两部分组成–在事务正常执行时,记录下足够的能使系统恢复的信息–在故障发生时,恢复数据库到一致性、原子性和持久性状态33恢复算法-续•两类恢复技术:–基于日志方法–影子页面(shadow-paging)方法•先假设事务是串行执行34日志•Log记录所有对DB的操作•事务标识每个事务给定一个具有唯一性的标识符•Log记录项:[开始,T],[提交,T],[夭折,T],[读,T,x],[写,T,x,旧值,新值]•DB/Log写动作Log优先•Log存储一般存在盘上,事务提交时,LogBuffer强迫写35Log举例LogWriteOutputT0startT0,A,1000,950To,B,2000,2050A=950B=2050T0commitT1startT1,C,700,600C=600BB,BAT1commitBC注:BX表示含有X的存储块.36数据访问xYABx1y1缓冲区缓冲块A缓冲块Binput(A)output(B)read(X)write(Y)磁盘T1工作区T2工作区主存x237日志缓冲区……数据库缓冲区(易变数据库)局部恢复管理器数据库缓冲区管理器主存取出读/写读/写日志档案库DB档案库稳定日志稳定DB读/写读/写38日志恢复举例•两个事务T0和T1(T0在T1前执行):T0:read(A)T1:read(C)A:=A-50C:=C-100Write(A)write(C)read(B)B:=B+50write(B)39日志恢复举例-续•事务执行在不同时刻的日志.40日志恢复举例-续•故障发生时刻不同,处理不同:(a)undo(T0):B还原到2000,A还原到1000.(b)undo(T1)并且redo(T0):C还原到700,A和B分别为950和2050.(c)redo(T0)和(T1):A和B分别取值950和2050.C取值60041检查点•日志恢复问题:–搜索整个日志非常耗时–某些已经写入数据库的更新还要重复执行.42检查点-续•检查点–设置一个周期性操作点a)LogBuffer写入Log数据集b)写[检查点]Log项,当前活动事务表,每个事务昀近一次Log记录在Log文件中的位置c)DBBuffer写入DBd)将[检查点]Log项在Log文件中的位置记入“重启动文件”43检查点-续•T1可以忽略(因为有检查点,更新已经被写入磁盘)•T2和T3redone.•T4undoneTcTfT1T2T3T4checkpointsystemfailure44事务故障恢复•恢复原则–孤立和逐步退出事务的原则undo事务已对DB的修改(不影响其他事务的可排除性局部故障)–成功结束事务原则Redo已成功事务的操作–夭折事务原则撤销全部事务,恢复到初态(Undo)45事务故障恢复-续•本地事务
本文标题:分布式事务管理与恢复
链接地址:https://www.777doc.com/doc-6426015 .html