分布式事務概述分布式事務的執(zhí)行和恢復兩階段提交協(xié)議分布

1、1. 1.分布式事務概述分布式事務概述2.2.分布式事務的執(zhí)行和恢復分布式事務的執(zhí)行和恢復3.3.兩階段提交協(xié)議兩階段提交協(xié)議4.4.分布式數據庫中的數據更新分布式數據庫中的數據更新5.5.分布式事務增強數據庫一致性分布式事務增強數據庫一致性6.6.總結總結分布式數據庫中的事務管理和恢復分布式數據庫中的事務管理和恢復 第第4章章事務概念 事務是訪問或更新各種數據項的最小邏輯工作單位。 它是一個操作序列 它可以使數據庫從一個一致狀態(tài)到另外一個一致狀態(tài) 事務必須保證數據庫的一致性 事務執(zhí)行期間數據庫可能不一致1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述 當事

2、務提交（commit）時數據庫必須是一致的事務T開始事務T結束事務T的執(zhí)行數據庫一致數據庫一致數據庫可能臨時不一致1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述事務概念分布式事務 集中式 事務和操作數據在一個站點上 不存在傳輸費用 分布式 操作數據分布在不同的站點上 事務也在多個站點上執(zhí)行 分布式事務是集中式事務的擴充 站點和通信鏈路故障都可能導致錯誤發(fā)生 分布式事務的恢復要比集中式事務復雜的多1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述 事務分類: 全局事務 通常由一個主事務和在不同站點上執(zhí)行的子事務組成 主事務：

3、負責事務的開始、提交和異常終止 子事務：完成對相應站點上的數據庫的訪問操作 局部事務 僅訪問或更新一個站點上的數據的事務1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述分布式數據庫中的事務分布式數據庫中的事務 ACID特性 原子性（原子性（Atomicity） 事務的操作要么全部執(zhí)行，要么全部不執(zhí)行，保證數據庫一致性狀態(tài)。 一致性（一致性（Consistency） 事務的正確性，串行性，并發(fā)執(zhí)行的多個事務，其操作的結果應與以某種順序串行執(zhí)行這幾個事務所得的結果相同。 持久性（持久性（Durability） 當事務提交后，其操作的結果將永久化，而與提交后發(fā)生的

4、故障無關。 1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述分布式事務特性分布式事務特性 隔離性（ Isolation） 雖然可以有多個事務同時執(zhí)行，但是單個事務的執(zhí)行不應該感知其他事務的存在，因此事務執(zhí)行的中間結果應該對其他并發(fā)事務隱藏 。 此外，分布式數據庫系統(tǒng)中還要考慮數據傳送、通信原語和控制報文等。 全局事務的主事務和子事務全部成功提交，才能改變數據庫狀態(tài)，有一個失敗，其他子事務操作都要撤銷。1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述分布式事務特性分布式事務特性 從賬號A向賬號B轉賬 $50: 1. read

5、(A) 2. A := A 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B)1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述分布式事務特性舉例分布式事務特性舉例 一致性要求: 事務執(zhí)行后A 和 B賬號的總金額不變 原子性要求: 如果事物在第3步和第6步之間故障，系統(tǒng)應該保證事務對數據庫的修改沒有產生，否則將導致不一致性。1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述分布式事務特性舉例分布式事務特性舉例 持久性要求: 一旦用戶通知說事務已經完成（即$50 轉賬成功），

6、那么由該事務對數據庫的修改就必須保證是永久的，即使是發(fā)生故障也如此。1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述分布式事務特性舉例分布式事務特性舉例 獨立性要求 如果在第 3步和第6步之間，允許其他事務訪問被修改的數據庫的中間結果，那么它將見到一個不一致的數據庫 (也就是說， A + B 的和少于它的正確值） 當然事務的串行執(zhí)行將不會出現這種情況，但是數據庫中事務并行執(zhí)行的優(yōu)點就損失了1.1 分布式事務定義和特性分布式事務定義和特性1 1 分布式事務概述分布式事務概述分布式事務特性舉例分布式事務特性舉例Begin Transaction原語：開始一個事務

7、 T1 T2 : 子事務或操作序列 : TnCommit原語：事務成功完成的結束Rollback或Abort原語：事務失敗的結束1.2 分布式事務結構和事務狀態(tài)分布式事務結構和事務狀態(tài)1 1 分布式事務概述分布式事務概述分布式事務的一般結構分布式事務的一般結構 活動 從事務開始執(zhí)行的初始狀態(tài)始， 事務執(zhí)行中保持該狀態(tài) 部分提交 事務的最后一個語句執(zhí)行后進入該狀態(tài) 失敗 一旦發(fā)現事務不能正常執(zhí)行時進入該狀態(tài)一旦發(fā)現事務不能正常執(zhí)行時進入該狀態(tài) 夭折 當事務被回滾后，數據庫恢復到事務開始執(zhí)行前當事務被回滾后，數據庫恢復到事務開始執(zhí)行前的狀態(tài)。的狀態(tài)。 事務夭折后有兩種選擇 重啟動 僅當沒有內部邏輯

8、錯誤時 殺死 提交 當事務成功執(zhí)行后1.2 分布式事務結構和事務狀態(tài)分布式事務結構和事務狀態(tài)1 1 分布式事務概述分布式事務概述分布式事務的狀態(tài)分布式事務的狀態(tài)1.2 分布式事務結構和事務狀態(tài)分布式事務結構和事務狀態(tài)1 1 分布式事務概述分布式事務概述分布式事務的狀態(tài)分布式事務的狀態(tài) 進程：系統(tǒng)中可以并行執(zhí)行的一段操作序列，分布式事務中的子事務序列是進程方式完成的 過程：不可并行執(zhí)行的操作序列 事務代理（Agent）：應用在各個Site上執(zhí)行的若干進程，稱作應用在該Site上的代理。代理可以執(zhí)行應用程序員寫的程序，也可以執(zhí)行系統(tǒng)的原語函數，不同代理間通過報文實現通訊 根代理（Root Agen

9、t） 應用啟動Site上的代理。根代理所在的Site稱作原發(fā)Site。一般，根代理負責發(fā)系統(tǒng)原語，只有根代理可以請求創(chuàng)建新代理。1.2 分布式事務結構和事務狀態(tài)分布式事務結構和事務狀態(tài)1 1 分布式事務概述分布式事務概述進程相關定義進程相關定義 為了協(xié)調執(zhí)行分布式應用的全局操作，分駐于不同站點的諸事務代理必須進行協(xié)調，有如下規(guī)定： 每一應用都有一個負責啟動整個事務的總代理（或稱根代理） 只有總代理才能發(fā)出全局有效的事務開始、提交和撤消原語 只有總代理才能請求建立新的事務代理 各站點上的子事務都執(zhí)行成功，總代理才能決定提交該事務，否則總代理將決定撤銷該事務1.2 分布式事務結構和事務狀態(tài)分布式事

10、務結構和事務狀態(tài)1 1 分布式事務概述分布式事務概述進程協(xié)作進程協(xié)作轉賬應用事務在兩個賬戶之間執(zhí)行“基金匯兌”操作。如果匯兌的金額小于轉出帳號現有金額，就撤銷如果大于等于就提交全局關系 Account (Account-number, Amount)假設賬戶分布在網絡的不同站點上。1.2 分布式事務結構和事務狀態(tài)分布式事務結構和事務狀態(tài)1 1 分布式事務概述分布式事務概述全局級轉帳事務FUND_TRANSFER:read (terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;select AMOUNT into $FROM_AMOUNT

11、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輸入：匯出金額和轉入/轉出帳號事務開始：檢查轉出帳號中是否 有足夠的轉出資金？更新轉出帳號存款余額

12、創(chuàng)建AGENT1向代理1送消息：轉入帳號，金額等待來自AGENT1的消息成功？提交事務：成功結束撤消事務：失敗結束ROOT_AGENTAGENT接收來自根代理的信息更新轉入帳號存款余額發(fā)送執(zhí)行消息給根代理(成功或失敗)是否否轉賬應用處理流程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 abor

13、telse begin 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、轉賬事務的兩個代理分布式事務管理問題分布式事務管理問題 處理數據項的多個副本 分布式事務處理負責保持同一數據的多個副本之間的一致性。當某個副本所在站點發(fā)生故障時，負責生成與該數據其他副本一致的拷貝，以便于及時恢復。 單個站點的故障 一個站點或多個站點故障時，DDBMS繼續(xù)與其他正常運行的站點一起繼續(xù)工作 當故障站點恢復時， DDBMS協(xié)同故障站點的DBMS，必須使得該站點與系統(tǒng)連接時，局部數據庫與其他站點同步 通信網絡的故障 必須能夠處理兩個或者多個站點間的通信網絡故障 分布式提交 如果提交分布式事務過程中有一個站點發(fā)生故障，提交就會產生問題 兩階段提交協(xié)議用于解決這一問題1.3 分布式事務管

15、理的問題和目標分布式事務管理的問題和目標1 1 分布式事務概述分布式事務概述分布式事務管理目標分布式事務管理目標 目的：事務能有效、可靠、并發(fā)的執(zhí)行 除了策略之外，效率的幾個重要方面 CPU和主存的使用 控制報文 響應時間 可用性 目標 維護事務的ACID性質 獲得最小的主存和CPU開銷，降低報文數目，加快響應時間 獲得最大限度的可靠性和可用性1.3 分布式事務管理的問題和目標分布式事務管理的問題和目標1 1 分布式事務概述分布式事務概述抽象模型抽象模型LTM: Local Transaction Manager DTM: Distributed Transaction Manager2.1

16、分布式事務管理的抽象模型分布式事務管理的抽象模型2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復本地事務管理器 LTM1本地事務管理器 LTM2本地事務管理器 LTMn分布式事務管理器 DTM1分布式事務管理器 DTM2分布式事務管理器 DTMn站點 n站點 2站點 1事務管理事務管理 DTM功能 保證分布式事務ACID特性， 特別是原子性，使每一站點的子事務都成功執(zhí)行，或者都不執(zhí)行。 通過向各站點發(fā)begin-transaction,commit或者abort,create原語來實現的 負責協(xié)調由該站點發(fā)出的所有分布式事務的執(zhí)行 啟動分布式事務的執(zhí)行 將分布式事務分解為子事務，并將其分派

17、到恰當的站點上執(zhí)行 決定分布式事務的終止（子事務都提交或者都撤銷） 支持分布式事務執(zhí)行位置透明性 實現了對網絡上各站點的各子事務的監(jiān)督和管理 完成對整個分布式事務執(zhí)行過程的調度和管理 保證分布式數據庫系統(tǒng)的高效率Log原語： Local Begin-Trans, Local-Commit, Local-Abort2.1 分布式事務管理的抽象模型分布式事務管理的抽象模型2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復事務管理事務管理 LTM功能 保證本地事務的ACID特性 維護一個用于恢復的日志，代替DTM把分布事務的執(zhí)行與恢復信息記入日志 參與適當的并發(fā)控制模式，以協(xié)調在該站點上執(zhí)行的事務

18、的并發(fā)執(zhí)行。接收并遵從本Site上DTM發(fā)來的Log原語，記入Log并執(zhí)行之Log原語： Local Begin-Trans, Local-Commit, Local-Abort2.1 分布式事務管理的抽象模型分布式事務管理的抽象模型2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復分布式事務執(zhí)行的控制模型分布式事務執(zhí)行的控制模型 是指協(xié)調分布式事務中各成員DBMS執(zhí)行其子事務的通用方法，有三種: 主從模型：主、從控制器，LTM之間無通信 三角模型：LTM之間可以傳遞數據，避免了主從之間不必要的傳輸 層次控制模型：LTM還可再創(chuàng)建Agent，控制其它LTM執(zhí)行，比前兩種復雜2.2 分布式事務

19、執(zhí)行的控制模型分布式事務執(zhí)行的控制模型2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復分布式事務管理器局部事務管理器局部事務管理器局部事務管理器數據庫數據庫數據庫命令命令命令回答回答回答主從控制模型分布式事務管理器局部事務管理器局部事務管理器數據庫數據庫命令命令回答回答臨時數據三角控制模型分布式事務管理器局部事務管理器數據庫命令命令回答回答局部事務管理器局部事務管理器局部事務管理器局部事務管理器局部事務管理器命令命令命令命令回答回答回答回答數據庫數據庫數據庫數據庫數據庫層次控制模型 故障類型 事務故障 由非預期的、不正常的程序結束所造成的故障，即事務沒有執(zhí)行到Commit或顯示Rollba

20、ck語句的故障，如：計算溢出、完整性破壞、操作員干預、輸入輸出錯誤、死循環(huán)等） 處理方法：內存、磁盤上信息沒有損失，使用Log做Rollback 系統(tǒng)故障 造成系統(tǒng)停止運行的任何事件，要求系統(tǒng)重啟動，如CPU出錯、緩沖區(qū)滿、系統(tǒng)崩潰等 處理方法：內存、I/O Buffer內容皆丟失，DB沒有破壞，恢復時，搜索Log，確定Rollback的事務。2.3 分布式數據庫系統(tǒng)中的故障分布式數據庫系統(tǒng)中的故障2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 介質故障： 輔助存儲器介質遭破壞 處理方法：如數據丟失, 日志無損失，從某個Dump狀態(tài)開始執(zhí)行已提交事務；數據與日志都丟失 不可能完全恢復以上

21、三種可以統(tǒng)稱為站點故障. 2.3 分布式數據庫系統(tǒng)中的故障分布式數據庫系統(tǒng)中的故障2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復通訊故障 報文故障 報文錯 報文失序 報文丟失 報文延遲 網絡分割故障（網絡斷連） 通訊發(fā)生, 即有某個報文Message從Site x 發(fā)往Site y, 正常情況:(a) 在某時間段Dmax 中, x 站點收到y(tǒng)發(fā)回的應答信息(Ack)(b) y收到的Message是一個合適的次序(c ) Message本身的信息是正確的 但是當某個Dmax之后, x還沒收到y(tǒng)的Ack, 則可能發(fā)生: (a) Message 或 Ack 信息丟失 (b) 網絡分割, 即網絡

22、不通2.3 分布式數據庫系統(tǒng)中的故障分布式數據庫系統(tǒng)中的故障2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 問題可以進一步分為:a) 是否是所在Site故障, 還是系統(tǒng)響應過慢，還是網絡流量過大b) 若是故障, 是通訊故障, 還是 y 站點故障?c) 如果是報文故障，是報文丟失還是應答丟失 對上述故障, 其恢復程序可以有不同級別:一級: 僅處理Site故障二級: Site故障及Message故障三級: Site故障及Message故障, 還包括網絡分割2.3 分布式數據庫系統(tǒng)中的故障分布式數據庫系統(tǒng)中的故障2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 事務恢復 當發(fā)生故障時，保證

23、事務原子性的措施稱為事務故障恢復，簡稱事務恢復 主要依靠日志來實現 事務狀態(tài)轉移跟蹤（操作） Begin_transaction：標記事務開始執(zhí)行 Read & write：表示事務對某個數據項進行讀寫 End_transaction：表示讀寫操作已完成，標記事務執(zhí)行結束 Commit_transaction：表示事務已經成功結束，任何改變已不可更改 Rollback (abort)：表示事務沒有成功結束，撤銷事務對數據庫所作的任何改變2.4 事務故障恢復的基本概念事務故障恢復的基本概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復2.4 事務故障恢復的基本概念事務故障恢復的基本

24、概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復ACTVEPARTIALLYCOMMITTEDCOMMITEDFAILEDTERMINATED BEGIN TRANSACTION READ/ WRITE END TRANSACTIONCOMMITABORTABORT 事務的提交點 當事務T所有的站點數據庫存取操作都已成功執(zhí)行； 所有操作對數據庫的影響都已記錄在日志中。到達提交點 提交點后事務就成為已提交的事務，并假定其結果已永久記錄在數據庫中 事務在日志中寫入提交記錄commit,T 在系統(tǒng)發(fā)生故障時，需要掃描日志，檢查日志中寫入start_transaction,T,但沒有寫入com

25、mit,T的所有事務T 恢復時必須回滾這些事務以取消他們對數據庫的影響 此外，還必須對日志中記錄的已提交子事務的所有寫操作進行恢復。2.4 事務故障恢復的基本概念事務故障恢復的基本概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 事務的提交點相關操作（日志） 日志文件保存到磁盤上 一般先將文件的相關塊，從磁盤拷貝到主存的緩沖區(qū)，然后更新，再寫回磁盤 緩沖區(qū)中會經常存在一個或多個日志文件塊，寫滿后一次性寫回磁盤 系統(tǒng)崩潰時，主存中的信息會丟失，這些信息無法利用 因此，事務到達提交點之前，未寫到磁盤的日志必須寫入，稱為事務提交前強制寫日志。2.4 事務故障恢復的基本概念事務故障恢復的基本概

26、念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 日志 Log：記錄所有對DB的操作 事務標識：每個事務給定一個惟一性的標識符 Log記錄項 : start_transaction, T, write_item, T, x, 舊值, 新值 read_item, T, x commit, T abort, T 寫動作：寫Log比寫數據優(yōu)先 Log存儲：一般磁盤，還會定期備份到磁帶上2.4 事務故障恢復的基本概念事務故障恢復的基本概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復Log舉例舉例Log Write Output A = 950 B = 2050 C = 600 BB, B

27、A BC注: BX 表示含有X的存儲塊.2.4 事務故障恢復的基本概念事務故障恢復的基本概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復數據訪問數據訪問xYABx1y1 緩沖區(qū)緩沖塊 A 緩沖塊 Binput(A)output(B) read(X)write(Y)磁盤 T1工作區(qū)T2 工作區(qū)主存x22.4 事務故障恢復的基本概念事務故障恢復的基本概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 檔案庫檔案庫 一天要產生大量的Log Log劃分為兩部分 一部分是當前活動的聯機部分，存儲在磁盤上 另一部分是檔案存儲部分，存儲在磁帶上2.4 事務故障恢復的基本概念事務故障恢復的基本概

28、念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復日志緩沖區(qū)數據庫緩沖區(qū)(易變數據庫)局部恢復管理器數據庫緩沖區(qū)管理器主存fetch/flush讀/寫讀/寫日志檔案庫DB檔案庫穩(wěn)定日志穩(wěn)定DB讀/寫讀/寫2.4 事務故障恢復的基本概念事務故障恢復的基本概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復數據庫、日志和檔案庫的存儲模式數據庫、日志和檔案庫的存儲模式 檢查點（Checkpoint） 設置一個周期性（時間/容量）操作點a) Log Buffer內容寫入Log數據集b) 寫檢查點Log信息：當前活動事務表, 每個事務最近一次Log記錄在Log文件中的位置c) DB Buffer

29、內容寫入DBd) 將本次檢查點Log項在Log文件中的地址記入“重啟動文件”2.4 事務故障恢復的基本概念事務故障恢復的基本概念2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 事務本身也會發(fā)生故障，也是主要通過日志來實現恢復 恢復原則 孤立和逐步退出事務的原則 undo 事務已對DB的修改 ( 不影響其他事務的可排除性局部故障，如事務操作的刪除、超時、違反完整性原則、資源、限制和死鎖等) 成功結束事務原則 Redo 已成功事務的操作 夭折事務原則 撤銷全部事務, 恢復到初態(tài)，兩種做法：利用數據備份和Undo 2.5 事務故障的恢復事務故障的恢復2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)

30、行與恢復 本地事務恢復 (與集中式恢復相同) 從“重啟動文件” 讀出最近Checkpoint的地址, 并定出Checkpoint在Log文件中的位置 創(chuàng)建Redo表（初態(tài)為空）, Undo表(即Checkpoint相應內容中的活動事務表) 檢查得出Undo事務（向前檢索，遇到begin transaction的log記錄，其對應的事務）與Redo事務（向前檢索，遇到commit的log記錄，其對應事務） 反向檢索Log, 將Undo表中事務, 直到遇到對應的Begin Trans 正向檢索Redo事務的Log記錄, 并執(zhí)行之, 直到對應的Commit記錄2.5 事務故障的恢復事務故障的恢復2

31、2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復重啟動文件UNDOREDO活動事務表故障發(fā)生地址c0c1(1)(3)(5)(2)(4)日志數據集利用日志進行事務恢復的過程2.5 事務故障的恢復事務故障的恢復2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復Checkpoints 舉例 T1 可以忽略 (因為有檢查點，更新已經被寫入磁盤) T2 和 T3 redo. T4 undoTcTfT1T2T3T4checkpointsystem failure2.5 事務故障的恢復事務故障的恢復2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復分布式事務恢復參考模型RootAgentAgentAge

32、ntDTM-Agent站點1的LTMDTM-AgentDTM-Agent站點2的LTM站點n的LTM全局事務分布式事務管理器(DTM)局部事務 管理器 (LTM)2.5 事務故障的恢復事務故障的恢復2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復 分布式事務模型 底層：本地事務管理層，LTM之間不需要進行聯系，執(zhí)行上層DTM代理發(fā)來的原語，實現接口1 Local begin, local commit, local abort, local create 中間層：分布式事務管理層，一組互相交換報文的本地DTM組成，實現接口2 Begin transaction, commit, abort

33、, create 頂層：全局事務層，由總代理和其他代理組成，只有它與中間層聯系2.5 事務故障的恢復事務故障的恢復2 2 分布式事務的執(zhí)行與恢復分布式事務的執(zhí)行與恢復.Begin Transaction.Create Agent1Send to Agent1.Local-begin .Send Create ReqWriteBegin -transactionin Local LogRoot AgentDTM-AgentLTMReceive.Local CreateLocal-begin.WriteBegin -transactionin Local LogLTMDTM-Agent Agent

34、113245678分布式事務執(zhí)行和恢復舉例 基本思想 將本地原子性提交行為的效果擴展到分布式事務, 保證了分布式事務提交的原子性, 并在不損壞Log的情況下, 實現快速故障恢復, 提高DDB系統(tǒng)的可靠性. 第一階段：表決階段 第二階段：執(zhí)行階段 兩類代理 協(xié)調者(Coordinator)：提交和撤銷事務的決定權，一般是總代理 參與者(Participants)：負責在本地數據庫中執(zhí)行寫操作，并且向協(xié)調者提出提交和撤銷子事務的意向3.1 基本思想和內容基本思想和內容3 3 兩階段提交協(xié)議兩階段提交協(xié)議3.1 基本思想和內容基本思想和內容3 3 兩階段提交協(xié)議兩階段提交協(xié)議協(xié)調者 參與者日志日志日

35、志日志命令應答. . 參與者 參與者2PC中協(xié)調者和參與者的關系中協(xié)調者和參與者的關系 表決階段 目的是形成一個共同的決定 首先，協(xié)調者給所有參與者發(fā)送“準備”消息，進入等待狀態(tài) 其次，參與者收到“準備”消息后，檢查是否能夠提交本地事務 如能，給協(xié)調者發(fā)送“建議提交”消息,進入就緒狀態(tài) 如不能，給協(xié)調者發(fā)送“建議撤銷”消息，可以單方面撤銷 第三，協(xié)調者收到所有參與者的消息后，他就做出是否提交事務的決定， 只要有一個參與者投了反對票，就決定撤銷整個事務，發(fā)送“全局撤銷”消息給所有參與者，進入撤銷狀態(tài) 否則，就決定提交整個事務，發(fā)送“全局提交”消息給所有參與者，進入提交狀態(tài) 執(zhí)行階段 實現表決階段

36、的決定，提交或者撤銷3.1 基本思想和內容基本思想和內容3 3 兩階段提交協(xié)議兩階段提交協(xié)議初始寫begin_commit到日志等待有要求撤消的？寫commit到日志提交寫end_of_transt到日志初始準備提交？寫ready到日志就緒消息類型？寫abort到日志寫commit到日志提交撤消撤消寫abort到日志寫abort到日志協(xié)調者參與者nonoabortcommit準備撤消提交全局撤消全局提交ACKACK兩階段提交協(xié)議的活動 2PC協(xié)議的重要特點 允許參與者單方面撤銷事務 一旦參與者確定了提交或撤銷協(xié)議，它就不能再更改它的提議 當參與者處于就緒狀態(tài)時，根據協(xié)調者發(fā)出的消息種類，它可以

37、轉換為提交狀態(tài)或者撤銷狀態(tài) 協(xié)調者根據全局提交規(guī)則做出全局終止決定 協(xié)調者和參與者可能進入互相等待對方消息的狀態(tài)，使用定時器，保證退出消息等待狀態(tài)3.1 基本思想和內容基本思想和內容3 3 兩階段提交協(xié)議兩階段提交協(xié)議 集中式 通訊只發(fā)生在協(xié)調者和參與者之間，參與者之間不交換信息 分層式 協(xié)調者是在樹根的DTM代理者，協(xié)調者與參與者之間的通訊不用直接廣播的方法進行，而是使報文在樹中上下傳播。每個DTM代理是通信樹的一個內部節(jié)點，它從下層節(jié)點處收集報文或向它們廣播報文。 線性 參與者之間可以互相通信。系統(tǒng)中的站點間要排序，消息串行傳遞。支持沒有廣播功能的網絡 分布式 允許所有參與者在第一階段相互

38、通信，從而可以獨立做出事務終止決定。3.2 通信結構通信結構3 3 兩階段提交協(xié)議兩階段提交協(xié)議23451234511協(xié)調者參與者協(xié)調者協(xié)調者參與者第一階段第二階段準備建議撤消/提交全局撤消/提交提交/撤消集中式集中式34251511協(xié)調者參 與 者協(xié)調者協(xié)調者參 與 者第一階段第二階段準備建議撤消/提交全局撤消/提交提交/撤消23422分層式分層式1234n第一階段第二階段準備建議提交/撤消建議提交/撤消建議提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消線性式線性式1n4324321n協(xié)調者協(xié)調者協(xié)調者+參與者第一階段準備建議撤消/提交全局撤消/提交可獨立做決定分布式分布

39、式1.站點故障a 參與者在將“Ready”記錄入Log之前故障此時協(xié)調者(C)達到超時，Abort發(fā)生。站點（P）恢復時，重啟動程序將執(zhí)行Abort，不必從其他站點獲取信息。b 當將“Ready”寫入Log后，站點故障此時所有運行的站點都將正常結束事務（Commit/Abort)。P恢復時，因為P已Ready，所以不可判定C的最終決定。因此恢復時，重啟動程序要詢問C或其他站點。c 當C將“Prepare”寫入Log，但“G-commit”/”G-abort”還沒有寫入前故障所有回答“Ready”的P等待C恢復。C重啟動時，將重開提交協(xié)議，重發(fā)“Prepare”，于是P要識別重發(fā)。d C在將“G

40、-commit”/”G-abort”寫入Log后，“Complete”沒有寫入前故障收到命令的P正常執(zhí)行，C重啟動程序必須再次向所有P重發(fā)命令。以前沒有收到命令的P也必須等待C恢復，P要識別兩次命令。e “Complete”寫入Log后故障無任何動作發(fā)生3.2 兩階段提交協(xié)議兩階段提交協(xié)議和故障恢復和故障恢復3 3 兩階段提交協(xié)議兩階段提交協(xié)議2. 報文丟失a 從P發(fā)出的“Ready”/“Abort”報文丟失 C達到超時，整個事務執(zhí)行“G-abort”。該故障僅能被C識別，此時C認為P故障，但P并無故障，不需執(zhí)行重啟動程序。b “Prepare”報文丟失 P等待，C得不到回答，結果同2.ac

41、“G-commit”/”G-abort”報文丟失 P處于不確定狀態(tài)。回答“Abort”的可以確定其工作，回答“Ready”的不行。此時可以修改加入計時器，超時則申請重發(fā)命令。d “Ack”報文丟失 C超時，可重發(fā)“G-commit”/”G-abort”命令，P無論是否有活動，都重發(fā)“Ack”報文3.2 兩階段提交協(xié)議兩階段提交協(xié)議和故障恢復和故障恢復3 3 兩階段提交協(xié)議兩階段提交協(xié)議3.網絡分割站點假設分成兩組：協(xié)調者組和參與者組。一組是協(xié)調者，一組是參與者。于是從協(xié)調者看是參與者組故障，結果同1.a, 1.b。 從參與者組看是協(xié)調者站點故障，動作如1.c, 1.d。3.2 兩階段提交協(xié)議兩

42、階段提交協(xié)議和故障恢復和故障恢復3 3 兩階段提交協(xié)議兩階段提交協(xié)議初始寫begin_commit到日志等待有要求撤消的？寫commit到日志提交寫Complete到日志初始準備提交？寫ready到日志就緒消息類型？寫abort到日志寫commit到日志提交撤消撤消寫abort到日志寫abort到日志協(xié)調者參與者nonoabortcommit 2. b 準備2.a撤消2.a 提交2.c全局撤消全局提交ACKACK1.c1.d1.e1.a1.b2.d 多站點數據更新 方法 ：站點A上有事務T對X更新, X在B1,Bn和C1,Cm上有副本, 則也要對這些副本更新 問題 多個站點同時更新不現實(每一

43、個站點某一時刻與站點A連通的概率小于1） 對未連通站點上的副本更新增多時出錯, 更新的順序也不一定是連通順序4.1 多站點數據更新多站點數據更新4 4 分布式數據庫中的數據更新分布式數據庫中的數據更新4.1 多站點數據更新多站點數據更新4 4 分布式數據庫中的數據更新分布式數據庫中的數據更新站點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暫時未連通。 主文本更新 思想：指定主副本, 修改只對主副本進行, 修改輔助副本時, 也按在主

44、副本上執(zhí)行的更新順序執(zhí)行 問題 修改傳播必須在短時間內完成, 否則將獲得“過時”數據 主副本不可用, 引得其他副本也不可用4.2 主文本更新主文本更新4 4 分布式數據庫中的數據更新分布式數據庫中的數據更新4.2 主文本更新主文本更新4 4 分布式數據庫中的數據更新分布式數據庫中的數據更新網絡網絡站點AX主文本站點B2X輔文本站點B1X輔文本站點B3X輔文本站點B5X輔文本站點B4X輔文本T1T2未未連連通通T1在在T2之前之前 移動主文本法 若初次更新在輔文本上進行，然后再把更新引向該數據的主站點 如果主站點此時尚未連通，則另選一個輔站點中的輔文本為該數據新的主文本進行更新 待原主文本站點連

45、通后，系統(tǒng)將自動把它改為輔文本，并按記錄要求執(zhí)行更新 如果初次更新在主文本上進行，但主文本站點與網絡未接通，則此次更新操作失敗，事務被撤銷，因為無法傳播更新 移動文本法的問題 網絡分割成很多部分時，更新處理會不一致 網絡分割成W1,W2，W1中X更新為R, W2中X更新為S,網絡連通時，使用R還是S來恢復X呢？4.2 主文本更新主文本更新4 4 分布式數據庫中的數據更新分布式數據庫中的數據更新 快照(Snapshot) 與視圖相似, 是導出的關系 快照的數據是實際存放在數據庫中的，視圖不是 周期地更新 用于某些需要“凍結”數據的應用 4.3 快照方法快照方法4 4 分布式數據庫中的數據更新分布

46、式數據庫中的數據更新 例子 Define Snapshot HP-Book as SELECT * FROM Book WHERE Price$100 REFRESH Every day 特點 快照不考慮數據的輔助副本, 只關心主文本和這個主本上定義的多個快照 快照與視圖一樣可以定義為一個或多個主副本的部分或全部 快照可以完成復雜的查詢, 但又不阻止更新 查詢操作可使用快照，也可使用主文本，對更新操作還是在主文本上進行4.3 快照方法快照方法4 4 分布式數據庫中的數據更新分布式數據庫中的數據更新 業(yè)務規(guī)則約束 有效性約束: 域約束，數據項的取值范圍 數據依賴約束: 實體完整性和引用完整性 例

47、子 取現金時 一個賬戶的存款余額必須大于零 轉賬時 一個賬戶的存款余額必須大于零. 事務結束時,兩賬戶中存款總和, 必須與事務開始時兩賬戶存款之和相同 定期利息計算 事務執(zhí)行后, 所有賬戶存款之和比事務開始前各賬戶存款總和大于10%（假定利息是總額的10%）5.1 業(yè)務規(guī)則的一致性業(yè)務規(guī)則的一致性5 5 分布式事務增強數據庫一致性分布式事務增強數據庫一致性 業(yè)務規(guī)則要強制執(zhí)行 用戶編寫的事務中 由DBMS事務優(yōu)化器產生的事務中 在產生的分布式執(zhí)行方案中，要編入業(yè)務規(guī)則的強制條件 或者從數據字典中獲取相關的業(yè)務規(guī)則，并在生產分布式事務的時候使用它 多數商用分布式DBMS的事務優(yōu)化器，只加入少數幾類業(yè)務規(guī)則，為了補救這種不足，需要 程序員必