前言

我們都在討論分散式，特別是面試的時候，不管是招初級軟體工程師還是高階，都會要求懂分散式，甚至要求用過。傳得沸沸揚揚的分散式到底是什麼東東，有什麼優勢？

借用火影忍術

看過火影的同學肯定知道漩渦鳴人的招牌忍術：多重影分身之術。

• 這個術有一個特別厲害的地方，過程和心得：多個分身的感受和經歷都是相通的。比如 A 分身去找卡卡西（鳴人的老師）請教問題，那麼其他分身也會知道 A 分身問的什麼問題。
• 漩渦鳴人有另外一個超級厲害的忍術，需要由幾個影分身完成：風遁·螺旋手裡劍。這個忍術是靠三個鳴人一起協作完成的。

這兩個忍術和分散式有什麼關係？

• 分佈在不同地方的系統或服務，是彼此相互關聯的。

• 分散式系統是分工合作的。

案例：

• 比如 Redis 的哨兵機制，可以知道叢集環境下哪臺 Redis 節點掛了。
• Kafka的 Leader 選舉機制，如果某個節點掛了，會從 follower 中重新選舉一個 leader 出來。（leader 作為寫資料的入口，follower 作為讀的入口）

那多重影分身之術有什麼缺點？

• 會消耗大量的查克拉。分散式系統同樣具有這個問題，需要幾倍的資源來支援。

對分散式的通俗理解

• 是一種工作方式
• 若干獨立計算機的集合，這些計算機對於使用者來說就像單個相關係統
• 將不同的業務分佈在不同的地方

優勢可以從兩方面考慮：一個是宏觀，一個是微觀。

• 宏觀層面：多個功能模組糅合在一起的系統進行服務拆分，來解耦服務間的呼叫。
• 微觀層面：將模組提供的服務分佈到不同的機器或容器裡，來擴大服務力度。

任何事物有陰必有陽，那分散式又會帶來哪些問題呢？

• 需要更多優質人才懂分散式，人力成本增加
• 架構設計變得異常複雜，學習成本高
• 運維部署和維護成本顯著增加
• 多服務間鏈路變長，開發排查問題難度加大
• 環境高可靠性問題
• 資料冪等性問題
• 資料的順序問題
• 等等

講到分散式不得不知道 CAP 定理和 Base 理論，這裡給不知道的同學做一個掃盲。

CAP 定理

在理論電腦科學中，CAP 定理指出對於一個分散式計算系統來說，不可能通是滿足以下三點：

• 一致性（Consistency）
• 所有節點訪問同一份最新的資料副本。
• 可用性（Availability）
• 每次請求都能獲取到非錯的響應，但不保證獲取的資料為最新資料
• 分割槽容錯性（Partition tolerance）
• 不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在 C 和 A 之間做出選擇）

BASE 理論

BASE 是 Basically Available（基本可用）、Soft state（軟狀態）和 Eventually consistent（最終一致性）三個短語的縮寫。BASE 理論是對 CAP 中 AP 的一個擴充套件，透過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許資料在一段時間內是不一致的，但最終達到一致狀態。滿足 BASE 理論的事務，我們稱之為柔性事務。

• 基本可用 ： 分散式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。如電商網址交易付款出現問題來，商品依然可以正常瀏覽。
• 軟狀態： 由於不要求強一致性，所以BASE允許系統中存在中間狀態（也叫軟狀態），這個狀態不影響系統可用性，如訂單中的“支付中”、“資料同步中”等狀態，待資料最終一致後狀態改為“成功”狀態。
• 最終一致性： 最終一致是指的經過一段時間後，所有節點資料都將會達到一致。如訂單的“支付中”狀態，最終會變為“支付成功”或者“支付失敗”，使訂單狀態與實際交易結果達成一致，但需要一定時間的延遲、等待。

一、分散式訊息佇列的坑

訊息佇列如何做分散式？

將訊息佇列裡面的訊息分攤到多個節點（指某臺機器或容器）上，所有節點的訊息佇列之和就包含了所有訊息。

1. 訊息佇列的坑之非冪等

冪等性概念

所謂冪等性就是無論多少次操作和第一次的操作結果一樣。如果訊息被多次消費，很有可能造成資料的不一致。而如果訊息不可避免地被消費多次，如果我們開發人員能透過技術手段保證資料的前後一致性，那也是可以接受的，這讓我想起了 Java 併發程式設計中的 ABA 問題，如果出現了 [ABA問題)，若能保證所有資料的前後一致性也能接受。

場景分析

RabbitMQ、RocketMQ、Kafka 訊息佇列中介軟體都有可能出現訊息重複消費問題。這種問題並不是 MQ 自己保證的，而是需要開發人員來保證。

這幾款訊息佇列中間都是是全球最牛的分散式訊息佇列，那肯定考慮到了訊息的冪等性。我們以 Kafka 為例，看看 Kafka 是怎麼保證訊息佇列的冪等性。

Kafka 有一個 偏移量 的概念，代表著訊息的序號，每條訊息寫到訊息佇列都會有一個偏移量，消費者消費了資料之後，每過一段固定的時間，就會把消費過的訊息的偏移量提交一下，表示已經消費過了，下次消費就從偏移量後面開始消費。

坑：當消費完訊息後，還沒來得及提交偏移量，系統就被關機了，那麼未提交偏移量的訊息則會再次被消費。

如下圖所示，佇列中的資料 A、B、C，對應的偏移量分別為 100、101、102，都被消費者消費了，但是隻有資料 A 的偏移量 100 提交成功，另外 2 個偏移量因系統重啟而導致未及時提交。

重啟後，消費者又是拿偏移量 100 以後的資料，從偏移量 101 開始拿訊息。所以資料 B 和資料 C 被重複訊息。

如下圖所示：

避坑指南

• 微信支付結果通知場景
• 微信官方文件上提到微信支付通知結果可能會推送多次，需要開發者自行保證冪等性。第一次我們可以直接修改訂單狀態（如支付中 -> 支付成功），第二次就根據訂單狀態來判斷，如果不是支付中，則不進行訂單處理邏輯。
• 插入資料庫場景
• 每次插入資料時，先檢查下資料庫中是否有這條資料的主鍵 id，如果有，則進行更新操作。
• 寫 Redis 場景
• Redis 的 Set 操作天然冪等性，所以不用考慮 Redis 寫資料的問題。
• 其他場景方案
• 生產者傳送每條資料時，增加一個全域性唯一 id，類似訂單 id。每次消費時，先去 Redis 查下是否有這個 id，如果沒有，則進行正常處理訊息，且將 id 存到 Redis。如果查到有這個 id，說明之前消費過，則不要進行重複處理這條訊息。
• 不同業務場景，可能會有不同的冪等性方案，大家選擇合適的即可，上面的幾種方案只是提供常見的解決思路。

2. 訊息佇列的坑之訊息丟失

坑:訊息丟失會帶來什麼問題？如果是訂單下單、支付結果通知、扣費相關的訊息丟失，則可能造成財務損失，如果量很大，就會給甲方帶來巨大損失。

那訊息佇列是否能保證訊息不丟失呢？答案：否。主要有三種場景會導致訊息丟失。

（1）生產者存放訊息的過程中丟失訊息

解決方案

• 事務機制（不推薦，非同步方式）

對於 RabbitMQ 來說，生產者傳送資料之前開啟 RabbitMQ 的事務機制channel.txselect ，如果訊息沒有進佇列，則生產者受到異常報錯，並進行回滾 channel.txRollback，然後重試傳送訊息；如果收到了訊息，則可以提交事務 channel.txCommit。但這是一個同步的操作，會影響效能。

• confirm 機制（推薦，非同步方式）

我們可以採用另外一種模式：confirm 模式來解決同步機制的效能問題。每次生產者傳送的訊息都會分配一個唯一的 id，如果寫入到了 RabbitMQ 佇列中，則 RabbitMQ 會回傳一個 ack 訊息，說明這個訊息接收成功。如果 RabbitMQ 沒能處理這個訊息，則回撥 nack 介面。說明需要重試傳送訊息。

也可以自定義超時時間 + 訊息 id 來實現超時等待後重試機制。但可能出現的問題是呼叫 ack 介面時失敗了，所以會出現訊息被髮送兩次的問題，這個時候就需要保證消費者消費訊息的冪等性。

事務模式 和 confirm 模式的區別：

• 事務機制是同步的，提交事務後悔被阻塞直到提交事務完成後。
• confirm 模式非同步接收通知，但可能接收不到通知。需要考慮接收不到通知的場景。

（2）訊息佇列丟失訊息

訊息佇列的訊息可以放到記憶體中，或將記憶體中的訊息轉到硬碟（比如資料庫）中，一般都是記憶體和硬碟中都存有訊息。如果只是放在記憶體中，那麼當機器重啟了，訊息就全部丟失了。如果是硬碟中，則可能存在一種極端情況，就是將記憶體中的資料轉換到硬碟的期間中，訊息佇列出問題了，未能將訊息持久化到硬碟。

解決方案

• 建立 Queue 的時候將其設定為持久化。
• 傳送訊息的時候將訊息的 deliveryMode 設定為 2 。
• 開啟生產者 confirm 模式，可以重試傳送訊息。

（3）消費者丟失訊息

消費者剛拿到資料，還沒開始處理訊息，結果程式因為異常退出了，消費者沒有機會再次拿到訊息。

解決方案

• 關閉 RabbitMQ 的自動 ack，每次生產者將訊息寫入訊息佇列後，就自動回傳一個 ack 給生產者。
• 消費者處理完訊息再主動 ack，告訴訊息佇列我處理完了。

問題： 那這種主動 ack 有什麼漏洞了？如果 主動 ack 的時候掛了，怎麼辦？

則可能會被再次消費，這個時候就需要冪等處理了。

問題： 如果這條訊息一直被重複消費怎麼辦？

則需要有加上重試次數的監測，如果超過一定次數則將訊息丟失，記錄到異常表或傳送異常通知給值班人員。

（4）RabbitMQ 訊息丟失總結

（5）Kafka 訊息丟失

場景：Kafka 的某個 broker（節點）當機了，重新選舉 leader （寫入的節點）。如果 leader 掛了，follower 還有些資料未同步完，則 follower 成為 leader 後，訊息佇列會丟失一部分資料。

解決方案

• 給 topic 設定 replication.factor 引數，值必須大於 1，要求每個 partition 必須有至少 2 個副本。
• 給 kafka 服務端設定 min.insyc.replicas 必須大於 1，表示一個 leader 至少一個 follower 還跟自己保持聯絡。

3. 訊息佇列的坑之訊息亂序

坑: 使用者先下單成功，然後取消訂單，如果順序顛倒，則最後資料庫裡面會有一條下單成功的訂單。

RabbitMQ 場景：

• 生產者向訊息佇列按照順序傳送了 2 條訊息，訊息1：增加資料 A，訊息2：刪除資料 A。
• 期望結果：資料 A 被刪除。
• 但是如果有兩個消費者，消費順序是：訊息2、訊息 1。則最後結果是增加了資料 A。

RabbitMQ 解決方案：

• 將 Queue 進行拆分，建立多個記憶體 Queue，訊息 1 和 訊息 2 進入同一個 Queue。
• 建立多個消費者，每一個消費者對應一個 Queue。

Kafka 場景：

• 建立了 topic，有 3 個 partition。
• 建立一條訂單記錄，訂單 id 作為 key，訂單相關的訊息都丟到同一個 partition 中，同一個生產者建立的訊息，順序是正確的。
• 為了快速消費訊息，會建立多個消費者去處理訊息，而為了提高效率，每個消費者可能會建立多個執行緒來並行的去拿訊息及處理訊息，處理訊息的順序可能就亂序了。

Kafka 解決方案：

• 解決方案和 RabbitMQ 類似，利用多個 記憶體 Queue，每個執行緒消費 1個 Queue。
• 具有相同 key 的訊息 進同一個 Queue。

4. 訊息佇列的坑之訊息積壓

訊息積壓：訊息佇列裡面有很多訊息來不及消費。

場景 1： 消費端出了問題，比如消費者都掛了，沒有消費者來消費了，導致訊息在佇列裡面不斷積壓。

場景 2： 消費端出了問題，比如消費者消費的速度太慢了，導致訊息不斷積壓。

坑：比如線上正在做訂單活動，下單全部走訊息佇列，如果訊息不斷積壓，訂單都沒有下單成功，那麼將會損失很多交易。

解決方案：解鈴還須繫鈴人

• 修復程式碼層面消費者的問題，確保後續消費速度恢復或儘可能加快消費的速度。
• 停掉現有的消費者。
• 臨時建立好原先 5 倍的 Queue 數量。
• 臨時建立好原先 5 倍數量的 消費者。
• 將堆積的訊息全部轉入臨時的 Queue，消費者來消費這些 Queue。

5. 訊息佇列的坑之訊息過期失效

坑：RabbitMQ 可以設定過期時間，如果訊息超過一定的時間還沒有被消費，則會被 RabbitMQ 給清理掉。訊息就丟失了。

解決方案：

• 準備好批次重導的程式
• 手動將訊息閒時批次重導

6. 訊息佇列的坑之佇列寫滿

坑：當訊息佇列因訊息積壓導致的佇列快寫滿，所以不能接收更多的訊息了。生產者生產的訊息將會被丟棄。

解決方案：

• 判斷哪些是無用的訊息，RabbitMQ 可以進行 Purge Message 操作。
• 如果是有用的訊息，則需要將訊息快速消費，將訊息裡面的內容轉存到資料庫。
• 準備好程式將轉存在資料庫中的訊息再次重導到訊息佇列。
• 閒時重導訊息到訊息佇列。

二、分散式快取的坑

在高頻訪問資料庫的場景中，我們會在業務層和資料層之間加入一套快取機制，來分擔資料庫的訪問壓力，畢竟訪問磁碟 I/O 的速度是很慢的。比如利用快取來查資料，可能5ms就能搞定，而去查資料庫可能需要 50 ms，差了一個數量級。而在高併發的情況下，資料庫還有可能對資料進行加鎖，導致訪問資料庫的速度更慢。

分散式快取我們用的最多的就是 Redis了，它可以提供分散式快取服務。

1. Redis 資料丟失的坑

哨兵機制

Redis 可以實現利用哨兵機制實現叢集的高可用。那什麼十哨兵機制呢？

• 英文名：sentinel，中文名：哨兵。
• 叢集監控：負責主副程式的正常工作。
• 訊息通知：負責將故障資訊報警給運維人員。
• 故障轉移：負責將主節點轉移到備用節點上。
• 配置中心：通知客戶端更新主節點地址。
• 分散式：有多個哨兵分佈在每個主備節點上，互相協同工作。
• 分散式選舉：需要大部分哨兵都同意，才能進行主備切換。
• 高可用：即使部分哨兵節點當機了，哨兵叢集還是能正常工作。

坑： 當主節點發生故障時，需要進行主備切換，可能會導致資料丟失。

非同步複製資料導致的資料丟失

主節點非同步同步資料給備用節點的過程中，主節點當機了，導致有部分資料未同步到備用節點。而這個從節點又被選舉為主節點，這個時候就有部分資料丟失了。

腦裂導致的資料丟失

主節點所在機器脫離了叢集網路，實際上自身還是執行著的。但哨兵選舉出了備用節點作為主節點，這個時候就有兩個主節點都在執行，相當於兩個大腦在指揮這個叢集幹活，但到底聽誰的呢？這個就是腦裂。

那怎麼腦裂怎麼會導致資料丟失呢？如果發生腦裂後，客戶端還沒來得及切換到新的主節點，連的還是第一個主節點，那麼有些資料還是寫入到了第一個主節點裡面，新的主節點沒有這些資料。那等到第一個主節點恢復後，會被作為備用節點連到叢集環境，而且自身資料會被清空，重新從新的主節點複製資料。而新的主節點因沒有客戶端之前寫入的資料，所以導致資料丟失了一部分。

避坑指南

• 配置 min-slaves-to-write 1，表示至少有一個備用節點。
• 配置 min-slaves-max-lag 10，表示資料複製和同步的延遲不能超過 10 秒。最多丟失 10 秒的資料

注意：快取雪崩、快取穿透、快取擊穿並不是分散式所獨有的，單機的時候也會出現。所以不在分散式的坑之列。

三、分庫分表的坑

1.分庫分表的坑之擴容

分庫、分表、垂直拆分和水平拆分

• 分庫： 因一個資料庫支援的最高併發訪問數是有限的，可以將一個資料庫的資料拆分到多個庫中，來增加最高併發訪問數。

• 分表： 因一張表的資料量太大，用索引來查詢資料都搞不定了，所以可以將一張表的資料拆分到多張表，查詢時，只用查拆分後的某一張表，SQL 語句的查詢效能得到提升。

• 分庫分表優勢：分庫分表後，承受的併發增加了多倍；磁碟使用率大大降低；單表資料量減少，SQL 執行效率明顯提升。

• 水平拆分： 把一個表的資料拆分到多個資料庫，每個資料庫中的表結構不變。用多個庫抗更高的併發。比如訂單表每個月有500萬條資料累計，每個月都可以進行水平拆分，將上個月的資料放到另外一個資料庫。

• 垂直拆分： 把一個有很多欄位的表，拆分成多張表到同一個庫或多個庫上面。高頻訪問欄位放到一張表，低頻訪問的欄位放到另外一張表。利用資料庫快取來快取高頻訪問的行資料。比如將一張很多欄位的訂單表拆分成幾張表分別存不同的欄位（可以有冗餘欄位）。

• 分庫、分表的方式：

• 根據租戶來分庫、分表。
• 利用時間範圍來分庫、分表。
• 利用 ID 取模來分庫、分表。

坑：分庫分表是一個運維層面需要做的事情，有時會採取凌晨當機開始升級。可能熬夜到天亮，結果升級失敗，則需要回滾，其實對技術團隊都是一種煎熬。

怎麼做成自動的來節省分庫分表的時間？

• 雙寫遷移方案：遷移時，新資料的增刪改操作在新庫和老庫都做一遍。
• 使用分庫分表工具 Sharding-jdbc  來完成分庫分表的累活。
• 使用程式來對比兩個庫的資料是否一致，直到資料一致。

坑: 分庫分表看似光鮮亮麗，但分庫分表會引入什麼新的問題呢？

垂直拆分帶來的問題

• 依然存在單表資料量過大的問題。
• 部分表無法關聯查詢，只能透過介面聚合方式解決，提升了開發的複雜度。
• 分散式事處理複雜。

水平拆分帶來的問題

• 跨庫的關聯查詢效能差。
• 資料多次擴容和維護量大。
• 跨分片的事務一致性難以保證。

2.分庫分表的坑之唯一 ID

為什麼分庫分表需要唯一 ID

• 如果要做分庫分表，則必須得考慮表主鍵 ID 是全域性唯一的，比如有一張訂單表，被分到 A 庫和 B 庫。如果 兩張訂單表都是從 1 開始遞增，那查詢訂單資料時就錯亂了，很多訂單 ID 都是重複的，而這些訂單其實不是同一個訂單。
• 分庫的一個期望結果就是將訪問資料的次數分攤到其他庫，有些場景是需要均勻分攤的，那麼資料插入到多個資料庫的時候就需要交替生成唯一的 ID 來保證請求均勻分攤到所有資料庫。

坑: 唯一 ID 的生成方式有 n 種，各有各的用途，別用錯了。

生成唯一 ID 的原則

• 全域性唯一性
• 趨勢遞增
• 單調遞增
• 資訊保安

生成唯一 ID 的幾種方式

• 資料庫自增 ID。每個資料庫每增加一條記錄，自己的 ID 自增 1。

• 多個庫的 ID 可能重複，這個方案可以直接否掉了，不適合分庫分表後的 ID 生成。
• 資訊不安全
• 缺點

• 適用 UUID 唯一 ID。

• UUID 太長、佔用空間大。
• 不具有有序性，作為主鍵時，在寫入資料時，不能產生有順序的 append 操作，只能進行 insert 操作，導致讀取整個 B+ 樹節點到記憶體，插入記錄後將整個節點寫回磁碟，當記錄佔用空間很大的時候，效能很差。
• 缺點

• 獲取系統當前時間作為唯一 ID。

• 高併發時，1 ms內可能有多個相同的 ID。
• 資訊不安全
• 缺點

• Twitter 的 snowflake（雪花演算法）：Twitter 開源的分散式 id 生成演算法，64 位的 long 型的 id，分為 4 部分

  

基本原理和優缺點：

• 1 bit：不用，統一為 0
  

• 41 bits：毫秒時間戳，可以表示 69 年的時間。

• 10 bits：5 bits 代表機房 id，5 個 bits 代表機器 id。最多代表 32 個機房，每個機房最多代表 32 臺機器。

• 12 bits：同一毫秒內的 id，最多 4096 個不同 id，自增模式。

• 優點：

• 毫秒數在高位，自增序列在低位，整個ID都是趨勢遞增的。

• 不依賴資料庫等第三方系統，以服務的方式部署，穩定性更高，生成ID的效能也是非常高的。

• 可以根據自身業務特性分配bit位，非常靈活。

• 缺點：

• 強依賴機器時鐘，如果機器上時鐘回撥（可以搜尋 2017 年閏秒 7:59:60），會導致發號重複或者服務會處於不可用狀態。

• 百度的 UIDGenerator 演算法。

  

• 基於 Snowflake 的最佳化演算法。
• 借用未來時間和雙 Buffer 來解決時間回撥與生成效能等問題，同時結合 MySQL 進行 ID 分配。
• 優點：解決了時間回撥和生成效能問題。
  
• 缺點：依賴 MySQL 資料庫。
  

• 美團的 Leaf-Snowflake 演算法。



• 獲取 id 是透過代理服務訪問資料庫獲取一批 id（號段）。

• 雙緩衝：當前一批的 id 使用 10%時，再訪問資料庫獲取新的一批 id 快取起來，等上批的 id 用完後直接用。

• 優點：

• Leaf服務可以很方便的線性擴充套件，效能完全能夠支撐大多數業務場景。

• ID號碼是趨勢遞增的8byte的64位數字，滿足上述資料庫儲存的主鍵要求。

• 容災性高：Leaf服務內部有號段快取，即使DB當機，短時間內Leaf仍能正常對外提供服務。

• 可以自定義max_id的大小，非常方便業務從原有的ID方式上遷移過來。

• 即使DB當機，Leaf仍能持續發號一段時間。

• 偶爾的網路抖動不會影響下個號段的更新。

• 缺點：

• ID號碼不夠隨機，能夠洩露發號數量的資訊，不太安全。

怎麼選擇：一般自己的內部系統，雪花演算法足夠，如果還要更加安全可靠，可以選擇百度或美團的生成唯一 ID 的方案。

四、分散式事務的坑

怎麼理解事務？

• 事務可以簡單理解為要麼這件事情全部做完，要麼這件事情一點都沒做，跟沒發生一樣。

• 在分散式的世界中，存在著各個服務之間相互呼叫，鏈路可能很長，如果有任何一方執行出錯，則需要回滾涉及到的其他服務的相關操作。比如訂單服務下單成功，然後呼叫營銷中心發券介面發了一張代金券，但是微信支付扣款失敗，則需要退回發的那張券，且需要將訂單狀態改為異常訂單。

坑：如何保證分散式中的事務正確執行，是個大難題。

分散式事務的幾種主要方式

• XA 方案（兩階段提交方案）
• TCC 方案（try、confirm、cancel）
• SAGA 方案
• 可靠訊息最終一致性方案
• 最大努力通知方案

XA 方案原理

• 事務管理器負責協調多個資料庫的事務，先問問各個資料庫準備好了嗎？如果準備好了，則在資料庫執行操作，如果任一資料庫沒有準備，則回滾事務。
• 適合單體應用，不適合微服務架構。因為每個服務只能訪問自己的資料庫，不允許交叉訪問其他微服務的資料庫。

TCC 方案

• Try 階段：對各個服務的資源做檢測以及對資源進行鎖定或者預留。
• Confirm 階段：各個服務中執行實際的操作。
• Cancel 階段：如果任何一個服務的業務方法執行出錯，需要將之前操作成功的步驟進行回滾。

應用場景：

• 跟支付、交易打交道，必須保證資金正確的場景。
• 對於一致性要求高。

缺點：

• 但因為要寫很多補償邏輯的程式碼，且不易維護，所以其他場景建議不要這麼做。

Sega 方案

基本原理：

• 業務流程中的每個步驟若有一個失敗了，則補償前面操作成功的步驟。

適用場景：

• 業務流程長、業務流程多。
• 參與者包含其他公司或遺留系統服務。

優勢：

• 第一個階段提交本地事務、無鎖、高效能。
• 參與者可非同步執行、高吞吐。
• 補償服務易於實現。

缺點：

• 不保證事務的隔離性。

可靠訊息一致性方案

基本原理：

• 利用訊息中介軟體 RocketMQ 來實現訊息事務。
• 第一步：A 系統傳送一個訊息到 MQ，MQ將訊息狀態標記為 prepared（預備狀態，半訊息），該訊息無法被訂閱。
• 第二步：MQ 響應 A 系統，告訴 A 系統已經接收到訊息了。
• 第三步：A 系統執行本地事務。
• 第四步：若 A 系統執行本地事務成功，將 prepared 訊息改為 commit（提交事務訊息），B 系統就可以訂閱到訊息了。
• 第五步：MQ 也會定時輪詢所有 prepared的訊息，回撥 A 系統，讓 A 系統告訴 MQ 本地事務處理得怎麼樣了，是繼續等待還是回滾。
• 第六步：A 系統檢查本地事務的執行結果。
• 第七步：若 A 系統執行本地事務失敗，則 MQ 收到 Rollback 訊號，丟棄訊息。若執行本地事務成功，則 MQ 收到 Commit 訊號。
• B 系統收到訊息後，開始執行本地事務，如果執行失敗，則自動不斷重試直到成功。或 B 系統採取回滾的方式，同時要透過其他方式通知 A 系統也進行回滾。
• B 系統需要保證冪等性。

最大努力通知方案

基本原理：

• 系統 A 本地事務執行完之後，傳送訊息到 MQ。
• MQ 將訊息持久化。
• 系統 B 如果執行本地事務失敗，則最大努力服務會定時嘗試重新呼叫系統 B，儘自己最大的努力讓系統 B 重試，重試多次後，還是不行就只能放棄了。轉到開發人員去排查以及後續人工補償。

幾種方案如何選擇

• 跟支付、交易打交道，優先 TCC。
• 大型系統，但要求不那麼嚴格，考慮 訊息事務或 SAGA 方案。
• 單體應用，建議 XA 兩階段提交就可以了。
• 最大努力通知方案建議都加上，畢竟不可能一出問題就交給開發排查，先重試幾次看能不能成功。

參考資料：

美團的 Leaf-Snowflake 演算法。
百度的 UIDGenerator 演算法。
Advanced-Java