1、分布式事務概述 分布式事務的恢復 兩階段提交協(xié)議 分布式數(shù)據(jù)庫中的數(shù)據(jù)更新 分布式事務增強數(shù)據(jù)庫一致性,分布式數(shù)據(jù)庫中的事務管理和恢復,1,事務概念,事務是訪問或更新各種數(shù)據(jù)項的最小邏輯工作單位。 它是一個操作序列 它可以使數(shù)據(jù)庫從一個一致狀態(tài)到另外一個一致狀態(tài) 事務必須保證數(shù)據(jù)庫的一致性 事務執(zhí)行期間數(shù)據(jù)庫可能不一致,2,當事務提交（commit）時數(shù)據(jù)庫必須是一致的,事務T開始,事務T結束,事務T的執(zhí)行,數(shù)據(jù)庫一致,數(shù)據(jù)庫一致,數(shù)據(jù)庫可能臨時不一致,事務概念,3,分布式事務,集中式 事務和操作數(shù)據(jù)在一個站點上 不存在傳輸費用 分布式 操作數(shù)據(jù)分布在不同的站點上 事務也在多個站點上執(zhí)行 分布

2、式事務是集中式事務的擴充 站點和通信連路故障都可能導致錯誤發(fā)生 分布式事務的恢復要比集中式事務復雜的多,4,事務分類: 全局事務 通常由一個主事務和在不同站點上執(zhí)行的子事務組成 主事務：負責事務的開始、提交和異常終止 子事務：完成對相應站點上的數(shù)據(jù)庫的訪問操作 局部事務 僅訪問或更新一個站點上的數(shù)據(jù)的事務,分布式數(shù)據(jù)庫中的事務,5,ACID特性 原子性（Atomicity） 事務的操作要么全部執(zhí)行, 要么全部不執(zhí)行 ,保證數(shù)據(jù)庫一致性狀態(tài) 一致性（Consistency） 事務的正確性，串行性，并發(fā)執(zhí)行的多個事務,其操作的結果應與以某種順序串行執(zhí)行這幾個事務所得的結果相同. 持久性（Durab

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

4、te(B),分布式事務特性舉例,8,一致性要求: 事務執(zhí)行后A 和 B賬號的總金額不變 原子性要求: 如果事物在第3步和第6步之間故障, 系統(tǒng)應該保證事務對數(shù)據(jù)庫的修改沒有產(chǎn)生,否則將導致不一致性,分布式事務特性舉例,9,持久性要求: 一旦用戶通知說事務已經(jīng)完成（即$50 轉賬成功），那么由該事務對數(shù)據(jù)庫的修改就必須保證是永久的，即使是發(fā)生故障也如此,分布式事務特性舉例,10,獨立性要求 如果在第 3步和第6步之間, 允許其他事務訪問被修改的數(shù)據(jù)庫的中間結果, 那么它將見到一個不一致的數(shù)據(jù)庫 (也就是說， A + B 的和少于它的正確值） 當然事務的串行執(zhí)行將不會出現(xiàn)這種情況，但是數(shù)據(jù)庫中事務

5、并行執(zhí)行的優(yōu)點就損失了,分布式事務特性舉例,11,Begin Transaction原語：開始一個事務 T1 T2 : 子事務或操作序列 : Tn Commit原語：事務成功完成的結束 Rollback或Abort原語：事務失敗的結束,分布式事務的一般結構,12,活動 從事務開始執(zhí)行的初始狀態(tài)始， 事務執(zhí)行中保持該狀態(tài) 部分提交 事務的最后一個語句執(zhí)行后進入該狀態(tài). 失敗 一旦發(fā)現(xiàn)事務不能正常執(zhí)行時進入該狀態(tài) 夭折 當事務被回滾后，數(shù)據(jù)庫恢復到事務開始執(zhí)行前的狀態(tài)。 事務夭折后有兩種選擇 重啟動 僅當沒有內部邏輯錯誤時 殺死 提交 當事務成功執(zhí)行后.,分布式事務的狀態(tài),13,分布式事務的狀態(tài),

6、14,進程：系統(tǒng)中可以并行執(zhí)行的一段操作序列，分布式事務中的子事務序列是進程方式完成的 進程說明：定義進程的行為模式，數(shù)據(jù)和數(shù)據(jù)上的操作，功能等 進行執(zhí)行：按模式來啟動這個進程，執(zhí)行其中的操作 過程：不可并行執(zhí)行的操作序列 事務代理（Agent）：應用在各個Site上執(zhí)行的若干進程，稱作應用在該Site上的代理。代理可以執(zhí)行應用程序員寫的程序，也可以執(zhí)行系統(tǒng)的原語函數(shù)，不同代理間通過報文實現(xiàn)通訊 根代理（Root Agent） 應用啟動Site上的代理。根代理所在的Site稱作原發(fā)Site. 一般，根代理負責發(fā)系統(tǒng)原語，只有根代理可以請求創(chuàng)建新代理。,進程相關定義,15,為了協(xié)調執(zhí)行分布式應用

7、的全局操作，分駐于不同站點的諸事務代理必須進行協(xié)調，有如下規(guī)定： 每一應用都有一個負責啟動整個事務的總代理（或稱根代理） 只有總代理才能發(fā)出全局有效的事務開始、提交和撤消原語 只有總代理才能請求建立新的事務代理 各站點上的子事務都執(zhí)行成功，總代理才能決定提交該事務，否則總代理將決定撤銷該事務,進程協(xié)作,16,轉賬應用,事務在兩個賬戶之間執(zhí)行“基金匯兌”操作。 如果匯兌的金額小于轉出帳號現(xiàn)有金額，就撤銷 如果大于等于就提交 全局關系 Account (Account-number, Amount) 假設賬戶分布在網(wǎng)絡的不同站點上。,17,全局級轉帳事務 FUND_TRANSFER: read (

8、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 abort else begin update ACCOUNT set AMOUNT = AMOUNT-$AMOUNT where ACCOUNT_NUMBER = $FROM_ACC; update ACCOUNT set AMOUNT = AMOUNT-$AMOUNT

9、where ACCOUNT_NUMBER = $TO_ACC; commit end,18,輸入：匯出金額和轉入/轉出帳號,事務開始：檢查轉出帳號中是否 有足夠的轉出資金？,更新轉出帳號存款余額 創(chuàng)建AGENT1 向代理1送消息：轉入帳號，金額,等待來自AGENT1的消息,成功？,提交事務：成功結束,撤消事務：失敗結束,ROOT_AGENT,AGENT,接收來自根代理的信息,更新轉入帳號存款余額,發(fā)送執(zhí)行消息給根代理 (成功或失敗),是,否,否,轉賬應用處理流程,19,ROOT_AGENT; read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC); begin_tra

10、nsaction; select AMOUNT into $FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC; if $FROM_AMOUNT-$AMOUNT0 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 f

11、rom ROOT_AGENT($AMOUNT,$TO_ACC); update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT=$TO_ACC; send to ROOT_AGENT(SUCCESS/FALL),轉賬事務的兩個代理,20,分布式事務管理問題,處理數(shù)據(jù)項的多個副本 分布式事務處理負責保持同一數(shù)據(jù)的多個副本之間的一致性。當某個副本所在站點發(fā)生故障時，負責生成與該數(shù)據(jù)其他副本一致的拷貝，以便于及時恢復。 單個站點的故障 一個站點或多個站點故障時，DDBMS繼續(xù)與其他正常運行的站點一起繼續(xù)工作 當故障站點恢復時， DDBMS協(xié)同故障站點的

12、DBMS，必須使得該站點與系統(tǒng)連接時，局部數(shù)據(jù)庫與其他站點同步 通信網(wǎng)絡的故障 必須能夠處理兩個或者多個站點間的通信網(wǎng)絡故障 分布式提交 如果提交分布式事務過程中有一個站點發(fā)生故障，提交就會產(chǎn)生問題 兩階段提交協(xié)議用于解決這一問題,21,分布式事務管理目標,目的：事務能有效、可靠、并發(fā)的執(zhí)行 除了策略之外，效率的幾個重要方面 CPU和主存的使用 控制報文 響應時間 可用性 目標 維護事務的ACID性質 獲得最小的主存和CPU開銷，降低報文數(shù)目，加快響應時間 獲得最大限度的可靠性和可用性,22,抽象模型,LTM: Local Transaction Manager DTM: Distribute

13、d Transaction Manager,本地事務管理器 LTM1,本地事務管理器 LTM2,本地事務管理器 LTMn,分布式事務管理器 DTM1,分布式事務管理器 DTM2,分布式事務管理器 DTMn,站點 n,站點 2,站點 1,23,事務管理,DTM功能 保證分布式事務ACID特性， 特別是原子性，使每一站點的子事務都成功執(zhí)行，或者都不執(zhí)行。 通過向各站點發(fā)begin-transaction,commit或者abort,create原語來實現(xiàn)的 負責協(xié)調由該站點發(fā)出的所有分布式事務的執(zhí)行 啟動分布式事務的執(zhí)行 將分布式事務分解為子事務，并將其分派到恰當?shù)恼军c上執(zhí)行 決定分布式事務的終止

14、（子事務都提交或者都撤銷） 支持分布式事務執(zhí)行位置透明性 實現(xiàn)了對網(wǎng)絡上各站點的各子事務的監(jiān)督和管理 完成對整個分布式事務執(zhí)行過程的調度和管理 保證分布式數(shù)據(jù)庫系統(tǒng)的高效率,Log原語： Local Begin-Trans, Local-Commit, Local-Abort,24,事務管理,LTM功能 保證本地事務的ACID特性 維護一個用于恢復的日志，代替DTM把分布事務的執(zhí)行與恢復信息記入日志 參與適當?shù)牟l(fā)控制模式，以協(xié)調在該站點上執(zhí)行的事務的并發(fā)執(zhí)行。接收并遵從本Site上DTM發(fā)來的Log原語，記入Log并執(zhí)行之,Log原語： Local Begin-Trans, Local-Co

15、mmit, Local-Abort,25,分布式事務執(zhí)行的控制模型,是指協(xié)調分布式事務中各成員DBMS執(zhí)行其子事務的通用方法，有三種: 主從模型：主、從控制器，LTM之間無通信 三角模型：LTM之間可以傳遞數(shù)據(jù)，避免了主從之間不必要的傳輸 層次控制模型：LTM還可再創(chuàng)建Agent，控制其它LTM執(zhí)行，比前兩種復雜,26,分布式事務 管理器,局部事務 管理器,局部事務 管理器,局部事務 管理器,數(shù)據(jù)庫,數(shù)據(jù)庫,數(shù)據(jù)庫,命令,命令,命令,回答,回答,回答,主從控制模型,27,分布式事務 管理器,局部事務 管理器,局部事務 管理器,數(shù)據(jù)庫,數(shù)據(jù)庫,命令,命令,回答,回答,臨時數(shù)據(jù),三角控制模型,28

16、,層次控制模型,29,故障類型 事務故障 由非預期的、不正常的程序結束所造成的故障，即事務沒有執(zhí)行到Commit或顯示Rollback語句的故障，如：計算溢出、完整性破壞、操作員干預、輸入輸出錯誤、死循環(huán)等） 處理方法：內存、磁盤上信息沒有損失，使用Log做Rollback 系統(tǒng)故障 造成系統(tǒng)停止運行的任何事件，要求系統(tǒng)重啟動，如CPU出錯、緩沖區(qū)滿、系統(tǒng)崩潰等 處理方法：內存、I/O Buffer內容皆丟失，DB沒有破壞，恢復時，搜索Log, 確定Rollback的事務。,30,介質故障： 輔助存儲器介質遭破壞 處理方法：如數(shù)據(jù)丟失, 日志無損失，從某個Dump狀態(tài)開始執(zhí)行已提交事務；數(shù)據(jù)與

17、日志都丟失 不可能完全恢復 以上三種可以統(tǒng)稱為站點故障.,31,通訊故障 報文故障 報文錯 報文失序 報文丟失 報文延遲 網(wǎng)絡分割故障（網(wǎng)絡斷連） 通訊發(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) 網(wǎng)絡分割, 即網(wǎng)絡不通,32,問題可以進一步分為: a) 是否是所在Site故障

18、, 還是系統(tǒng)響應過慢，還是網(wǎng)絡流量過大 b) 若是故障, 是通訊故障, 還是 y 站點故障? c) 如果是報文故障，是報文丟失還是應答丟失 對上述故障, 其恢復程序可以有不同級別: 一級: 僅處理Site故障 二級: Site故障及Message故障 三級: Site故障及Message故障, 還包括網(wǎng)絡分割,33,事務恢復 當發(fā)生故障時，保證事務原子性的措施稱為事務故障恢復，簡稱事務恢復 主要依靠日志來實現(xiàn) 事務狀態(tài)轉移跟蹤（操作） Begin_transaction：標記事務開始執(zhí)行 Read & write：表示事務對某個數(shù)據(jù)項進行讀寫 End_transaction：表示讀寫操作已完成

19、，標記事務執(zhí)行結束 Commit_transaction：表示事務已經(jīng)成功結束，任何改變已不可更改 Rollback (abort)：表示事務沒有成功結束，撤銷事務對數(shù)據(jù)庫所作的任何改變,34,35,事務的提交點 當事務T所有的站點數(shù)據(jù)庫存取操作都已成功執(zhí)行； 所有操作對數(shù)據(jù)庫的影響都已記錄在日志中。到達提交點 提交點后事務就成為已提交的事務，并假定其結果以永久記錄在數(shù)據(jù)庫中 事務在日志中寫入提交記錄commit,T 在系統(tǒng)發(fā)生故障時，需要掃描日志，檢查日志中寫入start_transaction,T,但沒有寫入commit,T的所有事務T 恢復時必須回滾這些事務以取消他們對數(shù)據(jù)庫的影響 此外

20、，還必須對日志中記錄的已提交子事務的所有寫操作進行恢復。,36,事務的提交點相關操作 日志文件保存到磁盤上 一般先將文件的相關塊，從磁盤拷貝到主存的緩沖區(qū)，然后更新，再寫回磁盤 緩沖區(qū)中會經(jīng)常存在一個或多個日志文件塊，寫滿后一次性寫回磁盤 系統(tǒng)崩潰時，主存中的信息會丟失，這些信息無法利用 因此，事務到達提交點之前，未寫到磁盤的日志必須寫入，稱為事務提交前強制寫日志。,37,日志 Log：記錄所有對DB的操作 事務標識：每個事務給定一個具有惟一性的標識符 Log記錄項 : start_transaction, T, write_item, T, x, 舊值, 新值 read_item, T, x

21、 commit, T abort, T 寫動作：寫Log比寫數(shù)據(jù)優(yōu)先 Log存儲：一般存在盤上, 還會定期備份到磁帶上,38,Log舉例,Log Write Output A = 950 B = 2050 C = 600 BB, BA BC 注: BX 表示含有X的存儲塊.,39,數(shù)據(jù)訪問,40,檔案庫 一天要產(chǎn)生大量的Log Log劃分為兩部分 一部分是當前活動的聯(lián)機部分，存儲在磁盤上 另一部分是檔案存儲部分，存儲在磁帶上,41,日志 緩沖區(qū),數(shù)據(jù)庫 緩沖區(qū) (易變數(shù)據(jù)庫),局部恢復 管理器,數(shù)據(jù)庫緩沖區(qū) 管理器,主存,取出,讀/寫,讀/寫,日志 檔案庫,DB 檔案庫,穩(wěn)定 日志,穩(wěn)定 DB

22、,讀/寫,讀/寫,數(shù)據(jù)庫、日志和檔案庫的存儲模式,42,檢查點（Checkpoint） 設置一個周期性（時間/容量）操作點 a) Log Buffer內容寫入Log數(shù)據(jù)集 b) 寫檢查點Log信息：當前活動事務表, 每個事務最近一次Log記錄在Log文件中的位置 c) DB Buffer內容寫入DB d) 將本次檢查點Log項在Log文件中的地址記入“重啟動文件”,43,事務本身也會發(fā)生故障，也是主要通過日志來實現(xiàn)恢復 恢復原則 孤立和逐步退出事務的原則 undo 事務已對DB的修改 ( 不影響其他事務的可排除性局部故障，如事務操作的刪除、超時、違反完整性原則、資源、限制和死鎖等) 成功結束事

23、務原則 Redo 已成功事務的操作 夭折事務原則 撤銷全部事務, 恢復到初態(tài)，兩種做法：利用數(shù)據(jù)備份和Undo,44,本地事務恢復 (與集中式恢復相同) 從“重啟動文件” 讀出最近Checkpoint的地址, 并定出Checkpoint在Log文件中的位置 創(chuàng)建Redo表（初態(tài)為空）, Undo表(即Checkpoint相應內容中的活動事務表) 檢查得出Undo事務（向前檢索，遇到begin transaction的log記錄，其對應的事務）與Redo事務（向前檢索，遇到commit的log記錄，其對應事務） 反向檢索Log, 將Undo表中事務, 按log記錄的操作，做Undo，直到遇到對應

24、的Begin Trans 正向檢索Redo事務的Log記錄, 并執(zhí)行之, 直到對應的Commit記錄,45,重啟動文件,UNDO,REDO,活動事務表,故障 發(fā)生,地址,c0,c1,(1),(3),(5),(2),(4),日志數(shù)據(jù)集,利用日志進行事務恢復的過程,46,Checkpoints 舉例,T1 可以忽略 (因為有檢查點，更新已經(jīng)被寫入磁盤) T2 和 T3 redo. T4 undo,47,分布式事務恢復參考模型,Root Agent,Agent,Agent,DTM- Agent,站點1的 LTM,DTM- Agent,DTM- Agent,站點2的 LTM,站點n的 LTM,全局事務

25、,分布式事務管理器(DTM),局部事務 管理器 (LTM),48,分布式事務模型 底層：本地事務管理層，LTM之間不需要進行聯(lián)系，執(zhí)行上層DTM代理發(fā)來的原語，實現(xiàn)接口1 Local begin, local commit, local abort, local create 中間層：分布式事務管理層，一組互相交換報文的本地DTM組成，實現(xiàn)接口2 Begin transaction, commit, abort, create 頂層：全局事務層，由總代理和其他代理組成，只有它與中間層聯(lián)系,49,. . Begin Transaction . . Create Agent1 Send to Ag

26、ent1,. Local-begin . Send Create Req,Write Begin -transaction in Local Log,Root Agent,DTM-Agent,LTM,Receive.,Local Create Local-begin,. Write Begin -transaction in Local Log,LTM,DTM-Agent,Agent1,1,3,2,4,5,6,7,8,分布式事務執(zhí)行和恢復舉例,50,基本思想 將本地原子性提交行為的效果擴展到分布式事務, 保證了分布式事務提交的原子性, 并在不損壞Log的情況下, 實現(xiàn)快速故障恢復, 提高DDB

27、系統(tǒng)的可靠性. 第一階段：表決階段 第二階段：執(zhí)行階段 兩類代理 協(xié)調者(Coordinator)：提交和撤銷事務的決定權，一般是總代理 參與者(Participants)：負責在本地數(shù)據(jù)庫中執(zhí)行寫操作，并且向協(xié)調者提出提交和撤銷子事務的意向,51,2PC中協(xié)調者和參與者的關系,52,表決階段 目的是形成一個共同的決定 首先，協(xié)調者給所有參與者發(fā)送“準備”消息，進入等待狀態(tài) 其次，參與者收到“準備”消息后，檢查是否能夠提交本地事務 如能，給協(xié)調者發(fā)送“建議提交”消息,進入就緒狀態(tài) 如不能，給協(xié)調者發(fā)送“建議撤銷”消息，可以單方面撤銷 第三，協(xié)調者收到所有參與者的消息后，他就做出是否提交事務的決

28、定， 只要有一個參與者投了反對票，就決定撤銷整個事務，發(fā)送“全局撤銷”消息給所有參與者，進入撤銷狀態(tài) 否則，就決定提交整個事務，發(fā)送“全局提交”消息給所有參與者，進入提交狀態(tài) 執(zhí)行階段 實現(xiàn)表決階段的決定，提交或者撤銷,53,初始,寫begin_commit到日志,等待,有要求撤消的？,寫commit到日志,提交,寫end_of_transt到日志,初始,準備提交？,寫ready到日志,就緒,消息類型？,寫abort到日志,寫commit到日志,提交,撤消,撤消,寫abort到日志,寫abort到日志,協(xié)調者,參與者,no,no,abort,commit,準備,撤消,提交,全局撤消,全局提交,

29、ACK,ACK,兩階段提交協(xié)議的活動,54,2PC協(xié)議的重要特點 允許參與者單方面撤銷事務 一旦參與者確定了提交或撤銷協(xié)議，它就不能再更改它的提議 當參與者處于就緒狀態(tài)時，根據(jù)協(xié)調者發(fā)出的消息種類，它可以轉換為提交狀態(tài)或者撤銷狀態(tài) 協(xié)調者根據(jù)全局提交規(guī)則做出全局終止決定 協(xié)調者和參與者可能進入互相等待對方消息的狀態(tài)，使用定時器，保證退出消息等待狀態(tài),55,集中式 通訊只發(fā)生在協(xié)調者和參與者之間，參與者之間不交換信息 分層式 協(xié)調者是在樹根的DTM代理者，協(xié)調者與參與者之間的通訊不用直接廣播的方法進行，而是使報文在樹中上下傳播。每個DTM代理是通信樹的一個內部節(jié)點，它從下層節(jié)點處收集報文或向它們

30、廣播報文。 線性 參與者之間可以互相通信。系統(tǒng)中的站點間要排序，消息串行傳遞。支持沒有廣播功能的網(wǎng)絡 分布式 允許所有參與者在第一階段相互通信，從而可以獨立做出事務終止決定。,56,2,3,4,5,1,2,3,4,5,1,1,協(xié)調者,參與者,協(xié)調者,協(xié)調者,參與者,第一階段,第二階段,準備,建議撤消/提交,全局撤消/提交,提交/撤消,集中式,57,3,4,2,5,1,5,1,1,協(xié)調者,參 與 者,協(xié)調者,協(xié)調者,參 與 者,第一階段,第二階段,準備,建議撤消/提交,全局撤消/提交,提交/撤消,2,3,4,2,2,分層式,58,1,2,3,4,n,第一階段,第二階段,準備,建議提交/撤消,建議

31、提交/撤消,建議提交/撤消,全局提交/撤消,全局提交/撤消,全局提交/撤消,全局提交/撤消,線性式,59,1,n,4,3,2,4,3,2,1,n,協(xié)調者,協(xié)調者,協(xié)調者+參與者,第一階段,準備,建議撤消/提交,全局撤消/提交 可獨立做決定,分布式,60,站點故障 a 參與者在將“Ready”記錄入Log之前故障 此時協(xié)調者(C)達到超時，Abort發(fā)生。站點（P）恢復時，重啟動程序將執(zhí)行Abort，不必從其他站點獲取信息。 b 當將“Ready”寫入Log后，站點故障 此時所有運行的站點都將正常結束事務（Commit/Abort)。P恢復時，因為P已Ready，所以不可判定C的最終決定。因此恢

32、復時，重啟動程序要詢問C或其他站點。 c 當C將“Prepare”寫入Log，但“G-commit”/”G-abort”還沒有寫入前故障 所有回答“Ready”的P等待C恢復。C重啟動時，將重開提交協(xié)議，重發(fā)“Prepare”，于是P要識別重發(fā)。 d C在將“G-commit”/”G-abort”寫入Log后，“Complete”沒有寫入前故障 收到命令的P正常執(zhí)行，C重啟動程序必須再次向所有P重發(fā)命令。以前沒有收到命令的P也必須等待C恢復，P要識別兩次命令。 e “Complete”寫入Log后故障 無任何動作發(fā)生,61,2. 報文丟失 a 從P發(fā)出的“Ready”/“Abort”報文丟失

33、C達到超時，整個事務執(zhí)行“G-abort”。該故障僅能被C識別，此時C認為P故障，但P并無故障，不需執(zhí)行重啟動程序。 b “Prepare”報文丟失 P等待，C得不到回答，結果同2.a c “G-commit”/”G-abort”報文丟失 P處于不確定狀態(tài)?；卮稹癆bort”的可以確定其工作，回答“Ready”的不行。此時可以修改加入計時器，超時則申請重發(fā)命令。 d “Ack”報文丟失 C超時，可重發(fā)“G-commit”/”G-abort”命令，P無論是否有活動，都重發(fā)“Ack”報文,62,網(wǎng)絡分割 站點假設分成兩組：協(xié)調者組和參與者組。 一組是協(xié)調者，一組是參與者。于是從協(xié)調者看是參與者組故

34、障，結果同1.a, 1.b。 從參與者組看是協(xié)調者站點故障，動作如1.c, 1.d。,63,初始,寫begin_commit到日志,等待,有要求撤消的？,寫commit到日志,提交,寫Complete到日志,初始,準備提交？,寫ready到日志,就緒,消息類型？,寫abort到日志,寫commit到日志,提交,撤消,撤消,寫abort到日志,寫abort到日志,協(xié)調者,參與者,no,no,abort,commit,2. b 準備,2.a撤消,2.a 提交,2.c全局撤消,全局提交,ACK,ACK,1.c,1.d,1.e,1.a,1.b,2.d,64,多站點數(shù)據(jù)更新 方法 ：站點A上有事務T對X

35、更新, X在B1,Bn和C1,Cm上有副本, 則也要對這些副本更新 問題 多個站點同時更新不現(xiàn)實(每一個站點某一時刻與站點A連通的概率小于1） 對未連通站點上的副本更新增多時出錯, 更新的順序也不一定是連通順序,65,66,主文本更新 思想：指定主副本, 修改只對主副本進行, 修改輔助副本時, 也按在主副本上執(zhí)行的更新順序執(zhí)行 問題 修改傳播必須在短時間內完成, 否則將獲得“過時”數(shù)據(jù) 主副本不可用, 引得其他副本也不可用,67,未連通,T1在T2之前,68,移動主文本法 若初次更新在輔文本上進行，然后再把更新引向該數(shù)據(jù)的主站點 如果主站點此時尚未連通，則另選一個輔站點中的輔文本為該數(shù)據(jù)新的主

36、文本進行更新 待原主文本站點連通后，系統(tǒng)將自動把它改為輔文本，并按記錄要求執(zhí)行更新 如果初次更新在主文本上進行，但主文本站點與網(wǎng)絡未接通，則此次更新操作失敗，事務被撤銷，因為無法傳播更新 移動文本法的問題 網(wǎng)絡分割成很多部分時，更新處理會不一致 網(wǎng)絡分割成W1,W2，W1中X更新為R, W2中X更新為S,網(wǎng)絡連通時，使用R還是S來恢復X呢？,69,業(yè)務規(guī)則約束 有效性約束: 域約束，數(shù)據(jù)項的取值范圍 數(shù)據(jù)依賴約束: 實體完整性和引用完整性 例子 取現(xiàn)金時 一個賬戶的存款余額必須大于零 轉賬時 一個賬戶的存款余額必須大于零. 事務結束時,兩賬戶中存款總和, 必須與事務開始時兩賬戶存款之和相同 定期利息計算 事務執(zhí)行后, 所有賬戶存款之和比事務開始前各賬戶存款總和大于10%（假定利息是總額的10%）,70,業(yè)務規(guī)則要強制執(zhí)行 用戶編寫的事務中 由DBMS事務優(yōu)化器產(chǎn)生的事務中 在產(chǎn)生的分布式執(zhí)行方案中，要編入業(yè)務規(guī)則的強制條件 或者從數(shù)據(jù)字典中獲取相關的業(yè)務規(guī)則，并在生產(chǎn)分布式事務的時候使用它 多數(shù)商用分布式DBMS的事務優(yōu)化器，只加入少數(shù)幾類業(yè)務規(guī)則，為了補救這種不足，需要 程序員必須編