1. 程式人生 > >分布式事務解決方案——柔性事務與服務模式

分布式事務解決方案——柔性事務與服務模式

會有 相同 順序 大型 協調 信息 解決 查詢接口 增加

在我的博客中,介紹過很多關於分布式和事務的文章,在閱讀本文之前,希望讀者可以對這些基礎知識有所了解,這裏簡單把之前的文章列舉下,已經按照順序排好,可按順序閱讀。

初識分布式系統

關於分布式一致性的探究

分布式系統的CAP理論(需要到博客中查看)

分布式系統的BASE理論(需要到博客中查看)

Java中的事務——JDBC事務和JTA事務

Java中的事務——全局事務與本地事務

關於分布式事務、兩階段提交協議、三階提交協議

深入理解分布式系統的2PC和3PC

這裏簡單總結下以前幾篇文章,算是本文的背景知識。在分布式系統中,存在CAP理論,即可用性、數據一致性和分區容錯性無法同時滿足。所以,一個基於CAP的最終一致性理論BASE理論是目前解決分布式問題比較靠譜的。

在分布式系統中,是無法使用本地事務保證數據的一致性的。一種標準的分布式事務就是全局事務(DTP模型)。他是基於2PC來控制的。但是由於2PC自身就存在同步阻塞的問題,這也就導致全局事務效率很低。所以,這種全局事務並不適合解決大型網站的分布式事務問題。

柔性事務

在業內,主要用來解決分布式事務的方案是使用柔性事務。所謂柔性事務,相比較與數據庫事務中的ACID這種剛性事務來說,柔性事務保證的是“基本可用,最終一致。”這其實就是基於BASE理論,保證數據的最終一致性。

雖然柔性事務並不像剛性事務那樣完全遵循ACID,但是,也是部分遵循ACID的,簡單看一下關於ACID四個屬性,柔性事務的支撐程度:技術分享圖片


柔性事務的基礎

前面介紹過了柔性事務的定義,目前,在業內,關於柔性事務,最主要的有以下三種類型:異步確保型、補償型、最大努力通知型。

這三種類型的柔性事務基本都有對應的實現,不同的場景需要使用不同的柔性事務類型。而這幾種柔性事務類型,其實還是依賴一些基礎模式的,或者叫做基礎接口,基礎功能。

比如,要想使用可靠消息最終一致來實現異步確保型柔性事務,就依賴接冪等操作和可查詢操作。關於具體實現,我們在後面的文章中介紹,本文簡單介紹下這些實現柔性事務依賴的基礎模式。

註意,下面要介紹的柔性事務的模式,並不是柔性事務的方案。這些是做柔性事務的基礎。也就是說,如果你想做柔性事務,你的接口和功能要滿足下面的幾個要求。不一定要都滿足,因為不同的方案的要求不一樣。但是都不滿足的話,是不可能做柔性事務的。

可查詢操作

可查詢操作,幾乎是所有的分布式解決方案都需要的。

舉一個常見的分布式場景的例子,如訂單處理這一功能:
技術分享圖片

以上這個支付訂單處理的例子中,除了訂單服務本地更新訂單狀態以外的所有操作,都需要調用RPC接口來執行,這種情況單純的本地事務就無法保證數據的一致性了。就需要引入分布式事務。在分布式事務執行過程中,如果某一個步驟執行出錯,就需要明確的知道其他幾個操作的處理情況,這就需要其他的服務都能夠提供查詢接口,保證可以通過查詢來判斷操作的處理情況。
技術分享圖片

為了保證操作的可查詢,需要對於每一個服務的每一次調用都有一個全局唯一的標識,可以是業務單據號(如訂單號)、也可以是系統分配的操作流水號(如支付記錄流水號)。除此之外,操作的時間信息也要有完整的記錄。

冪等操作

冪等性,其實是一個數學概念。冪等函數,或冪等方法,是指可以使用相同參數重復執行,並能獲得相同結果的函數,如:

f(f(x)) = f(x)

在編程中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。也就是說,同一個方法,使用同樣的參數,調用多次產生的業務結果與調用一次產生的業務結果相同。

技術分享圖片
這一個要求其實也比較好理解,因為要保證數據的最終一致性,很多解決防範都會有很多重試的操作,如果一個方法不保證冪等,那麽將無法被重試。

冪等操作的實現方式有多種,如在系統中緩存所有的請求與處理結果、檢測到重復操作後,直接返回上一次的處理結果等。

可補償操作

提到事務,為了保證原子性,就可能發生commit和rollback,那麽在分布式事務中,要想進行rollback,就需要提供可補償操作。
技術分享圖片

比如上面的訂單處理的例子中,在調用積分服務給積分帳戶增加積分操作執行之後,經過分布式事務協調,最終決定回滾整個事務,那麽就需要提供一個調用積分服務給積分帳戶扣減積分的操作。

並且,補償操作同時也需要滿足冪等性。

TCC操作

TCC 即 Try-Confirm-Cancel。

技術分享圖片
Try: 嘗試執行業務

完成所有業務檢查(一致性) 預留必須業務資源(準隔離性)

Confirm:確認執行業務

真正執行業務 不作任何業務檢查 只使用Try階段預留的業務資源 Confirm操作要滿足冪等性

Cancel: 取消執行業務

釋放Try階段預留的業務資源

Cancel操作要滿足冪等性

這種類型和可補償操作類似,就是提供一種提交和回滾的機制。是一種典型的兩階段類型的操作。這裏說的兩階段類型操作並不是指2PC,他和2PC還是有區別的。

TCC與2PC協議比較

TCC位於業務服務層而非資源層

TCC沒有單獨的準備(Prepare)階段,Try操作兼備資源操作與準備能力 ? Try操作可以靈活選擇業務資源的鎖定粒度(以業務定粒度)

TCC有較高開發成本

總結

本文主要是簡單介紹了一下柔性事務和柔性事務實現的基礎。柔性事務是目前主流的分布式事務解決方案,其基礎模式包含四個:冪等操作、可補償操作、可查詢操作和TCC操作。後續文章會分別介紹關於分布式事務的解決方案,敬請期待。

分布式事務解決方案——柔性事務與服務模式