轉載至：http://www.cnblogs.com/binyue/p/3678390.html，最近學習需要，先轉載方便用用來強化加深印象

一、分布式數據一致性

在分布式系統中，為了保證數據的高可用，通常會將數據保留多個副本(replica)，這些副本會放置在不同的物理的機器上。

（1）什麽是數據一致性

在數據有多份副本的情況下，如果網絡、服務器或者軟件出現故障，會導致部分副本寫入成功，部分副本寫入失敗。這就造成各個副本之間的數據不一致，數據內容沖突。

造成事實上的數據不一致。

（2）CAP定理

CAP理論認為在分布式的環境下設計和部署系統時，有3個核心的需求：

Consistency，Availability和Partition Tolerance，即CAP。

Availability：可用性，每一個操作總是能夠在一定時間內返回結果。需要註意“一定時間”和“返回結果”。“一定時間”是指，系統結果必須在給定時間內返回。“返回結果”是指系統返回操作成功或失敗的結果。

Partition Tolerance：分區容忍性，是否可以對數據進行分區。這是考慮到性能和可伸縮性。

（3）數據一致性模型

一些分布式系統通過復制數據來提高系統的可靠性和容錯性，並且將數據的不同的副本存放在不同的機器。

強一致性：
當更新操作完成之後，任何多個後續進程或者線程的訪問都會返回最新的更新過的值。這種是對用戶最友好的，就是用戶上一次寫什麽，下一次就保證能讀到什麽。根據 CAP 理論，這種實現需要犧牲可用性。

弱一致性：
系統並不保證續進程或者線程的訪問都會返回最新的更新過的值。用戶讀到某一操作對系統特定數據的更新需要一段時間，我們稱這段時間為“不一致性窗口”。系統在數據寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之後可以讀到。

最終一致性：
是弱一致性的一種特例。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操作的值。在沒有故障發生的前提下，不一致窗口的時間主要受通信延遲，系統負載和復制副本的個數影響。DNS 是一個典型的最終一致性系統。

二、典型的分布式事務實例

跨行轉賬問題是一個典型的分布式事務，用戶A向B的一個轉賬1000，要進行A的余額-1000，B的余額+1000，顯然必須保證這兩個操作的事務性。
類似的還有，電商系統中，當有用戶下單後，除了在訂單表插入記，還要在商品表更新庫存等，特別是隨著微服務架構的流行，分布式事務的場景更變得更普遍。

三、兩階段提交協議

兩階段提交協議是協調所有分布式原子事務參與者，並決定提交或取消（回滾）的分布式算法。
（1）協議參與者

在兩階段提交協議中，系統一般包含兩類機器（或節點）：一類為協調者（coordinator），通常一個系統中只有一個；另一類為事務參與者（participants，cohorts或workers），一般包含多個，在數據存儲系統中可以理解為數據副本的個數。協議中假設每個節點都會記錄寫前日誌（write-ahead log）並持久性存儲，即使節點發生故障日誌也不會丟失。協議中同時假設節點不會發生永久性故障而且任意兩個節點都可以互相通信。

（2）兩個階段的執行

1.請求階段（commit-request phase，或稱表決階段，voting phase）
在請求階段，協調者將通知事務參與者準備提交或取消事務，然後進入表決過程。
在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。

2.提交階段（commit phase）
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。
當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。
參與者在接收到協調者發來的消息後將執行響應的操作。

（3）兩階段提交的缺點

1.同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。
當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。

2.單點故障。由於協調者的重要性，一旦協調者發生故障。
參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麽所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處於阻塞狀態的問題）

3.數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之後，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。
而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分布式系統便出現了數據部一致性的現象。

（4）兩階段提交無法解決的問題

當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性。
考慮協調者再發出commit消息之後宕機，而唯一接收到這條消息的參與者同時也宕機了。
那麽即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

四、三階段提交協議

三階段提交協議在協調者和參與者中都引入超時機制，並且把兩階段提交協議的第一個階段拆分成了兩步：詢問，然後再鎖資源，最後真正提交。

（1）三個階段的執行
1.CanCommit階段
3PC的CanCommit階段其實和2PC的準備階段很像。
協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。

2.PreCommit階段
Coordinator根據Cohort的反應情況來決定是否可以繼續事務的PreCommit操作。
根據響應情況，有以下兩種可能。
A.假如Coordinator從所有的Cohort獲得的反饋都是Yes響應，那麽就會進行事務的預執行：
發送預提交請求。Coordinator向Cohort發送PreCommit請求，並進入Prepared階段。
事務預提交。Cohort接收到PreCommit請求後，會執行事務操作，並將undo和redo信息記錄到事務日誌中。
響應反饋。如果Cohort成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。

B.假如有任何一個Cohort向Coordinator發送了No響應，或者等待超時之後，Coordinator都沒有接到Cohort的響應，那麽就中斷事務：
發送中斷請求。Coordinator向所有Cohort發送abort請求。
中斷事務。Cohort收到來自Coordinator的abort請求之後（或超時之後，仍未收到Cohort的請求），執行事務的中斷。

3.DoCommit階段

該階段進行真正的事務提交，也可以分為以下兩種情況:

執行提交

A.發送提交請求。Coordinator接收到Cohort發送的ACK響應，那麽他將從預提交狀態進入到提交狀態。並向所有Cohort發送doCommit請求。
B.事務提交。Cohort接收到doCommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。
C.響應反饋。事務提交完之後，向Coordinator發送ACK響應。
D.完成事務。Coordinator接收到所有Cohort的ACK響應之後，完成事務。

中斷事務

Coordinator沒有接收到Cohort發送的ACK響應（可能是接受者發送的不是ACK響應，也可能響應超時），那麽就會執行中斷事務。

（2）三階段提交協議和兩階段提交協議的不同

對於協調者(Coordinator)和參與者(Cohort)都設置了超時機制（在2PC中，只有協調者擁有超時機制，即如果在一定時間內沒有收到cohort的消息則默認失敗）。
在2PC的準備階段和提交階段之間，插入預提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個階段。
PreCommit是一個緩沖，保證了在最後提交階段之前各參與節點的狀態是一致的。

摘自維基百科：

三階段提交是“非阻塞”協議。
三階段提交在兩階段提交的第一階段與第二階段之間插入了一個準備階段，
使得原先在兩階段提交中，參與者在投票之後，由於協調者發生崩潰或錯誤，
而導致參與者處於無法知曉是否提交或者中止的“不確定狀態”所產生的可能相當長的延時的問題得以解決。 舉例來說，假設有一個決策小組由一個主持人負責與多位組員以電話聯絡方式協調是否通過一個提案，以兩階段提交來說，主持人收到一個提案請求，打電話跟每個組員詢問是否通過並統計回復，然後將最後決定打電話通知各組員。
要是主持人在跟第一位組員通完電話後失憶，而第一位組員在得知結果並執行後老人癡呆，那麽即使重新選出主持人，也沒人知道最後的提案決定是什麽，也許是通過，也許是駁回，不管大家選擇哪一種決定，都有可能與第一位組員已執行過的真實決定不一致，老板就會不開心認為決策小組溝通有問題而解雇。
三階段提交即是引入了另一個步驟，主持人打電話跟組員通知請準備通過提案，以避免沒人知道真實決定而造成決定不一致的失業危機。
為什麽能夠解決二階段提交的問題呢？
回到剛剛提到的狀況，在主持人通知完第一位組員請準備通過後兩人意外失憶，即使沒人知道全體在第一階段的決定為何，全體決策組員仍可以重新協調過程或直接否決，不會有不一致決定而失業。
那麽當主持人通知完全體組員請準備通過並得到大家的再次確定後進入第三階段，
當主持人通知第一位組員請通過提案後兩人意外失憶，這時候其他組員再重新選出主持人後，
仍可以知道目前至少是處於準備通過提案階段，表示第一階段大家都已經決定要通過了，此時便可以直接通過。

（2）三階段提交協議的缺點

如果進入PreCommit後，Coordinator發出的是abort請求，假設只有一個Cohort收到並進行了abort操作，
而其他對於系統狀態未知的Cohort會根據3PC選擇繼續Commit，此時系統狀態發生不一致性。

五、Paxos算法

目前還有一種重要的算法就是Paxos算法，Zookeeper采用的就是Paxos算法的改進。

參考資料：

維基百科：兩階段提交協議

分布式協議之兩階段提交協議（2PC）和改進三階段提交協議（3PC）

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

Introduction to 3PC 三階段提交協議簡介

對分布式事務及兩階段提交、三階段提交的理解