在
支付寶架構與技術
中對柔性事務有大致的描述：
可以看出，柔性事務（遵循base理論）是指相對於acid剛性事務而言的。
支付寶所說的柔性事務分為：兩階段型、補償型、非同步確保型、最大努力通知型幾種。
由於支付寶整個架構是soa架構，因此傳統單機環境下資料庫的acid事務滿足了分布式環境下的業務需要，以上幾種事務類似就是針對分布式環境下業務需要設定的。
其中：1、兩階段型：就是分布式事務兩階段提交，對應技術上的xa、jta/jts。
這是分布式環境下事務處理的典型模式。
2、補償型：
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事務的可用性。
3、非同步確保型
將一些同步阻塞的事務操作變為非同步的操作，避免對資料庫事務的爭用，典型例子是熱點賬戶非同步記賬、批量記賬的處理。
4、最大努力型
ppt中提到的例子交易的訊息通知（例如商戶交易結果通知重試、補單重試）
如果有技術背景，可以參考另外乙個文件
大規模soa系統中的分布事務處事
，對支付寶分布式事務處理機制有較為詳細描述。
App 中的 微信支付 支付寶支付
返回的事件 function weixinpay data else if document.attachevent else onbridgeready function res vm.number null vm.router.go 1 vm.base url index.html deposi...
App 中的 微信支付 支付寶支付
返回的事件 function weixinpay data else if document.attachevent else onbridgeready function res vm.number null vm.router.go 1 vm.base url index.html deposi...
揭秘支付寶中的深度學習引擎 xNN
深度學習 雲端還是移動端?近來，深度學習 dl 在影象識別 語音識別 自然語言處理等諸多領域都取得了突破性進展。dl通常給人以計算複雜 模型龐大的印象 從siri語音助手到各種聊天機械人 再到支付寶 掃五福 移動端收集資料 雲端加工處理似乎成為一種常識。然而對很多應用來說，這種模式其實只是無奈之選。...