分佈式系統常見的事務處理機制

爲保障系統的可用性、可靠性以及性能，在分佈式系統中，每每會設置數據冗餘，即對數據進行復制。舉例來講，當一個數據庫的副本被破環之後，那麼系統只須要轉換到其餘數據副本就能繼續運行下去。另一個例子，當訪問單一服務器管理的數據的進程數不斷增長時，系統就須要對服務器的數量進行擴充，此時，對服務器進行復制，隨後讓它們分擔工做負荷，就能夠提升性能。但同時，如何保障多個數據節點之間數據的一致以及如何處理分佈式事務，將成爲爲一個複雜的話題。本文將介紹經常使用的事務處理機制。

CAP 定理
CAP 定理（也稱爲 Brewer 定理），是由計算機科學家 Eric Brewer 提出的，即在分佈式計算機系統不可能同時提供如下所有三個保證：

一致性（Consistency）：全部節點同一時間看到是相同的數據；
可用性（Availability）：不論是否成功，確保每個請求都能接收到響應；
分區容錯性（Partition tolerance）：系統任意分區後，在網絡故障時，仍能操做
顯然，爲了保障性能和可靠性，咱們將數據複製多份，分佈到多個節點上，同時也帶來了一個難點，那就是如何保持各個副本數據的一致性。換句話說，咱們選擇了 AP ，則必需要犧牲掉 C 了。

可是，在實際的應用場景中，數據的一致性每每也是須要保證的。那麼這是否違背了 CAP 定理呢？

一致性模型
其實，數據的一致性也分幾種狀況，大體能夠分爲：

Weak 弱一致性：當你寫入一個新值後，讀操做在數據副本上可能讀出來，也可能讀不出來。好比：某些存儲系統，搜索引擎，實時遊戲，語音聊天等，這些數據本文對完整性要求不高，數據是否一致關係也不大。
Eventually 最終一致性：當你寫入一個新值後，並不必定能立刻讀出來，但在某個時間窗口以後保證最終能讀出來。好比：DNS，電子郵件，消息中間件等系統，大部分分佈式系統技術都採用這類模式。
Strong 強一致性：新的數據一旦寫入，在任意副本任意時刻都能讀到新值。好比：文件系統，RDBMS都是強一致性的。
也就是說，在設計分佈式系統時，咱們並不必定要求是強一致性的，根據應用場景能夠選擇弱一致性或者是最終一致性。

事務的做用
事務有以下做用：

保證執行結果的正確性
保證數據的一致性
ACID
常見的事務處理機制
Master-Slave 複製
Slave 通常是 Master 的備份。在這樣的系統中，通常是以下設計的：

讀寫請求都由 Master 負責。
寫請求寫到 Master 上後，由 Master 同步到 Slave 上。
這種機制的特色是：

數據同步一般是異步的
有良好的吞吐量，低延遲 *　在大多數　RDBMS　中支持，好比　MySQL二進制日誌
弱/最終一致性
這種機制的缺點是，若是 Master 掛了，Slave 只能提供讀服務，而沒有寫服務。

Master-Master 多主複製
指一個系統存在兩個或多個Master，每一個Master都提供讀寫服務。這個機制是Master-Slave的增強版，數據間同步通常是經過Master間的異步完成，因此是最終一致性。 Master-Master的好處是，一臺Master掛了，別的Master能夠正常作讀寫服務，他和Master-Slave同樣，當數據沒有被複制到別的Master上時，數據會丟失。不少數據庫都支持Master-Master的Replication的機制。

這種機制的特色是：

異步
最終的一致性
多個節點間須要序列化協議
兩階段提交
兩階段提交協議 （Two-phase commit protocol，2PC）的過程涉及到協調者和參與者。協調者能夠看作成事務的發起者，同時也是事務的一個參與者。對於一個分佈式事務來講，一個事務是涉及到多個參與者的。具體的兩階段提交的過程以下：

第一階段（準備階段）
協調者節點向全部參與者節點詢問是否能夠執行提交操做(vote)，並開始等待各參與者節點的響應。
參與者節點執行詢問發起爲止的全部事務操做，並將 Undo 信息和 Redo 信息寫入日誌。（注意：若成功這裏其實每一個參與者已經執行了事務操做）
各參與者節點響應協調者節點發起的詢問。若是參與者節點的事務操做實際執行成功，則它返回一個「贊成」消息；若是參與者節點的事務操做實際執行失敗，則它返回一個「停止」消息。
第二階段（提交階段）
若是協調者收到了參與者的失敗消息或者超時，直接給每一個參與者發送回滾(Rollback)消息；不然，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操做，釋放全部事務處理過程當中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)

當協調者節點從全部參與者節點得到的相應消息都爲「贊成」時:
協調者節點向全部參與者節點發出「正式提交(commit)」的請求。
參與者節點正式完成操做，並釋放在整個事務期間內佔用的資源。
參與者節點向協調者節點發送「完成」消息。
若是任一參與者節點在第一階段返回的響應消息爲」停止」，或者 協調者節點在第一階段的詢問超時以前沒法獲取全部參與者節點的響應消息時：
協調者節點向全部參與者節點發出」回滾操做(rollback)」的請求。
參與者節點利用以前寫入的Undo信息執行回滾，並釋放在整個事務期間內佔用的資源。
參與者節點向協調者節點發送」回滾完成」消息。
協調者節點受到全部參與者節點反饋的」回滾完成」消息後，取消事務。
協調者節點受到全部參與者節點反饋的」完成」消息後，完成事務
無論最後結果如何，第二階段都會結束當前事務。

二段式提交協議的優缺點：

優勢：原理簡單，實現方便；

缺點：

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

三階段提交
三階段提交協議（Three-phase commit protocol，3PC），是二階段提交（2PC）的改進版本。與兩階段提交不一樣的是，三階段提交有兩個改動點：

引入超時機制。同時在協調者和參與者中都引入超時機制。
在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。
即 3PC 把 2PC 的準備階段再次一分爲二，這樣三階段提交就有 CanCommit、PreCommit、DoCommit 三個階段。

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

事務詢問：協調者向參與者發送 CanCommit 請求。詢問是否能夠執行事務提交操做。而後開始等待參與者的響應。
響應反饋：參與者接到 CanCommit 請求以後，正常狀況下，若是其自身認爲能夠順利執行事務，則返回 Yes 響應，並進入預備狀態。不然反饋 No
PreCommit 階段
協調者根據參與者的反應狀況來決定是否能夠記性事務的 PreCommit 操做。根據響應狀況，有如下兩種可能。

假如協調者從全部的參與者得到的反饋都是 Yes 響應，那麼就會執行事務的預執行。
發送預提交請求：協調者向參與者發送 PreCommit 請求，並進入Prepared 階段。
事務預提交：參與者接收到 PreCommit 請求後，會執行事務操做，並將undo 和 redo 信息記錄到事務日誌中。
響應反饋：若是參與者成功的執行了事務操做，則返回 ACK 響應，同時開始等待最終指令。
假若有任何一個參與者向協調者發送了 No 響應，或者等待超時以後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。
發送中斷請求：協調者向全部參與者發送 abort 請求。
中斷事務：參與者收到來自協調者的 abort 請求以後（或超時以後，仍未收到協調者的請求），執行事務的中斷。
doCommit 階段
該階段進行真正的事務提交，也能夠分爲如下兩種狀況。

執行提交
發送提交請求：協調接收到參與者發送的 ACK 響應，那麼他將從預提交狀態進入到提交狀態。並向全部參與者發送 doCommit 請求。
事務提交：參與者接收到 doCommit 請求以後，執行正式的事務提交。並在完成事務提交以後釋放全部事務資源。
響應反饋：事務提交完以後，向協調者發送 ACK 響應。
完成事務：協調者接收到全部參與者的 ACK 響應以後，完成事務。
中斷事務：協調者沒有接收到參與者發送的 ACK 響應（多是接受者發送的不是 ACK 響應，也可能響應超時），那麼就會執行中斷事務。
發送中斷請求：協調者向全部參與者發送 abort 請求
事務回滾：參與者接收到 abort 請求以後，利用其在階段二記錄的undo 信息來執行事務的回滾操做，並在完成回滾以後釋放全部的事務資源。
反饋結果：參與者完成事務回滾以後，向協調者發送 ACK 消息
中斷事務：協調者接收到參與者反饋的 ACK 消息以後，執行事務的中斷。
在 doCommit 階段，若是參與者沒法及時接收到來自協調者的 doCommit 或者 rebort 請求時，會在等待超時以後，會繼續進行事務的提交。即當進入第三階段時，因爲網絡超時等緣由，雖然參與者沒有收 到 commit 或者 abort 響應，事務仍然會提交。

三階段提交不會一直持有事務資源並處於阻塞狀態。可是這種機制也會致使數據一致性問題，由於，因爲網絡緣由，協調者發送的 abort 響應沒有及時被參與者接收到，那麼參與者在等待超時以後執行了 commit 操做，這樣就和其餘接到 abort 命令並執行回滾的參與者之間存在數據不一致的狀況。

Paxos 算法
Paxos 算法是 Leslie Lamport 於1990年提出的一種基於消息傳遞且具備高度容錯特性的一致性算法。Paxos 算法目前在 Google 的 Chubby、MegaStore、Spanner 等系統中獲得了應用，Hadoop 中的 ZooKeeper 也使用了 Paxos 算法。

在 Paxos 算法中，分爲4種角色：

Proposer ：提議者
Acceptor：決策者
Client：產生議題者
Learner：最終決策學習者
算法能夠分爲兩個階段來執行：

階段1Proposer 選擇一個議案編號 n，向 acceptor 的多數派發送編號也爲 n 的 prepare 請求。Acceptor：若是接收到的 prepare 請求的編號 n 大於它已經迴應的任何prepare 請求，它就回應已經批准的編號最高的議案（若是有的話），並承諾再也不迴應任何編號小於 n 的議案；階段2Proposer：若是收到了多數 acceptor 對 prepare 請求（編號爲 n）的迴應，它就向這些 acceptor 發送議案{n, v}的 accept 請求，其中 v 是全部迴應中編號最高的議案的決議，或者是 proposer 選擇的值，若是迴應說尚未議案。Acceptor：若是收到了議案{n, v}的 accept 請求，它就批准該議案，除非它已經迴應了一個編號大於 n 的議案。Proposer 能夠提出多個議案，只要它遵循上面的算法。它能夠在任什麼時候刻放棄一個議案。（這不會破壞正確性，即便在議案被放棄後，議案的請求或者回應消息纔到達目標）若是其它的 proposer 已經開始提出更高編號的議案，那麼最好能放棄當前的議案。所以，若是 acceptor 忽略一個 prepare 或者 accept 請求（由於已經收到了更高編號的 prepare 請求），它應該告知 proposer 放棄議案。這是一個性能優化，而不影響正確性。