RocketMQ實戰(3)-消息的有序性

1 為什麼需要消息有序

996一輩子了，準備去銀行存取款，對應兩個異步短信消息，要保證先存後取：

• M1 存錢
• M2 取錢

• 

  而MQ預設發消息到不同Q顯然是行不通的，會亂序。

是以，需發往同一Q，依賴隊列的先進先出機制。

2 基本概念

有序消息，又叫順序消息(FIFO消息)，指消息的消費順序和産生順序相同。

如訂單的生成、付款、發貨，這串消息必須按序處理。順序消息又可分為：

2.1 全局順序

一個Topic内所有的消息都釋出到同一Q，按FIFO順序進行釋出和消費：

适用場景

性能要求不高，所有消息嚴格按照FIFO進行消息釋出和消費的場景。

2.2 分區順序

對于指定的一個Topic，所有消息按sharding key進行區塊(queue)分區，同一Q内的消息嚴格按FIFO釋出和消費。

Sharding key是順序消息中用來區分不同分區的關鍵字段，和普通消息的Key完全不同。

性能要求高，根據消息中的sharding key去決定消息發送到哪個queue。

2.3 對比

• 發送方式對比

• 

3 如何保證消息順序？

在MQ模型中，順序需由3個階段去保障

1. 消息被發送時保持順序
2. 消息被存儲時保持和發送的順序一緻
3. 消息被消費時保持和存儲的順序一緻

4 RocketMQ 有序消息實作原理

RocketMQ消費端有兩種類型：

• MQPullConsumer
• MQPushConsumer

底層都是通過pull機制實作，pushConsumer是一種API封裝而已。

MQPullConsumer 由使用者控制線程，主動從服務端擷取消息，每次擷取到的是一個MessageQueue中的消息。

PullResult中的 List msgFoundList

MQPushConsumer

由使用者注冊

MessageListener

來消費消息，在用戶端中需要保證調用

MessageListener

時消息的順序性

看源碼

拉取生産端消息

判斷是并發的還是有序的,對應不同服務實作類

5 有序消息的缺陷

發送順序消息無法利用叢集的Failover特性，因為不能更換MessageQueue進行重試。

因為發送的路由政策導緻的熱點問題，可能某一些MessageQueue的資料量特别大

• 消費的并行讀依賴于queue數量
• 消費失敗時無法跳過