3分钟白话RocketMQ系列—— 如何保证消息顺序性

实现的消息的顺序性主要有两个维度，分别是「全局有序」和「局部有序」。

我们围绕这两个方面来白话下消息顺序性问题。

关键字摘要

• 全局有序

• 局部有序

• 局部有序能一直有序吗

• 顺序消息的限制

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: 顺序消息有哪些限制？

1）同一条消息是否可以既是顺序消息，又是定时消息和事务消息？

不可以。顺序消息、定时消息、事务消息是不同的消息类型，三者是互斥关系，不能叠加在一起使用。

2）为什么全局顺序消息性能一般？

全局顺序消息是严格按照FIFO的消息阻塞原则，即上一条消息没有被成功消费，那么下一条消息会一直被存储到Topic队列中。

关键字总结

• 全局有序：必须控制Topic只有一个队列queue，才能实现全局有序，性能一般。

• 局部有序：性能较好，需要确保「生产有序」和「消费有序」，同时注意Broker掉线时的 可用性 与 有序性 权衡。

3分钟到了吗？应该对RocketMQ如何生产消息有全面了解了吧。
如果还想了解更多，欢迎关注下一期内容。