分佈式事務實現方案阿里巴巴fescar、華爲servicecomb-pack對比分析

概述

因爲微服務架構大行其道，分佈式通訊幾何級增長，必然帶來一致性問題，也就是說，之前你遇到不一致的機率多是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://github.com/alibaba/fescar