分佈式數據庫管理系統

時間 2019-11-24

原文原文鏈接

分佈式數據庫管理系統的發展

單個數據庫分割成多個，而後把這些分割存放到同一網絡中的不一樣計算機中。多點數據庫是分佈式數據庫系統的核心。業務分佈在不一樣的國家和地區須要分佈式數據庫管理系統。分佈式數據庫系統的複雜性對於終端用戶來講是透明的。分佈式數據庫管理系統把分佈式數據庫當作單個邏輯的數據庫。分佈式數據庫管理系統（distributed database management system, DDBMS）管理在相關計算機系統中邏輯相關的數據存儲和處理，在這個系統中，數據存儲和處理都是分佈在不一樣的地方。集中式數據庫的使用須要公司把數據庫存儲到一個地方，一般這個地方是主機。複雜的分佈式數據環境將增長標準協議的緊迫性，須要用這些協議來管理事物處理、併發控制、安全性、備份、恢復、查詢優化、訪問路徑的選擇等。算法

分佈式處理（distributed processing）過程當中，數據庫處理過程在邏輯上分佈到兩個或者兩個以上的物理獨立位置上，並且這些位置能夠經過網絡鏈接。分佈式數據庫（distributed database）能夠把邏輯相關的數據庫存儲兩個或者兩個以上的物理位置上。在一個分佈式數據庫系統中，數據庫由許多部分組成，稱之爲數據庫分割（database fragments）。數據庫

注意：安全

分佈式處理不是須要一個分佈式數據庫，而分佈式數據庫須要分佈式處理（其局域的數據庫處理負責管理每一個數據庫分割）。
分佈式處理可能基於單個數據庫，而且該數據庫也是存放在一臺計算機上。因爲分佈式數據的產生，數據處理功能的副本必須分佈到全部的數據存儲位置上。
分佈式處理和分佈式數據庫都須要經過一個網絡來鏈接全部的計算機。

分佈式處理服務器

分佈式數據庫管理系統的特徵

DBMS至少有如下功能纔算得上是分佈式的：網絡

在分佈式數據庫中，應用層的接口必須鏈接終端用戶、應用程序和其餘DBMS。
對數據進行分析、驗證語法的正確性。
把複雜的請求轉化成簡單的數據請求。
爲了找到最好的訪問路徑，須要進行查詢優化（若是操做同步，那麼必須知道查詢訪問哪一個數據庫部件，怎麼更新數據？）。
映射本地和遠程分割的數據位置圖。
I/O接口能夠從永久的本地存儲中讀或者寫數據。
調整數據的格式後提交給終端用戶或應用程序。
確保本地和遠程數據庫的數據安全。
發生故障時，爲了確保數據庫的有效性和可恢復性，必須進行備份和恢復。
DBA具備數據庫管理的功能。
在DDBMS中，爲了管理同時訪問的數據，而且確保在數據庫部件中數據的一致性，必須進行進行併發控制。
爲了確保數據從一個一致性狀態中轉換到另外一個一致性狀態，必須進行相應的事務管理，包括本地和遠程事務的同步。

分佈式數據庫管理系統必須執行集中式DBMS的全部功能：架構

接受應用層（終端用戶）的請求。
驗證、分析、分解請求。這些請求可能包含數學的或者邏輯的操做，例如，選擇全部餘額超過1000的客戶。它可能從一個表中獲得數據，也可能須要訪問多個表。
把請求的邏輯數據映射到物理數據。
把請求分解到磁盤I/O操做中。
查找、定位、讀取、驗證數據。
確保數據庫的一致性、安全性和完整性。
根據條件驗證數據。
根據要求保留已有的數據。

另外，DDBMS必須完成全部分佈式數據的處理，而且對於終端用戶來講，執行這些功能是透明的。併發

數據層和分佈式處理

單點處理與單點數據

在單點處理與單點數據（single-site processing, single-site data, SPSD）狀況下，全部的處理都在一臺主機中進行（單處理服務器、多處理服務器、主機系統），而且全部數據都存儲在主機的本地磁盤系統中。處理不能在終端用戶的系統中執行。app

多點處理與單點數據

在多點處理與單點數據（multiple-site processing, multiple-site data, MPSD）狀況下，在共享單個數據倉庫的狀況下，由不一樣的計算機來處理數據。一般MPSD須要一個網絡文件服務器，這個服務器能夠經過網絡來訪問傳統的應用程序。分佈式

多點處理與多點數據

多點處理與多點數據（multiple-site processing, multiple-site data, MPMD）是一個完整的分佈式DBMS，它支持多點的數據處理和事務處理。根據集中式DBMS的不一樣類型，能夠把DBMS分爲同構和異構的。函數

同構DDBMS（homogeneous DDBMS）在網絡上僅集成一種集中式DBMS。相比之下，異構DDBMS（heterogeneous DDBMS）在網絡上集成多種集中式DBMS。全異構DDBMS（fully heterogeneous DDBMS）支持不一樣的DMBS，而這些DBMS可能支持不一樣的數據模型（關係、層次或者網絡）。這些模型都在不一樣的計算機系統中運行，如主機和PC。

分佈式數據庫的透明性

分佈透明性（distribution transparency），把分佈式數據庫當作單一的邏輯數據庫。

若是一個DDBMS呈現出分佈透明性，那麼用戶不須要知道：

數據的分割，即縱向和橫向地把表的行和列分割開而且存儲在多個地方。
數據能夠被複制到多個地方。
數據的位置。

事務處理透明性（transaction transparency），運行一個事務在多個地方更新數據。

故障透明性（failure transparency），它保證了系統在一個節點上發生故障時，也能繼續運行。因爲故障，丟失的功能將能夠從其餘網絡節點中找到。

性能透明性（performance transparency），是指系統的運行就像是一個集中式DBMS同樣。

異構透明性（heterogeneity transparency），在通用或全局模型下，異構透明性容許集成多個不一樣的本地DBMS（關係、網絡和層次）。

事務處理透明性

事務透明性是DDBMS的一個特徵，它使數據庫事務保持分佈式數據庫的完整性和一致性。請記住，一個DDBMS數據庫事務更新存儲在網絡中相連的不一樣計算機的數據。事務處理透明性確保在全部數據庫站點的事務處理都完成時，整個事務的處理纔算完成。

爲了管理事務而且確保數據庫的一致性和完整性，分佈式數據庫系統須要複雜的機制。爲了理解如何管理事務，應當知道管理遠程請求、遠程事務、分佈式事務和分佈式請求等基本概念。

分佈式請求和分佈式事務

一個事務是否時分佈式的，主要看它是一個仍是多個數據庫請求。非分佈式事務與分佈式事務之間最基本的區別是，後者能夠更新或者請求網上許多不一樣的遠程數據。

分佈式請求

分佈式事務

遠程事務的特徵：

事務會更新站點上的表
遠程事務會發送到站點上，並在站點上運行
每一個事務之能夠引用一個遠程DP
每一個SQL語句在一個時間內只能夠引用一個遠程DP，而且整個事務只能有一個遠程DP引用和運行

分佈式事務的特徵：

事務引用了兩個遠程站點
在不一樣的站點上處理不一樣的請求
在同一時候，每一個請求只能訪問一個遠程站點

不能從一個遠程站點訪問數據，所以DBMS必須支持分佈式請求。

分佈式請求容許一個SQL語句能夠在多個不一樣本地或者遠程DP站點引用數據。由於每一個請求（SQL語句）均可以從一個本地或者遠程DP站點中訪問數據，一個事務能夠訪問多個站點。

事務透明性把分佈式事務處理當作是集中式事務，這樣能夠確保事務的可串行化。也就是說不論併發事務的執行是不是分佈式的，都是將數據庫從一個一致性狀態帶到另外一個一致性的狀態。

分佈式併發控制

併發控制在分佈式數據庫環境中相當重要，由於多站點，多處理器操做比單點系統更可能產生數據的不一致和事務死鎖。例如，在最後的COMMIT執行完而且記錄事務以前，一個DDBMS的TP組件必須確保事務的全部分割都必須在全部站點上執行完。

假設每一個本地DP都提交每一個事務操做，可是其中有一個DP未提交事務的結果：事務將產生不一致數據庫，不可避免出現完整性問題，由於該提交的數據未能提交。爲了解決這個方法，會學習下面的兩階段提交協議。

兩階段提交協議

集中式數據庫僅須要一個DP。全部的數據庫操做僅發生在一個站點上，而且DBMS能夠很快地知道數據庫操做的結果。而分佈式數據庫使得事務可以訪問在多個站點的數據。全部的站點都已經執行完它們的事務後才能夠提交最後的COMMIT。兩階段的提交協議（two-phase commit protocol）能夠保證數據庫狀態的一致性：若是一個事務的一部分操做未能提交，那麼對參與事務的其餘站點的修改都取消。

每一個DP都有本身的事務日誌。兩階段提交協議須要在實際更新數據庫部分以前，對每一個DP記錄事務日誌。所以兩階段提交協議須要一個DO-UNDO-REDO協議和先寫協議。

根據系統事務的日誌，DP用DO-UNDO-REDO協議去會滾或前滾事務。DO-UNDO-REDO協議定義了3中類型的操做：

DO執行操做而且在事務日誌中記錄"以前"和"以後"的值。
根據DO的日誌記錄，UNDO取消操做。
根據DO的日誌記錄，REDO重作操做。

爲了保證DO、UNDO和REDO在系統崩潰中也能發揮做用，當在執行DO、UNDO、REDO操做時，就必須使用先寫協議（write-ahead protocol）。在實際的操做發生時，先寫協議就把日誌寫入永久存儲器中。

兩階段提交協議定義了兩種類型的節點之間的操做：協調器（coordinator）和一個或多個從屬者（subordinate）。參與節點使用的是同一個協調器。一般，協調器的做用是指定開始事務的節點。可是，不一樣系統實現了不一樣並且複雜的選舉方法。協議是分兩階段來實現。

第一階段：準備

協調器發送一個PREPARE TO COMMIT信息給全部的從屬者。

從屬者接到這個信息，使用先寫協議，寫入事務日誌併發送一個確認信息（YES/PREPARED TO COMMIT或NO/NO PREPARED）給協調器。
協調器確保全部節點要麼提交，要麼取消。

若是全部節點爲PREPARED TO COMMIT，事務調轉到第二階段。若是有一個或多個節點爲NO或NO PREPARED協調器就給全部從屬者發送一個ABORT。

第二階段：最後的提交

協調器廣播一個COMMIT信息給全部從屬者並等待回覆。
每一個從屬者接收到COMMIT信息而且使用DO協議更性數據庫。
從屬者回復一個 COMMITTED或者NOT COMMITTED信息給協調器。

若是一個或者多個從屬者沒有提交，協調器就發送一個ABORT消息，這樣就使它們都取消全部的操做。

兩階段提交的目的是爲了確保每一個節點都提交事務本身所操做的部分；不然，事務就取消。若是其中一個節點提交失敗，就用事務日誌來恢復數據庫的信息，並且使用的是DO-UNDO-REDO協議來恢復（記住使用先寫協議更新日誌信息）。

分佈式數據庫的設計

數據分割

水平分割
垂直分割
混合分割

數據複製

數據複製（data replication）是指經過計算機網絡把數據存儲複製到多個站點上。爲了知足特殊的信息需求，分割副本能夠存儲到多個站點上。由於分割副本的存在可以加強數據的可用性和響應時間，數據複製還能夠減小通訊和查詢時間。

數據放置

關於分佈式事務、兩階段提交協議、三階提交協議

隨着大型網站的各類高併發訪問、海量數據處理等場景愈來愈多，如何實現網站的高可用、易伸縮、可擴展、安全等目標就顯得愈來愈重要。

爲了解決這樣一系列問題，大型網站的架構也在不斷髮展。提升大型網站的高可用架構，不得不提的就是分佈式。在《分佈式系統的一致性探討》一文中主要介紹了分佈式系統中存在的一致性問題。本文將簡單介紹如何有效的解決分佈式的一致性問題，其中包括什麼是分佈式事務，二階段提交和三階段提交。

分佈式一致性回顧

在分佈式系統中，爲了保證數據的高可用，一般咱們會將數據保留多個副本（replica），這些副本會放置在不一樣的物理的機器上。爲了對用戶提供正確的增、刪、改、查等語義，咱們須要保證這些放置在不一樣物理機器上的副本是一致的。

爲了解決這種分佈式一致性問題，前人在性能和數據一致性的反反覆覆權衡過程當中總結了許多典型的協議和算法。其中比較著名的有二階提交協議（Two Phase Commitment Protocol）、三階提交協議（Two Phase Commitment Protocol）和Paxos算法。

分佈式事務

分佈式事務是指會涉及到操做多個數據庫的事務。其實就是將對同一庫事務的概念擴大到了對多個庫的事務。目的是爲了保證分佈式系統中的數據一致性。分佈式事務處理的關鍵是必須有一種方法能夠知道事務在任何地方所作的全部動做，提交或回滾事務的決定必須產生一致的結果（所有提交或所有回滾）

在分佈式系統中，各個節點之間在物理上相互獨立，經過網絡進行溝通和協調。因爲存在事務機制，能夠保證每一個獨立節點上的數據操做能夠知足ACID。可是，相互獨立的節點之間沒法準確的知道其餘節點中的事務執行狀況。因此從理論上講，兩臺機器理論上沒法達到一致的狀態。若是想讓分佈式部署的多臺機器中的數據保持一致性，那麼就要保證在全部節點的數據寫操做，要不所有都執行，要麼所有的都不執行。可是，一臺機器在執行本地事務的時候沒法知道其餘機器中的本地事務的執行結果。因此它也就不知道本次事務到底應該commit仍是 rollback。因此，常規的解決辦法就是引入一個"協調者"的組件來統一調度全部分佈式節點的執行。

XA規範

X/Open 組織（即如今的 Open Group）定義了分佈式事務處理模型。 X/Open DTP 模型（ 1994）包括應用程序（AP）、事務管理器（TM）、資源管理器（RM）、通訊資源管理器（CRM）四部分。通常，常見的事務管理器（TM）是交易中間件，常見的資源管理器（RM）是數據庫，常見的通訊資源管理器（CRM）是消息中間件。一般把一個數據庫內部的事務處理，如對多個表的操做，做爲本地事務看待。數據庫的事務處理對象是本地事務，而分佈式事務處理的對象是全局事務。所謂全局事務，是指分佈式事務處理環境中，多個數據庫可能須要共同完成一個工做，這個工做便是一個全局事務，例如，一個事務中可能更新幾個不一樣的數據庫。對數據庫的操做發生在系統的各處但必須所有被提交或回滾。此時一個數據庫對本身內部所作操做的提交不只依賴自己操做是否成功，還要依賴與全局事務相關的其它數據庫的操做是否成功，若是任一數據庫的任一操做失敗，則參與此事務的全部數據庫所作的全部操做都必須回滾。通常狀況下，某一數據庫沒法知道其它數據庫在作什麼，所以，在一個 DTP 環境中，交易中間件是必需的，由它通知和協調相關數據庫的提交或回滾。而一個數據庫只將其本身所作的操做（可恢復）影射到全局事務中。

XA 就是 X/Open DTP 定義的交易中間件與數據庫之間的接口規範（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。 XA 接口函數由數據庫廠商提供。

二階提交協議和三階提交協議就是根據這一思想衍生出來的。能夠說二階段提交其實就是實現XA分佈式事務的關鍵（確切地說：兩階段提交主要保證了分佈式事務的原子性：即全部結點要麼全作要麼全不作）

2PC

二階段提交（Two Phase Commit）是指，在計算機網絡以及數據庫領域內，爲了使基於分佈式系統架構下的全部節點在進行事務提交時保持一致性而設計的一種算法。一般，二階段提交也被稱爲是一種協議（Protocol）。在分佈式系統中，每一個節點雖然能夠知曉本身的操做時成功或者失敗，卻沒法知道其餘節點的操做的成功或失敗。當一個事務跨越多個節點時，爲了保持事務的ACID特性，須要引入一個做爲協調者的組件來統一掌控全部節點（稱做參與者）的操做結果並最終指示這些節點是否要把操做結果進行真正的提交（好比將更新後的數據寫入磁盤等等）。所以，二階段提交的算法思路能夠歸納爲：參與者將操做成敗通知協調者，再由協調者根據全部參與者的反饋情報決定各參與者是否要提交操做仍是停止操做。

所謂的兩個階段是指：第一階段：準備階段（投票階段）和第二階段：提交階段（執行階段）。

準備階段

事務協調者（事務管理器）給每一個參與者（資源管理器）發送Prepare消息，每一個參與者要麼直接返回失敗（如權限驗證失敗），要麼在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種"萬事俱備，只欠東風"的狀態。

能夠進一步將準備階段分爲如下三個步驟：

協調者節點向全部參與者節點詢問是否能夠執行提交操做（vote），並開始等待各參與者節點的響應。
參與者節點執行詢問發起爲止的全部事務操做，並將undo信息和redo信息寫入日誌。（注意：若成功這裏其實每一個參與者已經執行了事務操做）
各參與者節點響應協調者節點發起的詢問。若是參與者節點的事務操做實際執行成功，則它返回一個"贊成"消息；若是參與者節點的事務操做實際執行失敗，則它返回一個"停止"消息。

提交階段

若是協調者收到了參與者的失敗消息或者超時，直接給每一個參與者發送回滾（rollback）消息；不然，發送提交（commit）消息；參與者根據協調者的指令執行提交或者回滾操做，釋放全部事務處理過程當中使用的鎖資源。（注意：必須在最後階段釋放鎖資源）

接下來分兩種狀況分別討論提交階段的過程。

當協調者節點從全部參與者節點得到的相應消息都爲"贊成"時：

協調者節點向全部參與者節點發出"正式提交（commit）"的請求。
參與者節點正式完成操做，並釋放在整個事務期間內佔用的資源。
參與者節點向協調者節點發送"完成"消息。
協調者節點受到全部參與者節點反饋的"完成"消息後，完成事務。

若是任一參與者節點在第一階段返回的響應消息爲"停止"，或者協調者節點在第一階段的詢問超時以前沒法獲取全部參與者節點的響應消息時：

協調者節點向全部參與者節點發出"回滾操做（rollback）"的請求。
參與者節點利用以前寫入的undo信息執行回滾，並釋放在整個事務期間內佔用的資源。
參與者節點向協調者節點發送」回滾完成」消息。
協調者節點受到全部參與者節點反饋的"回滾完成"消息後，取消事務。

無論最後結果如何，第二階段都會結束當前事務。

二階段提交看起來確實可以提供原子性的操做，可是不幸的事，二階段提交仍是有幾個缺點的：

同步阻塞問題。執行過程當中，全部參與節點都是事務阻塞型的。當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態。
單點故障。因爲協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤爲在第二階段，協調者發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。（若是是協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）
數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中協調者發生了故障，這回致使只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據不一致性的現象。
二階段沒法解決的問題：協調者在發出commit消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了。那麼即便協調者經過選舉協議產生了新的協調者，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。

因爲二階段提交存在着諸如同步阻塞、單點問題、腦裂等缺陷，因此，研究者們在二階段提交的基礎上作了改進，提出了三階段提交。

3PC

三階段提交（Three Phase Commit），也叫三階段提交協議（Three Phase Commit Protocol），是二階段提交（2PC）的改進版本。

與兩階段提交不一樣的是，三階段提交有兩個改動點。

引入超時機制。同時在協調者和參與者中都引入超時機制。
在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。

（引入XA規範和2PC、3PC講的很好。可是上面這段話的第2條，在第一階段和第二階段中插入一個準備階段？這麼說不容易讓人理解，原本2pc就是準備階段+提交階段。再插入一個準備階段成什麼了，很容易讓人誤解。但願做者改正。建議：將準備階段拆分並在請求以前增長了一個狀態確認階段。

提問：3PC的canCommit，參與者進入預備狀態後這個預備狀態能夠理解爲事務已經開啓了麼？）

也就是說，除了引入超時機制以外，3PC把2PC的準備階段再次一分爲二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

CanCommit階段

3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者若是能夠提交就返回Yes響應，不然返回No響應。

1.事務詢問協調者向參與者發送CanCommit請求。詢問是否能夠執行事務提交操做。而後開始等待參與者的響應。

2.響應反饋參與者接到CanCommit請求以後，正常狀況下，若是其自身認爲能夠順利執行事務，則返回Yes響應，並進入預備狀態。不然反饋No

PreCommit階段

協調者根據參與者的反應狀況來決定是否能夠進行事務的PreCommit操做。根據響應狀況，有如下兩種可能。

假如協調者從全部的參與者得到的反饋都是Yes響應，那麼就會執行事務的預執行。

1. 發送預提交請求協調者向參與者發送PreCommit請求，並進入Prepared階段。

2. 事務預提交參與者接收到PreCommit請求後，會執行事務操做，並將undo和redo信息記錄到事務日誌中。

3. 響應反饋若是參與者成功的執行了事務操做，則返回ACK響應，同時開始等待最終指令。

假若有任何一個參與者向協調者發送了No響應，或者等待超時以後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。

1.發送中斷請求協調者向全部參與者發送abort請求。

2.中斷事務參與者收到來自協調者的abort請求以後（或超時以後，仍未收到協調者的請求），執行事務的中斷。

doCommit階段

該階段進行真正的事務提交，也能夠分爲如下兩種狀況。

執行提交

1. 發送提交請求協調接收到參與者發送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向全部參與者發送doCommit請求。

2. 事務提交參與者接收到doCommit請求以後，執行正式的事務提交。並在完成事務提交以後釋放全部事務資源。

3. 響應反饋事務提交完以後，向協調者發送Ack響應。

4. 完成事務協調者接收到全部參與者的ack響應以後，完成事務。

中斷事務協調者沒有接收到參與者發送的ACK響應（多是接受者發送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。

1.發送中斷請求協調者向全部參與者發送abort請求

2.事務回滾參與者接收到abort請求以後，利用其在階段二記錄的undo信息來執行事務的回滾操做，並在完成回滾以後釋放全部的事務資源。

3.反饋結果參與者完成事務回滾以後，向協調者發送ACK消息

4.中斷事務協調者接收到參與者反饋的ACK消息以後，執行事務的中斷。

在doCommit階段，若是參與者沒法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時以後，會繼續進行事務的提交。（其實這個應該是基於機率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那麼協調者產生PreCommit請求的前提條件是他在第二階段開始以前，收到全部參與者的CanCommit響應都是Yes。（一旦參與者收到了PreCommit，意味他知道你們其實都贊成修改了）因此，一句話歸納就是，當進入第三階段時，因爲網絡超時等緣由，雖然參與者沒有收到commit或者abort響應，可是他有理由相信：成功提交的概率很大。）

2PC與3PC的區別

相對於2PC，3PC主要解決的單點故障問題，並減小阻塞，由於一旦參與者沒法及時收到來自協調者的信息以後，他會默認執行commit。而不會一直持有事務資源並處於阻塞狀態。可是這種機制也會致使數據一致性問題，由於，因爲網絡緣由，協調者發送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時以後執行了commit操做。這樣就和其餘接到abort命令並執行回滾的參與者之間存在數據不一致的狀況。

瞭解了2PC和3PC以後，咱們能夠發現，不管是二階段提交仍是三階段提交都沒法完全解決分佈式的一致性問題。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算法。