【故障現場】MQ 消息亂序造成的業務事故

  1. 問題 & 分析 ==========

1.1. 案例

深夜，小艾接到了一通突如其來的電話，是物流系統的負責人曹工焦急的聲音。他火急火燎地反饋了一個嚴重的問題——大批用戶投訴物流信息異常，訂單狀態與實際情況不符，用戶已完成支付，但物流單還是待支付狀態。

小艾立刻警覺起來，意識到這個問題可能對公司的業務以及用戶體驗造成重大影響。她一邊安撫曹工的情緒，一邊迅速啓動緊急響應機制，通知 QA 對線上變更進行回滾。

隨着回滾進程的推進，系統逐步恢復正常。緊接着，他手工導出上線以來的全部訂單，並與曹工一起進行數據覈對，對問題數據進行修復。終於忙完了，天空已經微微發亮……

1.2. 問題分析

上午稍微補了個覺，小艾洗漱完畢後對這件事進行分析：訂單已支付，物流單待支付。

現在訂單和物流的系統交互如下：

在正常的業務流程中，訂單發佈事件和物流監聽事件緊密相連。

  1. 訂單系統發佈一個 “訂單已創建” 事件時，物流系統會立即響應並在其內部創建一條對應的物流單據。

  2. 當支付環節完成並觸發 “訂單已支付” 事件時，物流系統會找到關聯的物流單據並更新其爲待發貨狀態。

在正常情況下，沒有出現不一致的情況。小艾想到了最近的系統變更：

最近上線的一項新功能——禮品贈送。爲了降低對下游系統的影響，小艾通過在應用層對流程進行編排的方式實現該功能，簡單來說，就是系統先創建訂單，然後模擬支付成功，這樣既能滿足禮品贈送的需求，又能保障下游契約消息沒有變化。新流程如下所示：

整個流程與原來的方案沒有差別，問題究竟出現在哪呢？無奈的小艾只好打開 idea 查看源碼，終於發現問題所在：

@Service
public class RocketMQProducer {
    @Autowired
    private RocketMQTemplate rocketMQTemplate;

    @TransactionalEventListener
    public void handle(OrderCreatedEvent event){
        rocketMQTemplate.convertAndSend("order_created_event", event);
    }

    @TransactionalEventListener
    public void handle(OrderPaidEvent event){
        rocketMQTemplate.convertAndSend("order_paid_event", event);
    }
}

下單和支付成功使用兩個不同的 topic，兩個 topic 相互獨立，根本就無法保障投遞順序。在手動支付場景下，由於用戶從訂單創建到支付完成通常會有 5 秒以上的延遲，在這種情況下該實現可以保障邏輯的執行順序。然而在禮品贈送這個場景，系統先創建訂單，然後模擬支付成功，導致 “訂單已創建” 和“訂單已支付”兩個事件幾乎同時發出，在接收端就有可能先收到支付成功事件，再收到訂單已創建事件，從而導致訂單狀態和物流單狀態不一致，具體流程如下：

如果順序錯了，就會導致業務狀態不一致：

  1. 物流先接到支付成功事件，在查詢物流單時由於找不到物流單所以更新失敗。

  2. 隨後物流接到訂單創建事件，根據邏輯創建一條待支付的物流單，但由於該訂單的支付成功事件在上一步已經錯過，所以物流一直停留在待支付狀態。

問題終於找到了！！！

  1. 解決方案 =======

2.1. 方案一：主動延時

既然是順序問題，那最簡的方法就是對支付成功消息進行延時發送。

方案如下：

中間增加一個延時組件便能解決這個問題，但不同的方案影響巨大：

  1. sleep 方案，會導致大量線程處於阻塞狀態，增加接口響應時間，同時降低系統的吞吐。在線上絕對不允許這種方案的出現！

  2. 定時器方案，下單完成後，註冊一個定時調度任務，時間到達時調度器將自動執行任務。

定時器方案，核心代碼如下：

@TransactionalEventListener
public void handle(OrderPaidEvent event){
    // 創建Runnable任務
    Runnable task = () -> {
        rocketMQTemplate.convertAndSend("order_paid_event", event);
    };
    // 使用ScheduledExecutorService schedule方法在5秒後執行任務
    executor.schedule(task, 5, TimeUnit.SECONDS);
}

該方案存在幾個比較嚴重的問題：

  1. 全內存操作，容易操作任務的丟失。當遇到非優雅關機時，內存中的 task 就會丟失，從而導致業務邏輯不完整；

  2. 異步執行，容易造成錯覺。用戶完成任務提交併不代表任務肯定會成功運行

  3. 資源管理困難，如果任務量太大會大量消耗內存資源，甚至引起整個服務 OOM

2.2. 方案二：順序消息

現在不少 MQ 提供順序消息的支持，比如常見的 RocketMQ 提供了兩種類型的順序消息：全局順序消息和分區順序消息。

  1. 全局順序消息要求所有的消息都在一個隊列上發送和消費，因此只適用於少量隊列（通常是 1 個隊列，否則就無法做到全局順序）。

  2. 分區順序消息則允許基於（分片鍵）進行分區，相同的消息會被髮送到同一隊列中，從而在每個分區內部實現順序。

分區順序消息整體設計如下：

核心代碼如下：

@TransactionalEventListener
public void handle(OrderCreatedEvent event){
    Long orderId = event.getOrderId();
    Message<OrderCreatedEvent> message = MessageBuilder.withPayload(event)
            .setHeader(RocketMQHeaders.KEYS, orderId) // 設置 Sharding Key，即訂單ID
            .setHeader(RocketMQHeaders.TAGS, "OrderCreatedEvent") // 設置 Tag
            .build();
    // 發送至統一的 order_event_topic
    rocketMQTemplate.send("order_event_topic", message);
}

@TransactionalEventListener
public void handle(OrderPaidEvent event){
    Long orderId = event.getOrderId();
    Message<OrderPaidEvent> message = MessageBuilder.withPayload(event)
            .setHeader(RocketMQHeaders.KEYS, orderId) // 設置 Sharding Key，即訂單ID
            .setHeader(RocketMQHeaders.TAGS, "OrderCreatedEvent") // 設置 Tag
            .build();
    // 發送至統一的 order_event_topic
    rocketMQTemplate.send("order_event_topic", message);
}
  1. 示例 & 源碼 ==========

代碼倉庫：https://gitee.com/litao851025/learnFromBug

代碼地址：https://gitee.com/litao851025/learnFromBug/tree/master/src/main/java/com/geekhalo/demo/mq/disorder

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/0mO1s1_uWqqe5lTy520WnQ

猜你喜歡