高可用是指系統無中斷的執行功能的能力，代表了系統的可用程度，是進行系統設計時必須要遵守的準則之一。 而高可用的實現方案，無外乎就是冗余，就存儲的高可用而言，問題不在于如何進行數據備份，而在于如何規避數據不一致對業務造成的影響。 對于分布式系統而言，要保證分布式系統中的數據一致性就需要一種方案，可以保證數據在子系統中始終保持一致，避免業務出現問題。 這種實現方案就叫做分布式事務，要么一起成功，要么一起失敗，必須是一個整體性的事務。

1、理論基礎

1.1 CAP

CAP，Consistency Availability Partition tolerance 的簡寫：

Consistency：一致性，對某個客戶端來說，讀操作能夠返回最新的寫操作結果。 Availability：可用性，非故障節點在合理的時間內返回合理的響應。 Partition tolerance：分區容錯性，分布式系統中系統肯定部署在多臺機器上，無法保證網絡做到 100% 的可靠，所以網絡分區一定存在，即 P 一定存在。

在出現網絡分區后，就出現了可用性和一致性的問題，我們必須要在這兩者之間進行取舍，因此就有了兩種架構：

• CP 架構
• AP 架構

1.2 BASE理論

BASE 理論指的是基本可用 Basically Available，軟狀態 Soft State，最終一致性 Eventual Consistency，核心思想是即便無法做到強一致性，但應該采用適合的方式保證最終一致性。

BASE，Basically Available Soft State Eventual Consistency 的簡寫： BA：Basically Available 基本可用，分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。 S：Soft State 軟狀態，允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。 E：Consistency 最終一致性，系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。

BASE 理論本質上是對 CAP 理論的延伸，是對 CAP 中 AP 方案的一個補充。

2、分布式事務協議

2.1 二階段提交協議:2PC

2.1.1 概述

二階段提交（Two-phase Commit），是指，為了使基于分布式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種算法（Algorithm）。通常，二階段提交也被稱為是一種協議（Protocol）。

在分布式系統中，每個節點雖然可以知曉自己的操作是成功或者失敗，卻無法知道其他節點的操作是成功或失敗。

當一個事務跨越多個節點時，為了保持事務的 ACID 特性，需要引入一個作為協調者的組件來統一掌控所有節點（稱作參與者）的操作結果并最終指示這些節點是否要把操作結果進行真正的提交（比如將更新后的數據寫入磁盤等等）。

因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

2.1.2 二階段提交過程

• 投票階段

image.png

投票階段執行流程：

1. 協調者向所有參與者詢問是否可以執行提交操作，并開始等待各參與者的響應。
2. 參與者執行事務操作，如果執行成功就返回 Yes 響應，如果執行失敗就返回 No 響應。
3. 如果協調者接受參與者響應超時，也會認為執行事務操作失敗。

• 提交階段

image.png

提交階段執行流程：

1. 如果第一階段匯總所有參與者都返回 Yes 響應，協調者向所有參與者發出提交請求，所有參與者提交事務。
2. 如果第一階段中有一個或者多個參與者返回 No 響應，協調者向所有參與者發出回滾請求，所有參與者進行回滾操作。

2.1.3 優缺點

• 優點 盡量保證了數據的強一致，但不是 100% 一致
• 缺點 單點故障，由于協調者的重要性，一旦協調者發生故障，參與者會一直阻塞，尤其是在第二階段，協調者發生故障，那么所有的參與者都處于鎖定事務資源的狀態中，而無法繼續完成事務操作。 同步阻塞，由于所有節點在執行操作時都是同步阻塞的，當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處于阻塞狀態。 數據不一致，在第二階段中，當協調者向參與者發送提交事務請求之后，發生了局部網絡異常或者在發送提交事務請求過程中協調者發生了故障，這會導致只有一部分參與者接收到了提交事務請求。
  而在這部分參與者接到提交事務請求之后就會執行提交事務操作。但是其他部分未接收到提交事務請求的參與者則無法提交事務。從而導致分布式系統中的數據不一致。

2.2 三階段提交協議:3PC

2.2.1 概述

三階段提交（Three-phase commit），是為解決兩階段提交協議的缺點而設計的。與兩階段提交不同的是，三階段提交是“非阻塞”協議。

三階段提交在兩階段提交的第一階段與第二階段之間插入了一個準備階段，使得原先在兩階段提交中，參與者在投票之后，由于協調者發生崩潰或錯誤，而導致參與者處于無法知曉是否提交或者中止的“不確定狀態”所產生的可能相當長的延時的問題得以解決。

2.2.2 三階段提交過程

image.png

詢問階段：CanCommit 協調者向參與者發送 Commit 請求，參與者如果可以提交就返回 Yes 響應，否則返回 No 響應。

準備階段：PreCommit 協調者根據參與者在詢問階段的響應判斷是否執行事務還是終端事務： 如果所有參與者都返回 Yes，則執行事務。 如果參與者有一個或多個參與者返回 No 或者超時，則中斷事務。 參與者執行完操作之后返回 ACK 響應，同時開始等待最終指令

提交階段：DoCommit 協調者根據參與者在準備階段的響應判斷是否執行事務還是中斷事務： 如果所有參與者都返回正確的 ACK 響應，則提交事務。 如果參與者有一個或多個參與者收到錯誤的 ACK 響應或者超時，則中斷事務。 如果參與者無法及時接收到來自協調者的提交或者中斷事務請求時，會在等待超時之后，會繼續進行事務提交。 協調者收到所有參與者的 ACK 響應，完成事務。

2.2.3 解決二階段提交時的問題：

三階段提交解決了二階段提交中存在的由于協調者和參與者同時掛掉可能導致的數據一致性問題和單點故障問題，并減少阻塞。 因為一旦參與者無法及時收到來自協調者的信息之后，他會默認執行提交事務（三階段），而不會一直持有事務資源并處于阻塞狀態（二階段會）。

2.2.4 三階段提交的問題：

在提交階段如果發送的是中斷事務請求，但是由于網絡問題，導致部分參與者沒有接到請求。
那么參與者會在等待超時之后執行提交事務操作，這樣這些由于網絡問題導致提交事務的參與者的數據就與接受到中斷事務請求的參與者存在數據不一致的問題。

所以無論是 2PC 還是 3PC 都不能保證分布式系統中的數據 100% 一致。

2.3 ZAB——zookeeper 原子廣播協議

2.3.1 概述

ZAB 協議全稱是Zookeeper Atomic Broadcast，是為分布式協調服務 Zookeeper 專門設計的一種支持 崩潰恢復 和 原子廣播 協議。 ZAB 協議滿足CP，在選舉過程中，是不能對外提供服務的。

2.3.3 消息廣播

ZAB 協議的消息廣播過程（即數據同步過程）使用的是一個原子廣播協議，類似一個 二階段提交過程。對于客戶端發送的寫請求，全部由 Leader 接收，Leader 將請求封裝成一個事務 Proposal，將其發送給所有 Follwer ，然后，根據所有 Follwer 的反饋，如果超過半數成功響應，則執行 commit 操作（先提交自己，再發送 commit 給所有 Follwer）。

廣播流程：

image.png

• 客戶端發起一個寫操作請求。
• Leader 服務器將客戶端的請求轉化為事務 Proposal 提案，同時為每個 Proposal 分配一個全局的ID，即zxid。然后將需要廣播的Proposal 依次放到隊列中，并且根據 FIFO 策略進行消息發送。
• Follower 接收到 Proposal 后，會首先將其以事務日志的方式寫入本地磁盤中，寫入成功后向 Leader 反饋一個 Ack 響應消息。
• Leader 接收到超過半數以上 Follower 的 Ack 響應消息后，即認為消息發送成功，可以發送 commit 消息。
• Leader 向所有 Follower 廣播 commit 消息，同時自身也會完成事務提交。Follower 接收到 commit 消息后，會將上一條事務提交。

注意： 1、 Leader 服務器與每一個 Follower 服務器之間都維護了一個單獨的 FIFO 消息隊列進行收發消息，使用隊列消息可以做到異步解耦。 Leader 和 Follower 之間只需要往隊列中發消息即可 2、Leader 在收到客戶端請求之后，會將這個請求封裝成一個事務，并給這個事務分配一個全局遞增的唯一 ID，稱為事務ID（ZXID），ZAB 協議需要保證事務的順序，因此必須將每一個事務按照 ZXID 進行先后排序然后處理 3、可以認為這是一種簡化版本的 2PC，2PC的單點問題（Leader崩潰）這里也會遇到，ZAB是通過崩潰恢復來解決的

2.3.3 崩潰恢復

所謂崩潰恢復，是指當leader崩潰（單點故障）后，重新選舉leader并且數據保持一致性（數據同步）。

• leader選舉：
  選舉是通過投票來的，主要分為以下幾個階段，

1. 發起投票：首輪投票，每個節點發出一個投票，先投票給自己，然后再把投票結果廣播到集群中別的節點，其他機器。投票內容包含節點的myid（zookeeper安裝時要設置的值，表示當前節點id）和zxid（事務id），比如ZK1的投票為(1, 0)，ZK2的投票為(2, 0)
2. 驗證投票：每個節點都投票給自己并且廣播之后，那么節點就會收到別的節點的投票結果，在收到投票后可以驗證投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的服務器，
3. 變更投票：驗證完收到的投票結果后，處理投票，針對每一個投票，服務器都需要將別人的投票和自己的投票進行比較，規則如下 · 優先檢查ZXID。ZXID比較大的服務器優先作為Leader； · 如果ZXID相同，那么就比較myid。myid較大的服務器作為Leader服務器； 根據以上規則變更自己的投票，然后廣播第二輪投票，還是同樣的過程，先驗證投票，然后變更投票，變更完成以后統計票倉（本輪投票過程中接收到的別的節點的投票信息）中，是否有超過半數的相同投票，如果有，則其就是新的leader，選舉結束；如果沒有，則繼續發起投票，知道選出leader。

image.png

由上面規則可知，通常那臺服務器上的數據越新（ZXID會越大），其成為Leader的可能性越大，也就越能夠保證數據的恢復。如果ZXID相同，則SID越大機會越大。

• 數據同步：
  上面的leader選舉結束后，只有當新的leader和follower同步數據之后，才能對外提供服務。
  同步分為以下幾個階段：

1. 所有follower上報自己最后接收的事務的任期epoch（每個Proposal都包含了一個epoch值，用來代表當前的Leader 周期）；leader比較所有的任期，選取最大的epoch，加1后作為當前的任期E=E+1，并且將任期epoch廣播給所有follower；follower將任期改為leader發過來的值之后，返回給leader當前follewer節點上的事務隊列L；
2. leader從隊列集合中選取任期最大的隊列，如果有多個隊列任期都是最大，則選取事務編號n最大的隊列Lmax（通常就是leader節點自己的事務隊列，因為選舉leader時，就是選出的事務zxid最大的節點），并將其廣播給各個follower，follower接收隊列替換自己的事務隊列，并且執行隊列中的事務（執行過跳過，未執行執行），執行完以后反饋給leader 表明自己已經完成同步（追上來了），leader 收到過半反饋后，發送commit 消息；follower 接收到commit 消息后，提交事務； 至此各個節點的數據達成一致，zookeeper恢復正常服務。

注意：在zk選舉中，通過投票已經確認leader服務器是最大的zxid的節點了，所以同步過程沒有那么復雜。 同步階段主要是利用 Leader 前一階段獲得的最新 Proposal 歷史，同步集群中所有的副本。只有當超過半數的節點都同步完成，準 Leader 才會成為真正的 Leader。Follower 只會處理 zxid 比自己 lastZxid 大的 Proposal。

3、最終一致性分布式事務方案

3.1 本地消息表

本地消息表的核心思想是將分布式事務拆分成本地事務進行處理。

例如，在訂單系統新增一條消息表，將新增訂單和新增消息放到一個事務里完成，然后通過輪詢的方式去查詢消息表，將消息推送到 MQ，庫存系統去消費 MQ。

image.png

執行流程：

1. 訂單系統，添加一條訂單和一條消息，在一個事務里提交。
2. 訂單系統，使用定時任務輪詢查詢狀態為未同步的消息表，發送到 MQ，如果發送失敗，就重試發送。
3. 庫存系統，接收 MQ 消息，修改庫存表，需要保證冪等操作。
4. 如果修改成功，調用 RPC 接口修改訂單系統消息表的狀態為已完成或者直接刪除這條消息。 如果修改失敗，可以不做處理，等待重試。

訂單系統中的消息有可能由于業務問題會一直重復發送，所以為了避免這種情況可以記錄一下發送次數，當達到次數限制之后報警，人工接入處理；庫存系統需要保證冪等，避免同一條消息被多次消費造成數據一致。

本地消息表這種方案實現了最終一致性，需要在業務系統里增加消息表，業務邏輯中多一次插入的 DB 操作，所以性能會有損耗，而且最終一致性的間隔主要由定時任務的間隔時間決定。

3.2 MQ 消息事務

消息事務的原理是將兩個事務通過消息中間件進行異步解耦。

image.png

從上面可以看出，消息事務一定要保證業務操作與消息發送的一致性，如果業務操作成功，這條消息也一定投遞成功。

消息事務依賴于消息中間件的事務消息，基于消息中間件第二階段提交實現的，RocketMQ 就支持事務消息。RabbitMQ也支持事務消息

執行流程：

1. 發送 Prepare 消息到消息中間件。
2. 發送成功后，執行本地事務。
3. 如果事務執行成功，則 Commit，消息中間件將消息下發至消費端。
4. 如果事務執行失敗，則回滾，消息中間件將這條 Prepare 消息刪除。
5. 消費端接收到消息進行消費，如果消費失敗，則不斷重試。

這種方案也是實現了最終一致性，對比本地消息表實現方案，不需要再建消息表，不再依賴本地數據庫事務了，所以這種方案更適用于高并發的場景。

3.3 最大努力通知

最大努力通知相比前兩種方案實現簡單，適用于一些最終一致性要求較低的業務，比如支付通知，短信通知這種業務。 以支付通知為例，業務系統調用支付平臺進行支付，支付平臺進行支付，進行操作支付之后支付平臺會盡量去通知業務系統支付操作是否成功，但是會有一個最大通知次數。 如果超過這個次數后還是通知失敗，就不再通知，業務系統自行調用支付平臺提供一個查詢接口，供業務系統進行查詢支付操作是否成功。

image.png

執行流程：

1. 業務系統調用支付平臺支付接口， 并在本地進行記錄，支付狀態為支付中。
2. 支付平臺進行支付操作之后，無論成功還是失敗，都需要給業務系統一個結果通知。
3. 如果通知一直失敗則根據重試規則進行重試，達到最大通知次數后，不再通知。
4. 支付平臺提供查詢訂單支付操作結果接口。
5. 業務系統根據一定業務規則去支付平臺查詢支付結果。

這種方案也是實現了最終一致性。

3.4 補償事務 TCC

TCC，Try-Confirm-Cancel 的簡稱，針對每個操作，都需要有一個其對應的確認和取消操作。 當操作成功時調用確認操作，當操作失敗時調用取消操作，類似于二階段提交，只不過是這里的提交和回滾是針對業務上的，所以基于 TCC 實現的分布式事務也可以看做是對業務的一種補償機制。

3.4.1 TCC 第三個階段：

• Try 階段：對業務系統做檢測及資源預留、凍結。
• Confirm 階段：對業務系統做確認提交，Try 階段執行成功并開始執行 Confirm 階段時，默認 Confirm 階段是不會出錯的。即：只要 Try 成功，Confirm 一定成功。
• Cancel 階段：在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。

在 Try 階段，是對業務系統進行檢查及資源預覽，比如訂單和存儲操作，需要檢查庫存剩余數量是否夠用，并進行預留，預留操作的話就是新建一個可用庫存數量字段，Try 階段操作是對這個可用庫存數量進行操作。

3.4.2 TCC執行流程：

步驟一(Try 階段)：訂單系統將當前訂單狀態設置為支付中，庫存系統校驗當前剩余庫存數量是否大于 2，然后將可用庫存數量設置為庫存剩余數量 -2，并且設置凍結庫存為2

• image.png

步驟二(Confirm 階段)：如果 Try 階段執行成功，執行 Confirm 階段，將訂單狀態修改為支付成功，庫存剩余數量修改為可用庫存數量。

• image.png

步驟三(Cancel 階段)：如果 Try 階段執行失敗，執行 Cancel 階段，將訂單狀態修改為支付失敗，可用庫存數量修改為庫存剩余數量。

• image.png

image.png

3.4.3 基于 TCC 實現的分布式事務框架：

ByteTCC，github.com/liuyangming tcc-transaction：github.com/changmingxi