CAP 定理
CAP 必須滿足以下的 3 個屬性：
一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
分區容錯性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在 C 和 A 之間做出選擇。
簡單的來說，在一個分布式系統中，最多能支持上面的兩種屬性。但顯然既然是分布式注定我們是必然要進行分區，既然分區，我們就無法百分百避免分區的錯誤。因此，我們只能在一致性和可用性去作出選擇。
在分布式系統中，我們往往追求的是可用性，它的重要性比一致性要高，那么如何實現高可用，這里又有一個理論，就是 BASE 理論，它給 CAP 理論做了進一步的擴充。
BASE 理論
Basically Available（基本可用）
Soft state（軟狀態）
Eventually consistent（最終一致性）
BASE 理論是對 CAP 中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性。
MQ消息事務-RocketMQ
先說說MQ的分布式事務，RocketMq在4.3版本已經正式宣布支持分布式事務，在選擇Rokcetmq做分布式事務請務必選擇4.3以上的版本。
事務消息作為一種異步確保型事務， 將兩個事務分支通過 MQ 進行異步解耦，RocketMQ 事務消息的設計流程同樣借鑒了兩階段提交理論，整體交互流程如下圖所示：
這個時候我們基本可以認為，只有MQ發送方自己的本地事務執行完畢，那么MQ的訂閱方必定百分百能夠接收到消息，我們再對下單減庫存的步驟進行改造：
這里涉及到一個異步化的改造，我們理一下如果是同步流程中的各個步驟
查看商品詳情（或購物車）
計算商品價格和目前商品存在庫存（生成訂單詳情）
商品扣庫存（調用商品庫存服務）
訂單確認（生成有效訂單）
訂單創建完成后，發布一個事件“orderCreate” 到消息隊列中，然后由MQ轉發給訂閱該消息的服務，因為是基於消息事務，我們可以認為訂閱該消息的商品模塊是百分百能收到這個消息的。
商品服務接受到orderCreate消息后就執行扣減庫存的操作，注意，這里可能會有一些不可抗的因素導致扣減庫存失敗，無論成功或失敗，商品服務都將發送一個扣減庫存結果的消息“stroeReduce”到消息隊列中，訂單服務會訂閱扣減庫存的結果。
訂單服務收到消息后有兩種可能：
如果扣減庫存成功，將訂單狀態改為 “確認訂單” ，下單成功
如果扣減庫存失敗，將訂單狀態改為 “失效訂單” ，下單失敗
這種模式將確認訂單的流程變成異步化，非常適合在高並發的使用，但是，切記了，這個需要前端用戶體驗的一些改變，要配合產品來涉及流程。
完美，使用MQ分布式事務就可以解決調一致性問題
MQ消息事務方案的風險了解一下
上面使用MQ的方式確實是可以完成A和B操作，但是A和B並不是嚴格一致性，而是最終一致性，我們犧牲掉嚴格一致性，換來性能的提升，這種很適合在大促高並發場景總使用，但是如果B一直執行不成功，那么一致性也會被破壞，后續應該考慮到更多的兜底方案，方案越細系統就將越復雜。