003 分布式事務解決方案存在的問題

分布式系統一致性解決方案

cap和

base

理論為基礎，我們回過頭來再去看看

q1的問題，針對訂單表和庫存表，我們可以對

每乙個步驟都去記錄其狀態，有問題時可以根據所記錄的狀態來繼續執行任務，最終達到一致性，這種方法比如使用定時任務來撈取未知的狀態進行處理即可，而下游服務只需滿足

冪等性就可以達到目的。所以還要一種理論就是酸鹼平衡理論，

就是說我們可以使用資料庫的強一致性和base理論的弱一致性結合的方式來處理分布式場景中的一些實際問題。（結合使用才是合理方案）

冪等性：一條update語句，根據id進行更新，如果產生併發請求，無論多少併發，只保證其中一條成功；在更刪改前要先查詢出版本號，再將版本號作為修改條帶入語句，完成操作後版本號+1了，其他執行緒無對應版本號就無法修改最終失敗，這就是樂觀鎖方式；

了解了acid/cap/base

這些業界著名理論以後，再來看看通常分布式服務、分布式事務，在業界中都有那些解決方案：

•兩階段提交協議

•三階段提交協議

•使用mq處理分布式業務場景

•tcc柔性事務方案

兩階段提交協議、三階段提交協議（2pc、3pc）

•jee的xa

協議是根據兩階段提交來保證事務的完整性的，並且可以實現分布式服務化的強一致性。

•兩階段提交，顧名思義分為兩個階段，乙個是準備階段，乙個是提交階段。準備和提交階段都是由另外乙個事務管理器發起的，我們可以來看乙個文章說明一下問題。

使用mq處理分布式業務場景

對於rocketmq

他是目前唯一支援分布式事物的訊息中介軟體，他是具體如何實現的呢，看一篇文章，了解下。

tcc柔性事務（不推薦，非常麻煩，不好用，開發成本過高）

tcc，對於阿里所提出的柔性事務，網上各種版本，各不一致，有的生澀難懂，閱讀之後讓其更受困擾，變得更為複雜化，在這裡我們詳細來講講

tcc的概念。

tcc你可以理解為是專門針對於分布式場景的一種實現策略或者說協議，

tcc把乙個分布式的請求任務拆分成了

try、

confirm

、cancel

三個步驟，正常的流程肯定先會執行

try，如果執行沒問題，再執行

confirm

，如果執行過程**現了超時或者異常等問題，則執行

cancel

操作。從正常的角度去想，這仍然是一種兩階段提交協議的思想，但是其好處是在執行出現問題之後有一定的自我恢復能力，如果任何參與者出現了問題則協調者通過執行操作的逆向操作來回滾之前的所有操作，從而達到最終一致狀態。當然

tcc也有它的問題所在，在極端情況下，可能出現有些參與者收到命令，有些沒有收到命令的時候，那麼系統首先就會通過自動補償的方式嘗試自動修復或者重試，如果無法修復成功則只能由人工參與解決。