轉載自? ?分布式事務解決方案——柔性事務與服務模式

初識分布式系統

關于分布式一致性的探究

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

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

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

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

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

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

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

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

?

柔性事務

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

雖然柔性事務并不像剛性事務那樣完全遵循ACID，但是，也是部分遵循ACID的，簡單看一下關于ACID四個屬性，柔性事務的支撐程度：

原子性：嚴格遵循

一致性：事務完成后的一致性嚴格遵循；事務中的一致性可適當放寬

隔離性：并行事務間不可影響；事務中間結果可見性允許安全放寬

持久性：嚴格遵循

?

?

柔性事務的基礎

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

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

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

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

可查詢操作

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

舉一個常見的分布式場景的例子，如訂單處理這一功能：

/**?支付訂單處理?**/ public?void?completeOrder()?{orderDao.update();?//?訂單服務本地更新訂單狀態accountService.update();?//?調用資金賬戶服務給資金帳戶加款pointService.update();?//?調用積分服務給積分帳戶增加積分accountingService.insert();?//?調用會計服務向會計系統寫入會計原始憑證merchantNotifyService.notify();?//?調用商戶通知服務向商戶發送支付結果通知 }

以上這個支付訂單處理的例子中，除了訂單服務本地更新訂單狀態以外的所有操作，都需要調用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操作。后續文章會分別介紹關于分布式事務的解決方案，敬請期待。

總結

以上是生活随笔為你收集整理的分布式事务解决方案——柔性事务与服务模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。