分布式事務分析

近期公司專案基於微服務架構需要涉及到實現一套分布式事務。經過幾天在網上查閱資料發現大部分文章只是講解了具體的其中乙個模型。因此在這裡做乙個總結+自己的一些感悟和看法。

cap理論乙個核心論證就是p(分割槽容錯性)作為乙個分布式系統是肯定包含的。因此實際實現只是在cp和ap之間做抉擇。

cp：為了保證一致性和分割槽容錯性，那麼肯定會喪失一部分可用性。

ap：為了保證可用性和分割槽容錯性，那麼肯定會喪失一部分一致性。

acid原則是用來描述乙個事務應該包含的特性。原子性、一致性、隔離性、永續性。這個原則實際上和cap理論是相悖的。

我們來假設乙個簡單的支付場景，生成訂單--->扣使用者積分--->核銷優惠劵--->修改訂單狀態。這裡涉及三個系統，訂單系統、使用者積分系統、優惠劵系統。那麼如果我們要保證事務的一致性，我們在其中的每一步都會將資源鎖定，然後只有在最終事務全部完成後，我們才能釋放鎖。那麼在整個事務週期內我們的功能必定是處於不可用狀態。這也正符合cp定義。這麼做的事務確實可以保證事務的acid原則，但是因為鎖定時間長、鎖粒度大(鎖定資源多)，在高併發的情況下，並不適用。這一類強一致性事務，稱為剛性事務。

mysql在5.6之前就支援了xa協議，允許使用剛性事務。當然mysql僅僅是支援了協議，提供了介面。xa協議中的2pc(2階段提交)模型中的全域性管理者和參與者還是需要自己實現。

剛性事務既然不符合常用的場景，那麼我們就只能犧牲一部分一致性，保證最終一致性。也就是base理論基本可用、軟狀態、最終一致性。這一類事務稱為柔性事務，常見的模型有兩類，tcc模型：try-confirm-cancel。基於訊息系統的實現：最大努力通知型、可靠訊息型。

在真正的開始使用、實現分布式事務前，我們先要確定自己的需求真的需要乙個分布式事務才可以實現嗎？依然是之前的場景：生成訂單--->扣使用者積分--->核銷優惠劵--->修改訂單狀態。

當然其中的每一步都是乙個區域性本地的事務，執行下一步操作之前，當前的本地事務肯定是已經完成了，那麼回滾當然不能簡單的rollback()就可以了。其實可以每乙個步驟實現乙個回退的介面。當出現需要回滾的情況時候，由最上層的發起方依次呼叫指定服務的回退介面就可以了。

這種實現實際上完全base理論，從出現問題到全部回滾完之前的中間狀態下，資料確實是不一致的，但是回滾之後就是符合最終一致性的。根據前文所說的cap理論，在分布式系統下你是不可能保證資料的強一致性的！！！。因此，如果你使用分布式事務是簡單的任務能滿足強一致性，推薦你使用剛性事務實現。

通過之前的分析，其實同步場景下只需要通過上層呼叫實現的回滾介面就可以避免使用分布式事務，那麼這種柔性事務還有什麼意義呢？所謂的tcc模型、訊息模型還有什麼意義呢？我的理解是雖然同步呼叫情況下可以通過前文所說避免柔性事務，但是還是可能有完全不一致的情況出現。

首先就是上層呼叫方直接掛掉了。整個呼叫鏈斷掉了。這種情況下當然可以通過監控、校對來進行干預。

第二種情況我認為就是對**結構的封裝了，如果每乙個類似的呼叫鏈都需要開發者自己去手動判斷+呼叫回滾，容易遺漏、出錯，並且破壞**結構。這種情況下使用乙個統一的分布式事務將事務間的關聯管理起來，回滾等操作都呼叫方來說都不透明似乎是乙個很好的選擇。

因此根據你的實際需求，分析是否真的需要使用柔性事務，是否可以直接通過呼叫鏈的方式避免使用分布式事務系統。

分布式 分布式事務

是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...

分布式事務分析總結

分布式事務用於分布式系統中主要是為了確保不同節點的資料一致性，分布式事務有很多，最具代表性的就是oracre提出的xa分布式事務 分布式系統分為兩階段提交和三階段提交，這裡我們主要說一下兩階段提交。兩階段提交主要有三個部分主動方應用 訊息中介軟體 被動方應用，分布式事務主要是為解決資料不一致的問題。...

分布式事務 分布式事務的實現

如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...