分佈式事物-柔性事物簡介

在支付寶架構與技術 中對柔性事務有大體的描述：

 

能夠看出，柔性事務（遵循BASE理論）是指相對於ACID剛性事務而言的。
支付寶所說的柔性事務分爲：兩階段型、補償型、異步確保型、最大努力通知型幾種。
因爲支付寶整個架構是SOA架構，所以傳統單機環境下數據庫的ACID事務知足了分佈式環境下的業務須要，以上幾種事務相似就是針對分佈式環境下業務須要設定的。
其中：
一、兩階段型：就是分佈式事務兩階段提交，對應技術上的XA、JTA/JTS。
這是分佈式環境下事務處理的典型模式。

二、補償型：
TCC型事務（Try/Confirm/Cancel）能夠歸爲補償型。
補償型的例子，在一個長事務（ long-running ）中 ，一個由兩臺服務器一塊兒參與的事務，服務器A發起事務，服務器B參與事務，B的事務須要人工參與，因此處理時間可能很長。若是按照ACID的原則，要保持事務的隔離性、一致性，服務器A中發起的事務中使用到的事務資源將會被鎖定，不容許其餘應用訪問到事務過程當中的中間結果，直到整個事務被提交或者回滾。這就形成事務A中的資源被長時間鎖定，系統的可用性將不可接受。
WS-BusinessActivity提供了一種基於補償的long-running的事務處理模型。仍是上面的例子，服務器A的事務若是執行順利，那麼事務A就先行提交，若是事務B也執行順利，則事務B也提交，整個事務就算完成。可是若是事務B執行失敗，事務B自己回滾，這時事務A已經被提交，因此須要執行一個補償操做，將已經提交的事務A執行的操做做反操做，恢復到未執行前事務A的狀態。這樣的SAGA事務模型，是犧牲了必定的隔離性和一致性的，可是提升了long-running事務的可用性。
例子來源：OASIS的WS-BusinessActivity文檔

三、異步確保型
將一些同步阻塞的事務操做變爲異步的操做，避免對數據庫事務的爭用，典型例子是熱點帳戶異步記帳、批量記帳的處理。

四、最大努力型
PPT中提到的例子交易的消息通知（例如商戶交易結果通知重試、補單重試）

若是有技術背景，能夠參考另一個文檔 大規模SOA系統中的分佈事務處事 ，對支付寶分佈式事務處理機制有較爲詳細描述。
更詳細的也能夠參考OASIS的相關資料。