分布式数据库管理系统
分布式數(shù)據(jù)庫管理系統(tǒng)的發(fā)展
單個數(shù)據(jù)庫分割成多個，然后把這些分割存放到同一網(wǎng)絡(luò)中的不同計算機中。多點數(shù)據(jù)庫是分布式數(shù)據(jù)庫系統(tǒng)的核心。業(yè)務(wù)分布在不同的國家和地區(qū)需要分布式數(shù)據(jù)庫管理系統(tǒng)。分布式數(shù)據(jù)庫系統(tǒng)的復(fù)雜性對于終端用戶來說是透明的。分布式數(shù)據(jù)庫管理系統(tǒng)把分布式數(shù)據(jù)庫看成單個邏輯的數(shù)據(jù)庫。分布式數(shù)據(jù)庫管理系統(tǒng)（distributed database management system, DDBMS）管理在相關(guān)計算機系統(tǒng)中邏輯相關(guān)的數(shù)據(jù)存儲和處理，在這個系統(tǒng)中，數(shù)據(jù)存儲和處理都是分布在不同的地方。集中式數(shù)據(jù)庫的使用需要公司把數(shù)據(jù)庫存儲到一個地方，通常這個地方是主機。復(fù)雜的分布式數(shù)據(jù)環(huán)境將增加標(biāo)準(zhǔn)協(xié)議的緊迫性，需要用這些協(xié)議來管理事物處理、并發(fā)控制、安全性、備份、恢復(fù)、查詢優(yōu)化、訪問路徑的選擇等。
?
?
?
?
分布式處理（distributed processing）過程中，數(shù)據(jù)庫處理過程在邏輯上分布到兩個或者兩個以上的物理獨立位置上，而且這些位置可以通過網(wǎng)絡(luò)連接。分布式數(shù)據(jù)庫（distributed database）可以把邏輯相關(guān)的數(shù)據(jù)庫存儲兩個或者兩個以上的物理位置上。在一個分布式數(shù)據(jù)庫系統(tǒng)中，數(shù)據(jù)庫由許多部分組成，稱之為數(shù)據(jù)庫分割（database fragments）。
注意：
?
分布式處理
分布式數(shù)據(jù)庫管理系統(tǒng)的特征
DBMS至少有以下功能才算得上是分布式的：
分布式數(shù)據(jù)庫管理系統(tǒng)必須執(zhí)行集中式DBMS的所有功能：
另外，DDBMS必須完成所有分布式數(shù)據(jù)的處理，并且對于終端用戶來說，執(zhí)行這些功能是透明的。
數(shù)據(jù)層和分布式處理
單點處理與單點數(shù)據(jù)
在單點處理與單點數(shù)據(jù)（single-site processing, single-site data, SPSD）情況下，所有的處理都在一臺主機中進行（單處理服務(wù)器、多處理服務(wù)器、主機系統(tǒng)），并且所有數(shù)據(jù)都存儲在主機的本地磁盤系統(tǒng)中。處理不能在終端用戶的系統(tǒng)中執(zhí)行。
多點處理與單點數(shù)據(jù)
在多點處理與單點數(shù)據(jù)（multiple-site processing, multiple-site data, MPSD）情況下，在共享單個數(shù)據(jù)倉庫的情況下，由不同的計算機來處理數(shù)據(jù)。通常MPSD需要一個網(wǎng)絡(luò)文件服務(wù)器，這個服務(wù)器可以通過網(wǎng)絡(luò)來訪問傳統(tǒng)的應(yīng)用程序。
多點處理與多點數(shù)據(jù)
多點處理與多點數(shù)據(jù)（multiple-site processing, multiple-site data, MPMD）是一個完整的分布式DBMS，它支持多點的數(shù)據(jù)處理和事務(wù)處理。根據(jù)集中式DBMS的不同類型，可以把DBMS分為同構(gòu)和異構(gòu)的。
同構(gòu)DDBMS（homogeneous DDBMS）在網(wǎng)絡(luò)上僅集成一種集中式DBMS。相比之下，異構(gòu)DDBMS（heterogeneous DDBMS）在網(wǎng)絡(luò)上集成多種集中式DBMS。全異構(gòu)DDBMS（fully heterogeneous DDBMS）支持不同的DMBS，而這些DBMS可能支持不同的數(shù)據(jù)模型（關(guān)系、層次或者網(wǎng)絡(luò)）。這些模型都在不同的計算機系統(tǒng)中運行，如主機和PC。
分布式數(shù)據(jù)庫的透明性
分布透明性（distribution transparency），把分布式數(shù)據(jù)庫看成單一的邏輯數(shù)據(jù)庫。
如果一個DDBMS呈現(xiàn)出分布透明性，那么用戶不需要知道：
事務(wù)處理透明性（transaction transparency），運行一個事務(wù)在多個地方更新數(shù)據(jù)。
故障透明性（failure transparency），它保證了系統(tǒng)在一個節(jié)點上發(fā)生故障時，也能繼續(xù)運行。由于故障，丟失的功能將可以從其他網(wǎng)絡(luò)節(jié)點中找到。
性能透明性（performance transparency），是指系統(tǒng)的運行就像是一個集中式DBMS一樣。
異構(gòu)透明性（heterogeneity transparency），在通用或全局模型下，異構(gòu)透明性允許集成多個不同的本地DBMS（關(guān)系、網(wǎng)絡(luò)和層次）。
事務(wù)處理透明性
事務(wù)透明性是DDBMS的一個特征，它使數(shù)據(jù)庫事務(wù)保持分布式數(shù)據(jù)庫的完整性和一致性。請記住，一個DDBMS數(shù)據(jù)庫事務(wù)更新存儲在網(wǎng)絡(luò)中相連的不同計算機的數(shù)據(jù)。事務(wù)處理透明性確保在所有數(shù)據(jù)庫站點的事務(wù)處理都完成時，整個事務(wù)的處理才算完成。
為了管理事務(wù)并且確保數(shù)據(jù)庫的一致性和完整性，分布式數(shù)據(jù)庫系統(tǒng)需要復(fù)雜的機制。為了理解如何管理事務(wù)，應(yīng)當(dāng)知道管理遠(yuǎn)程請求、遠(yuǎn)程事務(wù)、分布式事務(wù)和分布式請求等基本概念。
分布式請求和分布式事務(wù)
一個事務(wù)是否時分布式的，主要看它是一個還是多個數(shù)據(jù)庫請求。非分布式事務(wù)與分布式事務(wù)之間最基本的區(qū)別是，后者可以更新或者請求網(wǎng)上許多不同的遠(yuǎn)程數(shù)據(jù)。
分布式請求
分布式事務(wù)
分布式事務(wù)
遠(yuǎn)程事務(wù)的特征：
- 事務(wù)會更新站點上的表
- 遠(yuǎn)程事務(wù)會發(fā)送到站點上，并在站點上運行
- 每個事務(wù)之可以引用一個遠(yuǎn)程DP
- 每個SQL語句在一個時間內(nèi)只可以引用一個遠(yuǎn)程DP，并且整個事務(wù)只能有一個遠(yuǎn)程DP引用和運行
分布式事務(wù)的特征：
- 事務(wù)引用了兩個遠(yuǎn)程站點
- 在不同的站點上處理不同的請求
- 在同一時候，每個請求只能訪問一個遠(yuǎn)程站點
不能從一個遠(yuǎn)程站點訪問數(shù)據(jù)，因此DBMS必須支持分布式請求。
分布式請求允許一個SQL語句可以在多個不同本地或者遠(yuǎn)程DP站點引用數(shù)據(jù)。因為每個請求（SQL語句）都可以從一個本地或者遠(yuǎn)程DP站點中訪問數(shù)據(jù)，一個事務(wù)可以訪問多個站點。
事務(wù)透明性把分布式事務(wù)處理看成是集中式事務(wù)，這樣可以確保事務(wù)的可串行化。也就是說不論并發(fā)事務(wù)的執(zhí)行是否是分布式的，都是將數(shù)據(jù)庫從一個一致性狀態(tài)帶到另一個一致性的狀態(tài)。
分布式并發(fā)控制
并發(fā)控制在分布式數(shù)據(jù)庫環(huán)境中至關(guān)重要，因為多站點，多處理器操作比單點系統(tǒng)更可能產(chǎn)生數(shù)據(jù)的不一致和事務(wù)死鎖。例如，在最后的COMMIT執(zhí)行完并且記錄事務(wù)之前，一個DDBMS的TP組件必須確保事務(wù)的所有分割都必須在所有站點上執(zhí)行完。
假設(shè)每個本地DP都提交每個事務(wù)操作，但是其中有一個DP未提交事務(wù)的結(jié)果：事務(wù)將產(chǎn)生不一致數(shù)據(jù)庫，不可避免出現(xiàn)完整性問題，因為該提交的數(shù)據(jù)未能提交。為了解決這個方法，會學(xué)習(xí)下面的兩階段提交協(xié)議。
兩階段提交協(xié)議
集中式數(shù)據(jù)庫僅需要一個DP。所有的數(shù)據(jù)庫操作僅發(fā)生在一個站點上，并且DBMS可以很快地知道數(shù)據(jù)庫操作的結(jié)果。而分布式數(shù)據(jù)庫使得事務(wù)能夠訪問在多個站點的數(shù)據(jù)。所有的站點都已經(jīng)執(zhí)行完它們的事務(wù)后才可以提交最后的COMMIT。兩階段的提交協(xié)議（two-phase commit protocol）可以保證數(shù)據(jù)庫狀態(tài)的一致性：如果一個事務(wù)的一部分操作未能提交，那么對參與事務(wù)的其他站點的修改都取消。
每個DP都有自己的事務(wù)日志。兩階段提交協(xié)議需要在實際更新數(shù)據(jù)庫部分之前，對每個DP記錄事務(wù)日志。因此兩階段提交協(xié)議需要一個DO-UNDO-REDO協(xié)議和先寫協(xié)議。
?
?
根據(jù)系統(tǒng)事務(wù)的日志，DP用DO-UNDO-REDO協(xié)議去會滾或前滾事務(wù)。DO-UNDO-REDO協(xié)議定義了3中類型的操作：
- DO執(zhí)行操作并且在事務(wù)日志中記錄"之前"和"之后"的值。
- 根據(jù)DO的日志記錄，UNDO取消操作。
- 根據(jù)DO的日志記錄，REDO重做操作。
為了保證DO、UNDO和REDO在系統(tǒng)崩潰中也能發(fā)揮作用，當(dāng)在執(zhí)行DO、UNDO、REDO操作時，就必須使用先寫協(xié)議（write-ahead protocol）。在實際的操作發(fā)生時，先寫協(xié)議就把日志寫入永久存儲器中。
兩階段提交協(xié)議定義了兩種類型的節(jié)點之間的操作：協(xié)調(diào)器（coordinator）和一個或多個從屬者（subordinate）。參與節(jié)點使用的是同一個協(xié)調(diào)器。通常，協(xié)調(diào)器的作用是指定開始事務(wù)的節(jié)點。但是，不同系統(tǒng)實現(xiàn)了不同而且復(fù)雜的選舉方法。協(xié)議是分兩階段來實現(xiàn)。
第一階段：準(zhǔn)備
協(xié)調(diào)器發(fā)送一個PREPARE TO COMMIT信息給所有的從屬者。
如果所有節(jié)點為PREPARED TO COMMIT，事務(wù)調(diào)轉(zhuǎn)到第二階段。如果有一個或多個節(jié)點為NO或NO PREPARED協(xié)調(diào)器就給所有從屬者發(fā)送一個ABORT。
第二階段：最后的提交
如果一個或者多個從屬者沒有提交，協(xié)調(diào)器就發(fā)送一個ABORT消息，這樣就使它們都取消所有的操作。
兩階段提交的目的是為了確保每個節(jié)點都提交事務(wù)自己所操作的部分；否則，事務(wù)就取消。如果其中一個節(jié)點提交失敗，就用事務(wù)日志來恢復(fù)數(shù)據(jù)庫的信息，而且使用的是DO-UNDO-REDO協(xié)議來恢復(fù)（記住使用先寫協(xié)議更新日志信息）。
分布式數(shù)據(jù)庫的設(shè)計
數(shù)據(jù)分割
數(shù)據(jù)復(fù)制
數(shù)據(jù)復(fù)制（data replication）是指通過計算機網(wǎng)絡(luò)把數(shù)據(jù)存儲復(fù)制到多個站點上。為了滿足特殊的信息需求，分割副本可以存儲到多個站點上。因為分割副本的存在能夠增強數(shù)據(jù)的可用性和響應(yīng)時間，數(shù)據(jù)復(fù)制還可以減少通信和查詢時間。
數(shù)據(jù)放置
關(guān)于分布式事務(wù)、兩階段提交協(xié)議、三階提交協(xié)議
隨著大型網(wǎng)站的各種高并發(fā)訪問、海量數(shù)據(jù)處理等場景越來越多，如何實現(xiàn)網(wǎng)站的高可用、易伸縮、可擴展、安全等目標(biāo)就顯得越來越重要。
為了解決這樣一系列問題，大型網(wǎng)站的架構(gòu)也在不斷發(fā)展。提高大型網(wǎng)站的高可用架構(gòu)，不得不提的就是分布式。在《分布式系統(tǒng)的一致性探討》一文中主要介紹了分布式系統(tǒng)中存在的一致性問題。本文將簡單介紹如何有效的解決分布式的一致性問題，其中包括什么是分布式事務(wù)，二階段提交和三階段提交。
分布式一致性回顧
在分布式系統(tǒng)中，為了保證數(shù)據(jù)的高可用，通常我們會將數(shù)據(jù)保留多個副本（replica），這些副本會放置在不同的物理的機器上。為了對用戶提供正確的增、刪、改、查等語義，我們需要保證這些放置在不同物理機器上的副本是一致的。
為了解決這種分布式一致性問題，前人在性能和數(shù)據(jù)一致性的反反復(fù)復(fù)權(quán)衡過程中總結(jié)了許多典型的協(xié)議和算法。其中比較著名的有二階提交協(xié)議（Two Phase Commitment Protocol）、三階提交協(xié)議（Two Phase Commitment Protocol）和Paxos算法。
分布式事務(wù)
分布式事務(wù)是指會涉及到操作多個數(shù)據(jù)庫的事務(wù)。其實就是將對同一庫事務(wù)的概念擴大到了對多個庫的事務(wù)。目的是為了保證分布式系統(tǒng)中的數(shù)據(jù)一致性。分布式事務(wù)處理的關(guān)鍵是必須有一種方法可以知道事務(wù)在任何地方所做的所有動作，提交或回滾事務(wù)的決定必須產(chǎn)生一致的結(jié)果（全部提交或全部回滾）
在分布式系統(tǒng)中，各個節(jié)點之間在物理上相互獨立，通過網(wǎng)絡(luò)進行溝通和協(xié)調(diào)。由于存在事務(wù)機制，可以保證每個獨立節(jié)點上的數(shù)據(jù)操作可以滿足ACID。但是，相互獨立的節(jié)點之間無法準(zhǔn)確的知道其他節(jié)點中的事務(wù)執(zhí)行情況。所以從理論上講，兩臺機器理論上無法達到一致的狀態(tài)。如果想讓分布式部署的多臺機器中的數(shù)據(jù)保持一致性，那么就要保證在所有節(jié)點的數(shù)據(jù)寫操作，要不全部都執(zhí)行，要么全部的都不執(zhí)行。但是，一臺機器在執(zhí)行本地事務(wù)的時候無法知道其他機器中的本地事務(wù)的執(zhí)行結(jié)果。所以它也就不知道本次事務(wù)到底應(yīng)該commit還是 rollback。所以，常規(guī)的解決辦法就是引入一個"協(xié)調(diào)者"的組件來統(tǒng)一調(diào)度所有分布式節(jié)點的執(zhí)行。
XA規(guī)范
X/Open 組織（即現(xiàn)在的 Open Group）定義了分布式事務(wù)處理模型。 X/Open DTP 模型（ 1994）包括應(yīng)用程序（AP）、事務(wù)管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。一般，常見的事務(wù)管理器（TM）是交易中間件，常見的資源管理器（RM）是數(shù)據(jù)庫，常見的通信資源管理器（CRM）是消息中間件。 通常把一個數(shù)據(jù)庫內(nèi)部的事務(wù)處理，如對多個表的操作，作為本地事務(wù)看待。數(shù)據(jù)庫的事務(wù)處理對象是本地事務(wù)，而分布式事務(wù)處理的對象是全局事務(wù)。所謂全局事務(wù)，是指分布式事務(wù)處理環(huán)境中，多個數(shù)據(jù)庫可能需要共同完成一個工作，這個工作即是一個全局事務(wù)，例如，一個事務(wù)中可能更新幾個不同的數(shù)據(jù)庫。對數(shù)據(jù)庫的操作發(fā)生在系統(tǒng)的各處但必須全部被提交或回滾。此時一個數(shù)據(jù)庫對自己內(nèi)部所做操作的提交不僅依賴本身操作是否成功，還要依賴與全局事務(wù)相關(guān)的其它數(shù)據(jù)庫的操作是否成功，如果任一數(shù)據(jù)庫的任一操作失敗，則參與此事務(wù)的所有數(shù)據(jù)庫所做的所有操作都必須回滾。一般情況下，某一數(shù)據(jù)庫無法知道其它數(shù)據(jù)庫在做什么，因此，在一個 DTP 環(huán)境中，交易中間件是必需的，由它通知和協(xié)調(diào)相關(guān)數(shù)據(jù)庫的提交或回滾。而一個數(shù)據(jù)庫只將其自己所做的操作（可恢復(fù)）影射到全局事務(wù)中。
XA 就是 X/Open DTP 定義的交易中間件與數(shù)據(jù)庫之間的接口規(guī)范（即接口函數(shù)），交易中間件用它來通知數(shù)據(jù)庫事務(wù)的開始、結(jié)束以及提交、回滾等。 XA 接口函數(shù)由數(shù)據(jù)庫廠商提供。
二階提交協(xié)議和三階提交協(xié)議就是根據(jù)這一思想衍生出來的。可以說二階段提交其實就是實現(xiàn)XA分布式事務(wù)的關(guān)鍵（確切地說：兩階段提交主要保證了分布式事務(wù)的原子性：即所有結(jié)點要么全做要么全不做）
2PC
二階段提交（Two Phase Commit）是指，在計算機網(wǎng)絡(luò)以及數(shù)據(jù)庫領(lǐng)域內(nèi)，為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點在進行事務(wù)提交時保持一致性而設(shè)計的一種算法。通常，二階段提交也被稱為是一種協(xié)議（Protocol）。在分布式系統(tǒng)中，每個節(jié)點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節(jié)點的操作的成功或失敗。當(dāng)一個事務(wù)跨越多個節(jié)點時，為了保持事務(wù)的ACID特性，需要引入一個作為協(xié)調(diào)者的組件來統(tǒng)一掌控所有節(jié)點（稱作參與者）的操作結(jié)果并最終指示這些節(jié)點是否要把操作結(jié)果進行真正的提交（比如將更新后的數(shù)據(jù)寫入磁盤等等）。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
所謂的兩個階段是指：第一階段：準(zhǔn)備階段（投票階段）和第二階段：提交階段（執(zhí)行階段）。
準(zhǔn)備階段
事務(wù)協(xié)調(diào)者（事務(wù)管理器）給每個參與者（資源管理器）發(fā)送Prepare消息，每個參與者要么直接返回失敗（如權(quán)限驗證失敗），要么在本地執(zhí)行事務(wù)，寫本地的redo和undo日志，但不提交，到達一種"萬事俱備，只欠東風(fēng)"的狀態(tài)。
可以進一步將準(zhǔn)備階段分為以下三個步驟：
提交階段
如果協(xié)調(diào)者收到了參與者的失敗消息或者超時，直接給每個參與者發(fā)送回滾（rollback）消息；否則，發(fā)送提交（commit）消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作，釋放所有事務(wù)處理過程中使用的鎖資源。（注意：必須在最后階段釋放鎖資源）
接下來分兩種情況分別討論提交階段的過程。
當(dāng)協(xié)調(diào)者節(jié)點從所有參與者節(jié)點獲得的相應(yīng)消息都為"同意"時：
如果任一參與者節(jié)點在第一階段返回的響應(yīng)消息為"中止"，或者協(xié)調(diào)者節(jié)點在第一階段的詢問超時之前無法獲取所有參與者節(jié)點的響應(yīng)消息時：
不管最后結(jié)果如何，第二階段都會結(jié)束當(dāng)前事務(wù)。
二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：
由于二階段提交存在著諸如同步阻塞、單點問題、腦裂等缺陷，所以，研究者們在二階段提交的基礎(chǔ)上做了改進，提出了三階段提交。
3PC
三階段提交（Three Phase Commit），也叫三階段提交協(xié)議（Three Phase Commit Protocol），是二階段提交（2PC）的改進版本。
與兩階段提交不同的是，三階段提交有兩個改動點。
（引入XA規(guī)范和2PC、3PC講的很好。但是上面這段話的第2條，在第一階段和第二階段中插入一個準(zhǔn)備階段？這么說不容易讓人理解，本來2pc就是準(zhǔn)備階段+提交階段。再插入一個準(zhǔn)備階段成什么了，很容易讓人誤解。希望作者改正。建議：將準(zhǔn)備階段拆分并在請求之前增加了一個狀態(tài)確認(rèn)階段。
提問：3PC的canCommit，參與者進入預(yù)備狀態(tài)后這個預(yù)備狀態(tài)可以理解為事務(wù)已經(jīng)開啟了么？）
也就是說，除了引入超時機制之外，3PC把2PC的準(zhǔn)備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。
CanCommit階段
3PC的CanCommit階段其實和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。
1.事務(wù)詢問 協(xié)調(diào)者向參與者發(fā)送CanCommit請求。詢問是否可以執(zhí)行事務(wù)提交操作。然后開始等待參與者的響應(yīng)。
2.響應(yīng)反饋 參與者接到CanCommit請求之后，正常情況下，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)，并進入預(yù)備狀態(tài)。否則反饋No
PreCommit階段
協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以進行事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況，有以下兩種可能。
假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會執(zhí)行事務(wù)的預(yù)執(zhí)行。
1. 發(fā)送預(yù)提交請求協(xié)調(diào)者向參與者發(fā)送PreCommit請求，并進入Prepared階段。
2. 事務(wù)預(yù)提交 參與者接收到PreCommit請求后，會執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。
3. 響應(yīng)反饋 如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時開始等待最終指令。
假如有任何一個參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時之后，協(xié)調(diào)者都沒有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷。
1.發(fā)送中斷請求 協(xié)調(diào)者向所有參與者發(fā)送abort請求。
2.中斷事務(wù) 參與者收到來自協(xié)調(diào)者的abort請求之后（或超時之后，仍未收到協(xié)調(diào)者的請求），執(zhí)行事務(wù)的中斷。
doCommit階段
該階段進行真正的事務(wù)提交，也可以分為以下兩種情況。
執(zhí)行提交
1. 發(fā)送提交請求 協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請求。
2. 事務(wù)提交 參與者接收到doCommit請求之后，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放所有事務(wù)資源。
3. 響應(yīng)反饋 事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送Ack響應(yīng)。
4. 完成事務(wù) 協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后，完成事務(wù)。
中斷事務(wù) 協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)，也可能響應(yīng)超時），那么就會執(zhí)行中斷事務(wù)。
1.發(fā)送中斷請求 協(xié)調(diào)者向所有參與者發(fā)送abort請求
2.事務(wù)回滾 參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。
3.反饋結(jié)果 參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息
4.中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷。
在doCommit階段，如果參與者無法及時接收到來自協(xié)調(diào)者的doCommit或者rebort請求時，會在等待超時之后，會繼續(xù)進行事務(wù)的提交。（其實這個應(yīng)該是基于概率來決定的，當(dāng)進入第三階段時，說明參與者在第二階段已經(jīng)收到了PreCommit請求，那么協(xié)調(diào)者產(chǎn)生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應(yīng)都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當(dāng)進入第三階段時，由于網(wǎng)絡(luò)超時等原因，雖然參與者沒有收到commit或者abort響應(yīng)，但是他有理由相信：成功提交的幾率很大。 ）
2PC與3PC的區(qū)別
相對于2PC，3PC主要解決的單點故障問題，并減少阻塞，因為一旦參與者無法及時收到來自協(xié)調(diào)者的信息之后，他會默認(rèn)執(zhí)行commit。而不會一直持有事務(wù)資源并處于阻塞狀態(tài)。但是這種機制也會導(dǎo)致數(shù)據(jù)一致性問題，因為，由于網(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒有及時被參與者接收到，那么參與者在等待超時之后執(zhí)行了commit操作。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。
了解了2PC和3PC之后，我們可以發(fā)現(xiàn)，無論是二階段提交還是三階段提交都無法徹底解決分布式的一致性問題。Google Chubby的作者Mike Burrows說過，"there is only one consensus protocol, and that's Paxos – all other approaches are just broken versions of Paxos."。意即世上只有一種一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。后面的文章會介紹這個公認(rèn)的難以理解但是行之有效的Paxos算法。
參考資料：
分布式協(xié)議之兩階段提交協(xié)議（2PC）和改進三階段提交協(xié)議（3PC）
關(guān)于分布式事務(wù)、兩階段提交、一階段提交、Best Efforts 1PC模式和事務(wù)補償機制的研究
兩階段提交協(xié)議與三階段提交協(xié)議
轉(zhuǎn)載于:https://www.cnblogs.com/tuhooo/p/9070222.html
總結(jié)
以上是生活随笔為你收集整理的分布式数据库管理系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软件架构设计——解释器模式
- 下一篇： windows安装jenkins及ant