聊聊分布式事務

事務就是一個會話過程中，對上下文的影響是一致的，要么所有的更改都做了，要么所有的更變都撤銷掉。就要么生，要么死。沒有半死不死的中間不可預期狀態。

參考下薛定諤的貓。

事務是為了保障業務數據的完整性和準確性的。

分布式事務，常見的兩個處理辦法就是兩段式提交和補償。
兩段式提交典型的就是XA，有個事務協調器，告訴大家，來都準備好提交，大家回復，都準備好了，然后協調器告訴大家，一起提交，大家都提交了。
補償比較好理解，先處理業務，然后定時或者回調里，檢查狀態是不是一致的，如果不一致采用某個策略，強制狀態到某個結束狀態（一般是失敗狀態），然后就世界太平了。典型的就是沖正操作。

準備好了以后，如果沒有問題，收到提交，所有人都開始提交。
這個時候，比如對數據庫來說，有redo日志的。
如果某個數據庫這時候宕機了，那么它重啟的時候，先執行檢查，也會把上一次的這些操作都提交掉的。所以各個點的數據都是一致的。

問題 1：比如 一個業務要調用很多的服務都是寫操作，如果有其中一個寫的服務失敗了，怎么辦 ？假設 4個寫的吧，有2個寫失敗了 。

kimmking：淘寶之類的網站一般的做法是，如果4個都成功才算成功，那么這次提交時4個寫都設置成一個中間狀態，先容許不一致。然后4個執行完成了以后，回調或是定時任務里檢查這4個數據是不是一致的，如果一致就全部置為成功狀態，如果不一致就全部置為失敗。

復 雜的業務交互過程中，不建議使用強一致性的分布式事務。解決分布式事務的最好辦法就是不考慮分布式事務。就像剛說的問題一樣，把分布式的事務過程拆解成多 個中間狀態，中間狀態的東西不允許用戶直接操作，等狀態都一致成功，或者檢測到不一致的時候全部失敗掉。就解耦了這個強一致性的過程。

一般情況下準實時就成了。涉及到錢，有時候也可以這么搞。
淘寶幾s內完整一個訂單處理，不是什么問題吧。
銀行也不是全部都強一致性。也會扎差，也會沖正。

特別是涉及到多個系統的時候，我們比如買機票，支付完成以后，只支付完成狀態，然后返回給用戶了，我們過幾分鐘再刷新頁面，才會看到變成已出票，訂單完成狀態。
這個時候，如果我們要求所有處理，都是強一致性的，那么久完蛋了。頁面要死在那兒幾分鐘，才把這個事務處理完成，返回給用戶。

這樣就肯定涉及一個問題，支付了，但是最終出票沒出來。那就沒辦法，商量換票或退款。
淘寶的訂單改成出票失敗，給支付發消息通知退款。

慢的時候，有可能是手工出票，這時出一張票半小時都可能，如果要求都必須強一致性的話，所有處理線程都掛在哪兒，系統早就完蛋了。

解決分布式事務的最好辦法就是不考慮分布式事務。

拆分，大的業務流程，轉化成幾個小的業務流程，然后考慮最終一致性。

問題2：分布式事務是你們自己開發的，還是數據庫自帶的？

kimmking：

1、只要一個處理邏輯能保證要么成功，要么跟什么也沒做一樣，都算是事務。數據庫事務，MQ也有事務。
你自己甚至可以寫個程序生成兩個文件，要么都生成了，要么都刪掉不留痕跡，這也算是事務。
2、分布式事務這一塊有個XA規范，實現XA接口的事務，都可以加入到一個分布式事務中，被XA容器管理起來。

3、補償的辦法，需要具體情況具體分析，沒有一個各種場合都適用的框架。