分佈式事務精華總結篇

-     總述     -

咱們前面分別對分佈式事務的幾個分支:XA、2PC、3PC、TCC、Saga、事務消息、最大努力事務進行的詳細介紹。本篇作爲分佈式事務設計的收尾篇,講對前面的內容查缺補漏和總結,最後對市面的一些開源框架做一些介紹。

 

-     查缺補漏     -

1. 補償型事務

柔性事務分補償型事務和通知型事務。但對補償型事務沒有進行詳細介紹,那什麼是補償型事務呢,在Atomikos 公司Guy Pardon的論文《Business_Activities》中有這樣的描述:

 

大致含義是,"補償是一個獨立的支持ACID特性的本地事務,用於在邏輯上取消了先前ACID交互的影響。對於一個長事務來說,基於補償的方法可將事務資源鎖定時間保持在最低程度,從而避免了事務資源長期佔用等缺點。”。

2.TCC事務模型補充

咱們前面文章說了不推薦TCC,並且認爲Seata的AT模式從理論上來說更像是Saga的變種,而非TCC的變種。目前有很多資料自行將TCC分了幾個分支:

  • 通用型TCC:標準TCC模型實現,從業務服務需要提供try、confirm、cancel

  • 補償性TCC:子服務只需要提供 Do 和 Compensate 兩個接口

  • 異步確保型 TCC:主服務是可靠消息服務,而子服務則通過消息服務解耦,作爲消息服務的消費端,異步地執行。可靠消息服務需要提供 Try、Confirm、Cancel 三個接口。Try 接口只負責持久化記錄存儲消息數據;Confirm 接口確認發送,這時纔開始真正的投遞消息;Cancel 接口取消發送,刪除消息數據。

原始論文《Life beyond Distributed Transactions》和 Atomikos 官網上並沒有類似的劃分,這些劃分其實是一些公司在內部實踐中,自行提出的概念。但是並未找到比較大的公司進行背書。所以其實咱們從論文上去看:

  • 補償性TCC並未提供Try接口,其實已經更接近Saga了,反而應該認爲是Saga的變種。

  • 異步確保型 TCC中 子服務不需要提供try、confirm、cancel三個接口,稱爲TCC貌似也不合適,從本質上其實事務消息的一種可靠投遞方式而已。

3. Saga 事務模型補充 

咱們說過Saga設計必須遵循允許空補償保持冪等性防止資源懸掛三個策略,因爲Saga事務不保證隔離性,在極端情況下可能由於髒寫無法完成回滾操作。比如舉一個極端的例子, 分佈式事務內先給用戶A充值, 然後給用戶B扣減餘額, 如果在給A用戶充值成功, 在事務提交以前, A用戶把餘額消費掉了, 如果事務發生回滾, 這時則沒有辦法進行補償了。這就是缺乏隔離性造成的典型的問題, 實踐中一般的應對方法是:

  • 業務流程設計時遵循“寧可長款, 不可短款”的原則, 長款意思是客戶少了錢機構多了錢, 以機構信譽可以給客戶退款, 反之則是短款, 少的錢可能追不回來了。所以在業務流程設計上一定是先扣款。

  • 有些業務場景可以允許讓業務最終成功, 在回滾不了的情況下可以繼續重試完成後面的流程, 所以要求Saga除了提供“回滾”能力還需要提供“向前”恢復上下文繼續執行的能力, 讓業務最終執行成功, 達到最終一致性的目的。

Saga 實現分兩種,一種是Saga 狀態機實現,一種是Saga AOP Proxy實現,但是前文缺少對比,補充如下:

Saga 狀態機實現,在關於參與者服務編排實現又有集中式和協同式兩種分支,他們的對比詳情如下:

 4.TCC VS Saga 

補償型事務事務主要分TCC 和 Saga。咱們前文中說到Saga 沒有Try行爲,直接commit,所以會留下原始事務操作痕跡。TCC Cancel是完美補償的Rollback,補償操作會徹底清理之前的原始事務操作,用戶是感知不到事務取消之前的狀態信息的。最近回看文章時,發現比較多人對此有疑問,所以進行補充詮釋下:

  • 從業務流程上說,TCC的Try行爲是嘗試階段, Comfirm 和Cannel是確認/回滾。是兩階段的廣義實現,在頁面表現上可以使用定時回查結果,那麼對客戶的說就是完美補償行爲。而Saga直接commit,在業務流程上存在的客戶感官上的髒讀現象。

 

  • 在數據層面上來說,TCC利用了數據的中間態,Cannel針對中間臺數據進行回滾,從而不存在數據污染問題;而Saga使用的是反向操作,存在數據變化記錄影響,有數據污染嫌疑。

 

TCC 和Saga 的對比 補充一個適用場景的相關對比信息:

  • TCC 適用於執行時間確定且較短、對一致性要求比較高、數據隔離強的業務,比如支付場景。

 

  • Saga 適用於業務流程長、業務流程多的業務,在銀行業金融機構使用廣泛。比如互聯網微貸、渠道整合場景

 

-     總結     -

單數據庫事務可以滿足事務ACID 四個特性,提供強一致性保證,但在分佈式事務要完全遵循 ACID 特性會比較困難。在互聯網時代中,我們通常追求分佈式系統的高可用和高吞吐,所以分佈式事務一般選擇最終一致性。

咱們把提供強一致性的事務稱之爲剛性事務,把提供最終一致性的事務稱之爲柔性事務。剛性事務可以完全滿足 ACID 四個特性,柔性事務對事務的 ACID 特性的支持情況如下:

  • 原子性:完全支持。

  • 一致性:只提供最終一致性支持。

  • 隔離性:不完全保證,通常爲了系統的吞吐和性能,會一定程度上放棄對隔離性的要求。

  • 持久性:完全支持。

在分佈式系統中,CAP理論通常是指導思維,而BASE理論是CAP理論中的AP延申,是對 CAP 中的一致性和可用性進行一個權衡的結果,理論的核心思想就是:我們無法做到強一致,但每個應用都可以根據自身的業務特點,採用適當的方式來使系統達到最終一致性。而柔性事務其實就是BASE理論的實踐產物。

因爲分佈式事務難免會對系統造成一定的性能損耗,所以在互聯網高可用和高吞吐的要求下。我們通常處理分佈式事務的原則是:業務規避 > BASE柔性事務 > CP剛性事務。柔性事務通常推薦 同步Saga、異步事務消息;剛性事務推薦 2PC實現。

 

-     開源框架推薦     -

從結論上我們可以看出業務規避其實已經沒有了分佈式事務的必要性,因此如果實在無法業務規避或者規避成本更加昂貴下,我們必須有分佈式事務來處理數據一致性問題。這時我們需要選擇一個合適的分佈式框架來處理事務。我對業界常見分佈式事務做了一定比較,其實有大廠背景背書、經過大量生產實踐、開源組件的只有華爲的ServiceComb Saga、阿里的Seata、Apache Camel Saga。但是華爲ServiceComb Saga和 Apache Camel Saga只提供了Saga實現,而阿里Seata提供了AT、Saga、XA(剛出不久,不建議馬上使用)。從廣度上來說,其實Seata是佔比較大的優勢,我剛好對Seata又有比較深的研究,所以強烈推薦Seata

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章