指事務的操作位於不同的節點上，需要保證事務的 aicd 特性。
例如：你下單，要走訂單服務和庫存服務，如何確保事務的正確執行
事務具有4個特徵，原子性，一致性，隔離性，永續性
原子性：要麼都執行，要麼都不執行
一致性：事務不能不一部分執行成功，一部分執行不成功，導致資料不一致
隔離性：乙個事務要操作的資料，不要被另乙個事務同時操作
永續性：一但事務提交，那將永久修改資料庫的資料
c：一致性：所有節點存入資料，返回響應
a：高可用：某個節點存入資料，返回響應
p：分割槽容錯性：某乙個節點掛了，還可以有其他節點可以使用
ba：基本可用：出現錯誤，還可以對外提供服務
s：軟狀態：中間狀態
e：資料一致性，中間狀態存在有時間期限，一道期限，必須保證資料一致性
第一階段：讓每個參與者執行sql，如果都執行成功，則到第二階段提交，如不成功，進行回滾
第二階段：進行commit操作（這一部分無法解決commit時，有服務出現錯誤的情況）
缺點：commit的時候發生網路故障（某一服務沒有commit），導致資料不一致
再等待所有參與者響應時，所有的參與者都是阻塞狀態
重點：3個方法（try，確認，補償），字段新增了乙個中間狀態和乙個預留字段（用於存減了多少庫存，或者減去/加上某某值）
例子：我們買了2件衣服
物品id
物品名稱
庫存狀態
預留欄位1衣服
20未更新
0首先我們先呼叫try方法，作用：看庫存夠不夠，把這一行資料的狀態改為更新中，再預留欄位中存入我們要減的庫存
物品id
物品名稱
庫存狀態
預留欄位1衣服
20更新中
2更新狀態就不能被其他操作
然後執行sql，commit，如果都成功了，呼叫確認方法，進行狀態的更新，預留欄位的值變為0
物品id
物品名稱
庫存狀態
預留欄位1衣服
18已更新
0如果有乙個沒有執行成功，那麼就會呼叫補償方法，進行狀態的更新，預留欄位的值變為0
物品id
物品名稱
庫存狀態
預留欄位1衣服
20已取消
0重點：
保證生產者能將訊息傳到mq（訊息確認機制）
mq能夠正常的被生產者消費（訊息確認機制，重試機制）
不能被重複消費（將訊息id放到redis中）
最終實現資料最終一致
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...