分布式事務
分布式事務處理，兩端提交協議
klose
隨著網路環境的日益普及，新的應用呈現出許多相似的特點那就是開放性和分布性。對於internet商業應用來說分布性和開放性更是最基本的要求，並且隨著人們對電子商務、安全防範等複雜的web應用需求的增加，web應用不僅僅是對唯讀資訊的訪問，面向商業活動的讀取將迅速增加。這意味著，從簡單的資料系統全球聯網查詢，逐步轉向更具有分布式資料庫系統特色的應用環境。
我們知道，研究分布式資料庫系統的目的、動機主要是組織目標，即為應用所驅動。開放性、分布性不僅是當前新應用的要求，也同樣是分布式資料庫系統的優勢所在。可以預料在當前的網路、分布、開放的大環境下，分布式資料庫系統將會有更加長足的發展和應用。
第三章 分布式事務
分布式資料庫通過兩種策略:分布式事務和資料複製，保持各種資料副本的 一致性。資料複製主要用於更新多個伺服器上的大量資料。除此之外，還需要在本地的資料庫伺服器之間更新若干表。這時所需更新的資料量不是很大，因此決定採 用分布式事務處理的方法來解決。當乙個伺服器上的資料進行修改時，為了保證資料的一致性，需要引起其它伺服器上的資料隨之更新，這就要用到分布事務(distributed transaction)的概念，並且要採用分布式的事務處理方法。
3．1分布式事務處理
為了更好的說明分布式事務處理的機制，首先介紹一下事務的概念。首先討論一下分布式事務，分布式事務用兩階段提交協議保證事務的原子性。兩階段提交協議中，各結點採取的是完全同步的方法來保證資料庫的一致性。
3．1．1事務的概念
事務作為資料庫的重要概念，是併發控制的基本單位[10]。所謂「事務」是一系列有單個使用者或應用程式提交的資料庫操作，這些操作是乙個不可分隔的整體。
3．1．2事務具有四個特性
原子性(atomicity)，即一事務的操作要麼全部執行，要麼全部不執行。當事務非正常終止時，其中間結果將被取消。
一致性(consistency)，又叫可序列性。併發執行的幾個事務，其操作的結果應與以某種次序序列執行它們的結果相同，因此稱為可序列性。這種可序列化的併發排程是由資料庫系統的併發控制機制來完成，以保證併發事務執行時資料庫狀態一致，所以這種性質也稱為事務的一致性。
隔離性(isolation)，乙個未完成事務不能在提交前就把其中間結果提供給其它事務使用。
耐久性(durability)，乙個事務正常結束即提交後其操作的結果將永久化且與提交後發生的故障無關。
事務的acid屬性[11]對開發可靠的分布式應用起著重要的作用。可序列性和隔離性主要涉及到多個事務對資料庫進行訪問操作時的併發控制機制;而原子性和永續性更是為了保證資料庫狀態一致，特別是在出現故障後仍能恢復到前乙個資料庫一致狀態，所以涉及到恢復機制。
3．2分布式事務管理
在分布式資料庫系統中，分布式事務管理的目的在於保證事務的正確執行及執行結果的有效性，主要解決系統可靠性、事務併發控制及系統資源的有效利用等問題。
在分布式資料庫中對各種資料項的訪問常常通過事務來完成，乙個事務可能要訪問分布儲存在多個站點上的資料，該事務將被劃分成多個子事務，每個子事務負責對乙個資料儲存站點進行訪問。在分布式資料庫中把事務分為兩種型別:區域性事務和全域性事務。區域性事務是那些僅訪問和更新乙個區域性資料庫中資料的事務：全域性事務是那些訪問和更新多個區域性資料庫中資料的事務。
3．3分布式事務的恢復
分布式資料庫系統中，各個場地除了可能發生如同集中式資料庫的那些故障外，還會出現通訊時資訊丟失、傳送延時、線路中斷等事故。因此，情況比集中式資料庫更複雜，相應的恢復過程也就複雜些。
為了執行分布事務，通常在每個場地都有乙個區域性事務管理器，用來管理區域性子事務的執行，保證事務的完整性，並且各區域性事務管理器之間必須相互協調，保證所有場地對它們所處理的子事務採取相同的策略：確保要麼執行，要麼回滾[12]。確保這一策略的常用技術是兩段提交協議(2-phase-commitment protocol)簡稱2pc。
3．3．1兩段提交協議2pc
兩段提交協議把乙個分布事務的事務管理分為兩類:乙個是協調者，所有其他的是參與者。協調者負責做出最後的提交或夭折決定。參與者負責本地子事務的動作。2pc的基本思想是為全部參與者做出關於提交或夭折全部本地子事務的唯一決定。如果其中有乙個參與者不能本地提交其子事務，則全部參與者必須本地天折。此協議有兩階段組成，第一階段的目的是達到一共同的決定，第二階段的目的是實現這個決定。協議的原理如下[13]：
採用兩段提交協議後，當系統發生故障時，各場地利用各自相關的日誌資訊便可執行恢復操作[14]。針對站點故障、丟失報文及網路分割等常見故障的恢復操作過程描述如下：
1．站點故障
(1)當參與者在寫入「準備提交」前發生故障時，該參與者無法向協調者發回答資訊，因此當協調者等待超時後，將決定天折事務。當該故障恢復後，重啟動過程無須收集其它站點的資訊即可夭折事務。
(2)參與者在寫入「準備提交」後發生故障，這時其它的參與者可以正常 的結束該事務「提交」或「天折」，因為協調者可以根據收到的應答決定「提交」或「天折」。因此，故障恢復後，重啟動過程要訪問協調者或參與者，以了解事務 己做出的決定，然後執行相應的操作。這裡我們假設在日誌中寫入「準備提交」記錄和傳送「準備提交」資訊給協調者這兩個動作具有原子性。
(3)協調者在日誌中寫入「預提交」記錄後，寫入「全部提交」或「全部夭折」前發生故障，這時己發出「準備提交」的參與者將等待協調者恢復。協調者的重啟動過程從頭恢復提交協議，從「預提交」記錄中讀出參與者的標誌符，重發「預提交」報文給參與者，重新執行提交過程。
(4)協調者在寫入「全部提交」或「全部夭折」記錄後，在寫入「事務結束」記錄前發生故障。在這種情況下，協調者恢復時必須給所有的參與者重發其決定，未收到資訊的參與者不得不等待協調者的恢復。和(3)一樣，參與者不應因收到兩次一樣的命令而受影響。
(5)協調者在日誌中寫入「事務結束」記錄後發生故障，這種情況下事務己結束，不需恢復處理。
2.丟失報文
(1)來自參與者的回答報文(「準備提交」或「夭折」)至少丟失乙個。在這種情況下，協調者將等待回答而超時，整個事務被夭折。但它無法決定是站點故障還是通訊故障，而參與者正確執行，它不會啟動恢復過程。
(2)丟失「預提交」報文，由於至少乙個參與者收不到「預提交」命令，因此參與者處於等待狀態，而協調者也等待參與者的回答，所以協調者會因為等待超時而夭折事務。
(3)丟失「提交」或「天折」報文，這種情況下參與者處於等待協調者命令的狀態下，當未收到命令時會因等待而超時，這時向協調者發請求重發該命令的資訊。
(4)丟失了「己執行」報文，當協調者未收到全部的「己執行」報文時，協調者會因等待而超時，這時協調者重發命令報文給參與者，這時參與者必須給予「執行」報文回答，即使此時相應的子事務己不在活動也要重發。
3.網路分割
假設在出現網路分割時，整個網路分為兩個組，包含協調者的組稱為協調者組，其它的則組成參與者組。這種情況對於協調者來說相當於參與者組中的多個參 與者同時發生故障，這時協調者可以做出決定，然後把命令發給協調者組中的參與者，因此這些站點上的子事務可以結束。這與站點故障中的(1)和(2)兩種情況類似。對於參與者失去聯絡，這時它們認為出現故障。這種情況與站點故障中的(3)和(4)相似。
3．3．2三階段提交協議3pc
在基本的2pc協議中，當參與者等待協調者的回答時，可能因為網路故障或協調者故障使之收不到回答資訊而出現等待超時，這時事務進入等待狀態。當故障一直持續時，則事務就一直處於阻塞狀態，因此降低了整個系統的可用性。為此，我們引入了3pc協議，這是一種非阻塞提交協議[15]。這裡所說的非阻塞的提交協議只是相對一定的故障模型，到目前為止還沒有一種協議可以完全避免阻塞，但是我們可以通過一定的處理減少阻塞。
在2pc協議中，參與者的提交是在它知道了其它所有的參與者均發生了「準備提交」的報文後進行的。若在2pc中增加一階段使得參與者的提交不僅要等到它知道所有的參與者均發出了「準備提交」的報文，而且還知道所有參與者的狀態(如：故障狀態或已經恢復)以後才執行。這時2pc變成3pc協議。在3pc協 議中，報文有三次接收和傳送，協調者第二次向參與者發出的報文不是「提交報文」，而是提交前的預備報文，告訴所有的參與者均可以自己做出決定或夭折或提 交，而不必因等待協調者惡意問答而進入阻塞狀態，因為即使此時發生故障，系統的恢復機制遲早也要恢復故障前的一刻，即個參與者的子事務都要提交，因此，參 與者可以自行決定先執行下去而不是處於等待狀態，從而減少了阻塞。
3pc可以避免阻塞是基於一定的故障模型的。一般來說，在下列故障出現時3pc不會進入阻塞狀態:
(1)只允許出現場地故障而不會出現網路分隔的情況。
(2)場地故障但不影響通訊功能，即它仍能進行正常的收發工作且資訊是正確的。
(3)場地故障使得系統必須進行恢復處理，恢復機制應能知道已發生過故障且其它場地進行通訊，了解故障前的情況是參與者恢復到提交狀態中去。
(4)場地五故障時必須在超時以前向曾求助於它的場地發回答報文。
(5)網路不會丟失報文且場地間傳送報文的次序和接收報文的次序一樣。
3．4小結
本章主要討論了分布式事務的概念，分布式事務提交，並具體分析了兩階段提交協議(2pc)中針對站點故障、丟失報文及網路分割等常見故障等常見故障的恢復操作做了介紹。最後引入了三階段提交協議(3pc)。
分布式事務處理，兩端提交協議 ZZ
from 隨著網路環境的日益普及，新的應用呈現出許多相似的特點那就是開放性和分布性。對於internet商業應用來說分布性和開放性更是最基本的要求，並且隨著人們對電子商務 安全防範等複雜的web應用需求的增加，web應用不僅僅是對唯讀資訊的訪問，面向商業活動的讀取將迅速增加。這意味著，從簡單的資料系...
分布式事務處理
前提如下 db a,db b為兩個資料庫 都有乙個person表 該錶兩個字段 personid 主鍵 和personname 下面的分布式事務 實現的是 同時向這兩個庫的兩個表新增資料 set xact abort on 開始分布式事務 begin distributed transaction ...
分布式事務處理
場景 a資料庫有乙個人叫小明，b資料庫有乙個人叫小花，現在小明要給小花轉賬100，那麼就有兩個操作，小明賬戶 100，小 花賬戶 100，由於是跨資料庫，事務在此時沒用，那該如何保證兩人賬戶資料的準確。方案一 兩次提交，設計理念 在同乙個資料庫中，我們可以使用事務來保證資料的原子性。現在我們有兩個資...