我们围绕这两个方面来白话下消息顺序性问题。
关键字摘要
- 全局有序
- 局部有序
- 局部有序能一直有序吗
- 顺序消息的限制
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，表示顺序消息:
代码语言：javascript复制$ 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如何生产消息有全面了解了吧。 如果还想了解更多，欢迎关注下一期内容。
往期热门笔记合集推荐：
- HBase原理与实战笔记合集
- MySQL实战笔记合集
- Canal/Otter源码与实战笔记合集
- Java实战技巧笔记合集
原创：阿丸笔记，欢迎 分享，转载请保留出处。
