關鍵字摘要

• 全局有序
• 局部有序
• 局部有序能一直有序嗎
• 順序消息的限制

Q1：什么是全局有序？如何實現全局有序？

適用于性能要求不高，所有的消息嚴格按照先進先出（FIFO）的原則來發布和消費的場景。

例如，在證券處理中，以人民幣兌換美元為Topic，在價格相同的情況下，先出價者優先處理，則可以按照FIFO的方式發布和消費全局順序消息。

要實現全局有序，必須控制Topic只有一個隊列queue，才能實現全局有序。

由于只有一個隊列存在，這種方式雖然保證了全局有序，但是性能不高，無法擴展。

Q2：什么是局部有序？如何實現局部有序？

適用于性能要求高，以Sharding Key作為分區字段，在同一個隊列queue中嚴格地按照FIFO原則進行消息發布和消費的場景。

例如，用戶注冊需要發送發驗證碼，以用戶ID作為Sharding Key，那么同一個用戶發送的消息都會按照發布的先后順序來消費。

保證「消息生產」的順序性，則必須滿足以下條件：

• 單一生產者：消息生產的順序性僅支持單一生產者，不同生產者分布在不同的系統，即使設置相同的分區鍵，不同生產者之間產生的消息也無法判定其先后順序。
• 串行發送：生產者客戶端支持多線程安全訪問，但如果生產者使用多線程并行發送，則不同線程間產生的消息將無法判定其先后順序。

滿足以上條件的生產者，將 「順序消息」 發送至服務端后，會保證設置了同一分區鍵的消息，按照發送順序存儲在同一隊列中。

局部有序（分區有序）

注意，在RocketMQ 5.x版本中，新增了「消息組」概念，順序消息發送必須要設置消息組。

保證「消息消費」的順序性，則必須滿足以下條件：

• 語義正確。業務方消費消息時需要嚴格按照 接收---處理---應答 的語義處理消息，避免因異步處理導致消息亂序。
• 有限重試。順序消息消費投遞次數限定有限范圍內，即一條消息如果超過最大重試次數后，將跳過這條消息消費，不會一直阻塞后續消息處理。

對于需要嚴格保證消費順序的場景，請務必設置合理的重試次數，避免參數不合理導致消息亂序。

Q3:如果Broker掉線，局部有序還能保持有序嗎？

如果一個Broker掉線，那么此時隊列總數是否會發化？

如果發生變化，那么同一個 ShardingKey 的消息就會發送到不同的隊列上，造成亂序。

如果不發生變化，那消息將會發送到掉線Broker的隊列上，必然是失敗的。

因此 Apache RocketMQ 提供了兩種模式，如果要保證嚴格順序而不是可用性，創建 Topic 是要指定 -o 參數（--order）為true，表示順序消息:

$ sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -o true -n 127.0.0.1:9876
create topic to 127.0.0.1:10911 success.
TopicConfig [topicName=TopicTest, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=true, attributes=null]

其次，要保證NameServer中的配置 orderMessageEnable 和 returnOrderTopicConfigToBroker 必須是 true。

如果上述任意一個條件不滿足，則是保證可用性而不是嚴格順序。

Q4: 順序消息有哪些限制？

同一條消息是否可以既是順序消息，又是定時消息和事務消息？

不可以。順序消息、定時消息、事務消息是不同的消息類型，三者是互斥關系，不能疊加在一起使用。

為什么全局順序消息性能一般？

全局順序消息是嚴格按照FIFO的消息阻塞原則，即上一條消息沒有被成功消費，那么下一條消息會一直被存儲到Topic隊列中。

關鍵字總結

• 全局有序：必須控制Topic只有一個隊列queue，才能實現全局有序，性能一般。
• 局部有序：性能較好，需要確保「生產有序」和「消費有序」，同時注意Broker掉線時的 可用性 與 有序性 權衡。