分散式事務的典型處理方式:2PC、TCC、非同步確保和最大努力型
1. 柔性事務和剛性事務
柔性事務滿足BASE理論（基本可用，最終一致）
剛性事務滿足ACID理論
本文主要圍繞分散式事務當中的柔性事務的處理方式進行討論。
柔性事務分為
- 兩階段型
- 補償型
- 非同步確保型
- 最大努力通知型幾種。 由於支付寶整個架構是SOA架構，因此傳統單機環境下資料庫的ACID事務滿足了分散式環境下的業務需要，以上幾種事務類似就是針對分散式環境下業務需要設定的。
2. 兩階段提交（2PC）型
兩階段型：就是分散式事務兩階段提交，對應技術上的XA、JTA/JTS。
這是分散式環境下事務處理的典型模式。
2、事務補償型（TCC事務）：
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文件
3、非同步確保型
將一些同步阻塞的事務操作變為非同步的操作，避免對資料庫事務的爭用，典型例子是熱點賬戶非同步記賬、批量記賬的處理。
4、最大努力型
PPT中提到的例子交易的訊息通知（例如商戶交易結果通知重試、補單重試）
如果有技術背景，可以參考另外一個文件 大規模SOA系統中的分佈事務處事 ，對支付寶分散式事務處理機制有較為詳細描述。
更詳細的也可以參考OASIS的相關資料。
參考資料：
https://www.zhihu.com/question/31813039（樑川）
支付寶架構與技術
大規模SOA系統中的分散式事務處理
from: http://kaimingwan.com/post/fen-bu-shi/fen-bu-shi-shi-wu-de-dian-xing-chu-li-fang-shi-2pc-tcc-yi-bu-que-bao-he-zui-da-nu-li-xing