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

時間 2019-11-25

標籤分佈式事務解決方案柔性服務模式欄目系統架構简体版

原文原文鏈接

在個人博客中，介紹過不少關於分佈式和事務的文章，在閱讀本文以前，但願讀者能夠對這些基礎知識有所瞭解，這裏簡單把以前的文章列舉下，已經按照順序排好，可按順序閱讀：html

初識分佈式系統數據庫

關於分佈式一致性的探究編程

分佈式系統的CAP理論緩存

分佈式系統的BASE理論安全

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

Java中的事務——全局事務與本地事務分佈式

關於分佈式事務、兩階段提交協議、三階提交協議函數

深刻理解分佈式系統的2PC和3PC網站

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

在分佈式系統中，是沒法使用本地事務保證數據的一致性的。一種標準的分佈式事務就是全局事務（DTP模型）。他是基於2PC來控制的。可是因爲2PC自身就存在同步阻塞的問題，這也就致使全局事務效率很低。因此，這種全局事務並不適合解決大型網站的分佈式事務問題。

柔性事務

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

雖然柔性事務並不像剛性事務那樣徹底遵循ACID，可是，也是部分遵循ACID的，簡單看一下關於ACID四個屬性，柔性事務的支撐程度：

原子性：嚴格遵循

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

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

持久性：嚴格遵循

柔性事務的基礎

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

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

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

注意，下面要介紹的柔性事務的模式，並非柔性事務的方案。這些是作柔性事務的基礎。也就是說，若是你想作柔性事務，你的接口和功能要知足下面的幾個要求。不必定要都知足，由於不一樣的方案的要求不同。可是都不知足的話，是不可能作柔性事務的。

可查詢操做

可查詢操做，幾乎是全部的分佈式解決方案都須要的。

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

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

以上這個支付訂單處理的例子中，除了訂單服務本地更新訂單狀態之外的全部操做，都須要調用RPC接口來執行，這種狀況單純的本地事務就沒法保證數據的一致性了。就須要引入分佈式事務。在分佈式事務執行過程當中，若是某一個步驟執行出錯，就須要明確的知道其餘幾個操做的處理狀況，這就須要其餘的服務都可以提供查詢接口，保證能夠經過查詢來判斷操做的處理狀況。