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