适用于性能要求不高，所有的消息严格按照先进先出（FIFO）的原则来发布和消费的场景。
例如，在证券处理中，以人民币兑换美元为Topic，在价格相同的情况下，先出价者优先处理，则可以按照FIFO的方式发布和消费全局顺序消息。
要实现全局有序，必须控制Topic只有一个队列queue，才能实现全局有序。
由于只有一个队列存在，这种方式虽然保证了全局有序，但是性能不高，无法扩展。
适用于性能要求高，以Sharding Key作为分区字段，在同一个队列queue中严格地按照FIFO原则进行消息发布和消费的场景。
例如，用户注册需要发送发验证码，以用户ID作为Sharding Key，那么同一个用户发送的消息都会按照发布的先后顺序来消费。
保证「消息生产」的顺序性，则必须满足以下条件：
满足以上条件的生产者，将 「顺序消息」 发送至服务端后，会保证设置了同一分区键的消息，按照发送顺序存储在同一队列中。
局部有序（分区有序）
注意，在RocketMQ 5.x版本中，新增了「消息组」概念，顺序消息发送必须要设置消息组。
保证「消息消费」的顺序性，则必须满足以下条件：
对于需要严格保证消费顺序的场景，请务必设置合理的重试次数，避免参数不合理导致消息乱序。
如果一个Broker掉线，那么此时队列总数是否会发化？
如果发生变化，那么同一个 ShardingKey 的消息就会发送到不同的队列上，造成乱序。
如果不发生变化，那消息将会发送到掉线Broker的队列上，必然是失败的。
因此 Apache RocketMQ 提供了两种模式，如果要保证严格顺序而不是可用性，创建 Topic 是要指定 -o 参数（--order）为true，表示顺序消息:
$ sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -o true -n 127.0.0.1:9876create 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。
如果上述任意一个条件不满足，则是保证可用性而不是严格顺序。
同一条消息是否可以既是顺序消息，又是定时消息和事务消息？
不可以。顺序消息、定时消息、事务消息是不同的消息类型，三者是互斥关系，不能叠加在一起使用。
为什么全局顺序消息性能一般？
全局顺序消息是严格按照FIFO的消息阻塞原则，即上一条消息没有被成功消费，那么下一条消息会一直被存储到Topic队列中。
本文链接：//www.dmpip.com//www.dmpip.com/showinfo-26-10904-0.html三分钟白话RocketMQ系列—— 如何保证消息顺序性
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
