事務就是乙個會話過程中，對上下文的影響是一致的，要麼所有的更改都做了，要麼所有的更變都撤銷掉。就要麼生，要麼死。沒有半死不死的中間不可預期狀態。
參考下薛丁格的貓。
事務是為了保障業務資料的完整性和準確性的。
分布式事務，常見的兩個處理辦法就是兩段式提交和補償。
兩段式提交典型的就是xa，有個事務協調器，告訴大家，來都準備好提交，大家回覆，都準備好了，然後協調器告訴大家，一起提交，大家都提交了。
補償比較好理解，先處理業務，然後定時或者**裡，檢查狀態是不是一致的，如果不一致採用某個策略，強制狀態到某個結束狀態（一般是失敗狀態），然後就世界太平了。典型的就是沖正操作。
準備好了以後，如果沒有問題，收到提交，所有人都開始提交。
這個時候，比如對資料庫來說，有redo日誌的。
如果某個資料庫這時候宕機了，那麼它重啟的時候，先執行檢查，也會把上一次的這些操作都提交掉的。所以各個點的資料都是一致的。
問題 1：比如 乙個業務要呼叫很多的服務都是寫操作，如果有其中乙個寫的服務失敗了，怎麼辦 ？假設 4個寫的吧，有2個寫失敗了 。
kimmking：**之類的**一般的做法是，如果4個都成功才算成功，那麼這次提交時4個寫都設定成乙個中間狀態，先容許不一致。然後4個執行完成了以後，**或是定時任務裡檢查這4個資料是不是一致的，如果一致就全部置為成功狀態，如果不一致就全部置為失敗。
複雜的業務互動過程中，不建議使用強一致性的分布式事務。解決分布式事務的最好辦法就是不考慮分布式事務。就像剛說的問題一樣，把分布式的事務過程拆解成多
個中間狀態，中間狀態的東西不允許使用者直接操作，等狀態都一致成功，或者檢測到不一致的時候全部失敗掉。就解耦了這個強一致性的過程。
一般情況下准實時就成了。涉及到錢，有時候也可以這麼搞。
**幾s內完整乙個訂單處理，不是什麼問題吧。
銀行也不是全部都強一致性。也會扎差，也會沖正。
特別是涉及到多個系統的時候，我們比如買機票，支付完成以後，只支付完成狀態，然後返回給使用者了，我們過幾分鐘再重新整理頁面，才會看到變成已出票，訂單完成狀態。
這個時候，如果我們要求所有處理，都是強一致性的，那麼久完蛋了。頁面要死在那兒幾分鐘，才把這個事務處理完成，返回給使用者。
這樣就肯定涉及乙個問題，支付了，但是最終出票沒出來。那就沒辦法，商量換票或退款。
**的訂單改成出票失敗，給支付發訊息通知退款。
慢的時候，有可能是手工出票，這時出一張票半小時都可能，如果要求都必須強一致性的話，所有處理執行緒都掛在哪兒，系統早就完蛋了。
解決分布式事務的最好辦法就是不考慮分布式事務。
拆分，大的業務流程，轉化成幾個小的業務流程，然後考慮最終一致性。
問題2：分布式事務是你們自己開發的，還是資料庫自帶的？
kimmking：
1、只要乙個處理邏輯能保證要麼成功，要麼跟什麼也沒做一樣，都算是事務。資料庫事務，mq也有事務。
你自己甚至可以寫個程式生成兩個檔案，要麼都生成了，要麼都刪掉不留痕跡，這也算是事務。
2、分布式事務這一塊有個xa規範，實現xa介面的事務，都可以加入到乙個分布式事務中，被xa容器管理起來。
3、補償的辦法，需要具體情況具體分析，沒有乙個各種場合都適用的框架。
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
聊聊分布式系統
一提起 分布式系統 大家的第一感覺就是好高大上啊，深不可測，看各類大牛關於分布式系統的演講或者書籍，也大多是一臉懵逼。本文期望用淺顯易懂的大白話來就什麼是分布式系統 分布式系統有哪些優勢 分布式系統會面臨 挑戰 如何來設計分布式等方面的話題來展開討論。關於這個定義，我們直觀的感受就是 從程序角度看，...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...