標籤：

常用的分散式事務解決方案介紹有多少種？

01-21

關於分散式事務，工程領域主要討論的是強一致性和最終一致性的解決方案。典型方案包括：

  1. 兩階段提交（2PC, Two-phase Commit）方案
  2. eBay 事件隊列方案
  3. TCC 補償模式
  4. 緩存數據最終一致性

一、一致性理論

分散式事務的目的是保障分庫數據一致性，而跨庫事務會遇到各種不可控制的問題，如個別節點永久性宕機，像單機事務一樣的ACID是無法奢望的。另外，業界著名的CAP理論也告訴我們，對分散式系統，需要將數據一致性和系統可用性、分區容忍性放在天平上一起考慮。

兩階段提交協議（簡稱2PC）是實現分散式事務較為經典的方案，但2PC 的可擴展性很差，在分散式架構下應用代價較大，eBay 架構師Dan Pritchett 提出了BASE 理論，用於解決大規模分散式系統下的數據一致性問題。BASE 理論告訴我們：可以通過放棄系統在每個時刻的強一致性來換取系統的可擴展性。

1、CAP理論

在分散式系統中，一致性（Consistency）、可用性（Availability）和分區容忍性（Partition Tolerance）3 個要素最多只能同時滿足兩個，不可兼得。其中，分區容忍性又是不可或缺的。

  • 一致性：分散式環境下多個節點的數據是否強一致。
  • 可用性：分散式服務能一直保證可用狀態。當用戶發出一個請求後，服務能在有限時間內返回結果。
  • 分區容忍性：特指對網路分區的容忍性。

舉例：Cassandra、Dynamo 等，默認優先選擇AP，弱化C；HBase、MongoDB 等，默認優先選擇CP，弱化A。

2、BASE 理論

核心思想：

  • 基本可用（Basically

    Available）    ：指分散式系統在出現故障時，允許損失部分的可用性來保證核心可用。
  • 軟狀態（Soft

    State）    ：指允許分散式系統存在中間狀態，該中間狀態不會影響到系統的整體可用性。
  • 最終一致性（Eventual

    Consistency）    ：指分散式系統中的所有副本數據經過一定時間後，最終能夠達到一致的狀態。

二、一致性模型

數據的一致性模型可以分成以下 3 類：

  1. 強一致性：數據更新成功後，任意時刻所有副本中的數據都是一致的，一般採用同步的方式實現。
  2. 弱一致性：數據更新成功後，系統不承諾立即可以讀到最新寫入的值，也不承諾具體多久之後可以讀到。
  3. 最終一致性：弱一致性的一種形式，數據更新成功後，系統不承諾立即可以返回最新寫入的值，但是保證最終會返回上一次更新操作的值。

分散式系統數據的強一致性、弱一致性和最終一致性可以通過Quorum NRW演算法分析。

三、分散式事務解決方案

1、2PC方案——強一致性

2PC的核心原理是通過提交分階段和記日誌的方式，記錄下事務提交所處的階段狀態，在組件宕機重啟後，可通過日誌恢復事務提交的階段狀態，並在這個狀態節點重試，如Coordinator重啟後，通過日誌可以確定提交處於Prepare還是PrepareAll狀態，若是前者，說明有節點可能沒有Prepare成功，或所有節點Prepare成功但還沒有下發Commit，狀態恢復後給所有節點下發RollBack；若是PrepareAll狀態，需要給所有節點下發Commit，資料庫節點需要保證Commit冪等。

2PC方案的問題：

  1. 同步阻塞。
  2. 數據不一致。
  3. 單點問題。

升級的3PC方案旨在解決這些問題，主要有兩個改進：

  1. 增加超時機制。
  2. 兩階段之間插入準備階段。

但三階段提交也存在一些缺陷，要徹底從協議層面避免數據不一致，可以採用Paxos或者Raft 演算法。

2、eBay 事件隊列方案——最終一致性

eBay 的架構師Dan Pritchett，曾在一篇解釋BASE 原理的論文《Base：An Acid Alternative》中提到一個eBay 分散式系統一致性問題的解決方案。它的核心思想是將需要分散式處理的任務通過消息或者日誌的方式來非同步執行，消息或日誌可以存到本地文件、資料庫或消息隊列，再通過業務規則進行失敗重試，它要求各服務的介面是冪等的。

描述的場景為，有用戶表user 和交易表transaction，用戶表存儲用戶信息、總銷售額和總購買額，交易表存儲每一筆交易的流水號、買家信息、賣家信息和交易金額。如果產生了一筆交易，需要在交易表增加記錄，同時還要修改用戶表的金額。

論文中提出的解決方法是將更新交易表記錄和用戶表更新消息放在一個本地事務來完成，為了避免重複消費用戶表更新消息帶來的問題，增加一個操作記錄表updates_applied來記錄已經完成的交易相關的信息。

這個方案的核心在於第二階段的重試和冪等執行。失敗後重試，這是一種補償機制，它是能保證系統最終一致的關鍵流程。

3、TCC （Try-Confirm-Cancel）補償模式——最終一致性

某業務模型如圖，由服務 A、服務B、服務C、服務D 共同組成的一個微服務架構系統。服務A 需要依次調用服務B、服務C 和服務D 共同完成一個操作。當服務A 調用服務D 失敗時，若要保證整個系統數據的一致性，就要對服務B 和服務C 的invoke 操作進行回滾，執行反向的revert 操作。回滾成功後，整個微服務系統是數據一致的。

實現關鍵要素：

  1. 服務調用鏈必須被記錄下來。
  2. 每個服務提供者都需要提供一組業務邏輯相反的操作，互為補償，同時回滾操作要保證冪等。
  3. 必須按失敗原因執行不同的回滾策略。

4、緩存數據最終一致性

在我們的業務系統中，緩存（Redis 或者Memcached）通常被用在資料庫前面，作為數據讀取的緩衝，使得I/O 操作不至於直接落在資料庫上。以商品詳情頁為例，假如賣家修改了商品信息，並寫回到資料庫，但是這時候用戶從商品詳情頁看到的信息還是從緩存中拿到的過時數據，這就出現了緩存系統和資料庫系統中的數據不一致的現象。

要解決該場景下緩存和資料庫數據不一致的問題我們有以下兩種解決方案：

  1. 為緩存數據設置過期時間。當緩存中數據過期後，業務系統會從資料庫中獲取數據，並將新值放入緩存。這個過期時間就是系統可以達到最終一致的容忍時間。
  2. 更新資料庫數據後同時清除緩存數據。資料庫數據更新後，同步刪除緩存中數據，使得下次對商品詳情的獲取直接從資料庫中獲取，並同步到緩存。

四、選擇建議

在面臨數據一致性問題的時候，首先要從業務需求的角度出發，確定我們對於3 種一致性模型的接受程度，再通過具體場景來決定解決方案。

從應用角度看，分散式事務的現實場景常常無法規避，在有能力給出其他解決方案前，2PC也是一個不錯的選擇。

對購物轉賬等電商和金融業務，中間件層的2PC最大問題在於業務不可見，一旦出現不可抗力或意想不到的一致性破壞，如數據節點永久性宕機，業務難以根據2PC的日誌進行補償。金融場景下，數據一致性是命根，業務需要對數據有百分之百的掌控力，建議使用TCC這類分散式事務模型，或基於消息隊列的柔性事務框架，這兩種方案都在業務層實現，業務開發者具有足夠掌控力，可以結合SOA框架來架構，包括Dubbo、Spring Cloud等（題主的標籤寫了Dubbo）。

利益相關：

以上內容，基本都摘自網易雲基礎服務架構團隊著《雲原生應用架構實踐》，更多內容，譬如分散式事務的核心——分散式鎖的解析，可以參閱圖書。部分內容預覽可以參考這裡。

樓上已經包含了主要的幾種，我在這裡對2PC補充一點，classic-2PC是不容錯的，coordinator一旦宕機就會產生阻塞，因此一些擴展協議，比如Paxos和Raft，對於2F+1個coordinator，可以容錯F台機器宕機，而且採用的強一致性原則保證了一致性，根據CAP理論是選擇了AC，所以需要大的集中的數據中心。其他的還有許多非強一致性演算法，如最初的ViewStamped replication，需要達到最終一致需要其他的處理措施。對於2PC還有一些擴展 比如PA(Presumed Abort) PC(Presumed Commit)等等，種類非常繁多

我最近有看到一篇文章，寫到了幾種常用的分散式事務解決方案，作者闡明了幾種解決方案的不同點，對於取決於哪種方式關鍵還是要看項目需求： 常用的分散式事務解決方案介紹

推薦閱讀：

※如何理解阿里大神程立的分散式事務文檔?
※阿里雲的分散式事務中間件是什麼實現的？

TAG:Java | IT解決方案 | 分散式事務 | dubbo |