概述

由於微服務架構大行其道，分散式通訊幾何級增加，必然帶來一致性問題，也就是說，以前你遇到不一致的概率可能是100年1次，現在可能是1年1次，甚至1天1次。微服務架構的前期，大多數開發者只關注拆分，選擇性忽略一致性、效能、可用性、工具鏈等問題，導致架構步履維艱，在這些問題當中，一致性是最容易被忽略的。當然，絕大多數場景並不需要那麼高的一致性，可以採用失敗重試的策略簡單處理。 從目前業界的情況來看，主要有如下幾種實現方式：

XA（2PC）

失敗重試

可靠事件

Saga

TCC

實際上很多方案都要結合業務去做，但是事務保證本身是一個通用的技術，工程師更希望抽象出來，通過簡單的配置、註解就能搞定，並且不會大幅降低效能。

下面就給大家介紹兩個開源的關於分散式事務的明日之星框架。

對比
出身
Fescar是阿里巴巴開源的分散式事務中介軟體，基於其內部的TXC和GTS的技術積累。雖然此框架非常活躍，但是19年剛剛開源，目前0.3版本，如果用於生產環境風險較大。

servicecomb-pack出自華為微服務框架servicecomb，servicecomb在Apache已經畢業了，但是一直比較“低調”。知名資料庫中間Sharding-Sphere採用的就是servicecomb-pack提供的saga方案。

實現原理

fescar實際上本質就是將一個分散式事務轉化為多個單庫事務。

沒錯，這就是Saga的思想，所有的正向操作，都保留逆向操作。一旦要回滾，只需要執行逆向操作就可以了。

如圖所示，這種方案和基於業務實現的原理比較像，就是在業務資料庫中額外增加一張事件表，這個事件表就是關鍵所在，在更新正常業務資料庫的同時，在一個單庫事務內（同一個資料庫連線）同步更新事件表，這樣來保證不丟資料。我們可以回顧一下一致性的要求，“要麼同時成功，要麼同時失敗。”單庫事務就可以保證。

如圖所示，business要去呼叫Storage和order服務，如何保證事務呢？bussiness是事務的發起者，也叫TM，Order、Storage是事務的執行者，是被呼叫的服務，也叫RM，TC負責整體協調，可以生成全域性事務ID，所有被呼叫的服務就是通過這個全域性的事務ID串聯起來的，另外，TC承擔分散式鎖的能力，這個分散式鎖主要是為了解決寫隔離，拿到鎖才有寫的權利，當然TC必須是高可用的。Storage和Order在進行業務操作的時候除了正常儲存業務資料，還要在同一個事務內實現事件表的更新，一旦出現回滾的要求，需要根據事件表生成逆向操作的SQL，並且執行回滾。

servicecomb-pack和fescar一樣，同樣是saga的思想，所有的正向操作，都保留逆向操作。一旦要回滾，只需要執行逆向操作就可以了。但是，除此之外，servicecomb-pack也支援TCC。

如圖所示，Omega作為一個客戶端，攔截所有的事務操作，事務開始向Alpha記錄開始記錄，事務結束向Alpha記錄事務結束記錄，一旦出現問題，直接在Alpha事件表中生成逆向操作，你應該已經看出來了，和fescar不同的是，事件表中的資料儲存在全域性協調者（alpha）這一側。

兩種做法各有優劣吧，存在業務側實際上是有侵入的，不是絕對意義上的無侵入，雖然單庫事務效能不錯，但是事件表的所有操作都會影響正常業務，無法做到更好的隔離性。存在協調者一側相對來說隔離性更好一些，但是這裡會有概率產生不一致，例如，實際上業務操作已經完成了，資料庫更新成功了，但是寫事件日誌可能會失敗，這時候協調者會認為業務操作也失敗了。

穩定性
servicecomb-pack略勝一籌。更早的專案。

隔離性
fescar略勝一籌。雖然並不完美，但是已有解決方案。fescar寫隔離通過TC提供的分散式鎖來實現，讀隔離通過select for update實現，當然，servicecomb-pack同樣可以通過select for update實現讀隔離。

複雜度
servicecomb-pack略勝一籌。角色少，思路簡單。業務側，兩個框架都可以通過簡單的註解實現。

文件
fescar略勝一籌。

效能
沒有實際測試，從原理上來講，相差無幾。

支援的資料庫
fescar目前只支援mysql，servicecomb-pack的方案不區分資料庫。

更詳細的內容可以參考官方文件。

總結
雖然兩個框架的目標都是讓業務開發人員更簡單，不用關心分散式事務的問題，但是在我看來，如果要使用，還是要搞清楚原理，除非對此問題非常敏感，否則，應該謹慎使用，能不用最好不用。 兩個框架都在快速發展中，從實現思想上來講非常相似，都是很好的解決方案，未來的情況主要看投入程度。

宣告：由於兩個框架都在前期快速發展的階段，案例和資料都很少，本人無法保證所有觀點的正確性，如有謬誤，請不吝賜教。

參考：

https://github.com/apache/servicecomb-pack/blob/master/docs/design_zh.md

https://gith