一、背景

隨著微服務架構的演進，單體應用按照服務維度進行拆分，組織架構也隨之演進以橫向、縱向維度拆分；導致了原來呼叫一個服務的一個介面就完成的功能，現在需要協同呼叫多個服務的多個接口才能完成。原來在一個庫中就完成的功能，現在可能要涉及多個庫的多張表，通常還會有多種儲存介質一起協作以支撐資料儲存；而這些情況下傳統的本地事務不能保證資料的一致性。

以下圖購買商品下單業務為例，下訂單由訂單服務、賬戶服務和庫存服務 3 個服務來完成。

本地事務只能保證每個服務各自的本地事務，比如庫存服務 DB 操作異常，其透過本地事務回滾後庫存資料無異常，但訂單和賬戶的記錄並未回滾，因為他們並不知道庫存異常了，這便是典型的分散式資料一致性問題。

二、現狀

在生產環境中裝置、程式等是不可靠的，若它們發生意外則會出現資料不一致的情況；在對資料的一致性要求高的業務場景中，若缺少有效工具的輔助，則常常需要透過如客訴、人工抽檢核對等方式來發現問題，之後再交給程式設計師透過

人工智慧

來排查、修復；這種方式雖也能解決問題，但從時效和人力兩方面看都不高效，同時也拉低了服務質量。

雖然 BASE 論文基於 CAP 定理分析並表述了分散式系統追求高可用的場景下不得不弱化強一致性的觀點，並對眾人產生了深遠的影響，但並不能理解為要降低對一致性的要求，尤其是在某些特殊業務場景中，資料

容易出現非預期的不一致

或

高延遲的不一致

時，會給客戶帶來

極其不好的使用體驗，嚴重時甚至導致運營無法推進、產品無法落地

。所以

需要重新審視資料一致性問題，它實際是與系統的可擴充套件性和高可用同等重要 是【基礎 IT 架構】支撐業務高質量轉型、升級的重點也是難點

。

三、訴求

應對業務規模、資料規模的不斷擴大，主流技術方案都是透過橫向擴充套件節點以提高非熱點資料的併發效能；而橫向擴充套件節點的效果體現在如下 2 方面：

擴充套件功能節點：對應用進行微服務化改造。

擴充套件資料節點：增加資料分片如分庫分表，使用混合儲存如 mysql + ES 的組合。

微服務演進方案的優勢很多，但同時也必然會帶來業務資料不一致的問題，有些情況還讓人特頭疼。在之前很長一段時間，受分散式事務技術成熟度、業務的複雜性及實現價效比等多重因素的影響，關於該如何應對分散式業務資料一致性的這個難題，似乎分化成兩種相對的觀念：一種是困難太多、價效比不高，一致性保障讓人有心無力，進而置之不理；另一種則是需迎難而上，各顯神通，導致出現了許多有意思的變種實現，有些可能既不通用也不健壯。

從標準架構規範的大局來看，置之不理或各顯神通這兩種情況都非合理狀態，實際上需要的是

一套規範的、通用的、可靠的分散式事務解決方案

，能夠幫助開發者在分散式的環境下，既能

保證業務資料的一致性

，又不需要

投入太多的資源

用於業務資料一致性的開發維護，還能

加快迭代速度保障專案交付

。

四、選型

分散式事務解決方案通常分為兩大類，其中一類是非同步確保型，另一類是非非同步確保型；非同步確保型非本篇主題，暫且不提。重點探討非非同步確保型，在行業中開源的分散式事務解決方案的產品有Seata、tcc-transaction TX-LCN Hmily ByteTCC EasyTransaction等，它們各有特色後續會整理一篇稍詳細點的能力對比介紹。從它們所提供方案的分類來說有：補償型-TCC 、無侵入性-AT、強一致型-XA 、補償性-SAGA 以及 LCN。Seata 的能力比較全面，所提供方案種類最多，而且社群活躍度最高。

Seata 從設計層面將事務參與者的角色分為 TC、RM、TM，事務的整體運轉模型如上圖，基於此模型，Seata 支援了TC、AT、XA、SAGA 這 4 種方案，能應對許多應用場景，個人感覺比較貼合日常分散式事務能力訴求的的是 TC 叢集的高可用架構 以及 TCC 和 AT 這兩種事務模式的能力。

1）TC 叢集具有高可用架構

應用到叢集是這樣一個間接的關係：應用 -》事務分組 -》TC 叢集，應用啟動後所指定的事務分組不能變，可透過配置中心變更事務分組所屬的 TC 叢集，Seata 客戶端監聽到這個變更後，會切換到新的 TC 叢集。

2）TCC 模式

TCC 模式要求由業務側透過編碼實現 Try、Confirm、Cancel 3 個方法，TCC 的 Try 操作作為一階段，負責資源的檢查和預留；Confirm 操作作為二階段提交操作，執行真正的業務；Cancel 操作作為二階段回滾操作，執行預留資源的取消，使資源回到初始狀態。

因為各階段都由業務側編碼實現，所以就大大增加了靈活性，容易實現特定場景下的自定義最佳化和特殊功能開發。這個模式幾乎能滿足任何想要的事務場景，如補償型、資源預留型以及訊息事務型等。但也意味著開發的工作量比較大，對開發者的要求比較高。

無論有沒有本地事務控制都可以使用該模式，與底層資料庫事務實現不相關（無需 JDBC 支援）。

Seata 對 TCC 模式實現的完整度比較高，可應對經典的空回滾、防懸掛和冪等控制這三個問題。

3）AT 模式

若把 TCC 模式類比成手動擋駕駛模式，那麼 Seata 的 AT 模式就好比自動擋駕駛模式。AT 模式 是基於 DataSource 代理實現的，其核心思想就是由框架託管分散式事務：透過代理 DataSource ，攔截 SQL 執行，增強其執行邏輯，由代理側加入額外的能力以完成分散式事務。

要求上下游分支事務都支援 JDBC，且所用的 SQL 需要框架能夠支援，有一定的效能損耗，在應用層增加了全域性鎖（行級鎖），高併發有熱點資料的場景需斟酌。

在業務併發不高、邏輯複雜、對一致性要求較高的場景中特別有優勢，只需要引入依賴後調整少量程式碼，方法上增加註解便可擁有完整的分散式事務的能力；這種場景下，特能體現 AT 模式難度低、效率高、更安全的特點。

基於以上評估，Seata 所兼備的 TC 高可用、 TCC 模式和 AT 模式特別符合

一套規範的、通用的、可靠的分散式事務解決方案

的訴求，能將分散式事務問題從業務中儘量剝離出來（AT模式剝離的比較徹底），作為一個獨立的技術切面由專人管理運維（獨立的服務端和模組化的客戶端），提供簡單、易用、高效、穩定的分散式事務解決方案，體現出以下價值：

架構複雜度降低：分散式事務這個切面的技術問題，全部由 Seata 所提供的服務能力來解決。

設計和開發成本減輕，加快交付和迭代速度：業務邏輯的設計和開發中，若採用 AT 模式，則無需考慮是否涉及分散式事務，是否需要做額外的準備，專注 SQL 編寫實現業務邏輯即可，對業務 0 侵入 。

運營成本降低，保證業務資料準確度，以及出錯時的自動回滾和及時通知

五、總結與預告

本篇介紹了微服務架構演進，必然帶來資料不一致的問題，在一些特性場景下資料的一致性要求會很高，而大多數情況下對一致性的要求又不高，這些差異也導致了對分散式事務解決方案呈現兩種相對的顧念，一種認為可以置之不理，一種則認為必須解決，在沒有標準方案的情況下，很容易出現各顯神通，做出的東西即不通用也不健壯。

這兩種情況從標準架構規範的大局來看都非合理狀態，實際上從公司技術架構管理的角度看，需要的是

一套規範的、通用的、可靠的分散式事務解決方案

，能夠幫助開發者在分散式的環境下，既能

保證業務資料的一致性

，又不需要

投入太多的資源

用於業務資料一致性的開發維護，還能

加快迭代速度保障專案交付

。

從技術架構管理的角度看，需要一套規範的、通用的、可靠的分散式事務解決方案，幫助開發者在分散式的環境下，既能保證業務資料的一致性，又不需要投入太多的資源用於業務資料一致性的開發維護，還能加快迭代速度保障專案交付。

TAG: 分散式事務一致性業務資料