本文介绍消息队列RocketMQ版顺序消息的概念、版本说明、适用场景以及使用过程中的注意事项。
什么是顺序消息
顺序消息(FIFO消息)是消息队列RocketMQ版提供的一种严格按照顺序来发布和消费的消息。顺序发布和顺序消费是指对于指定的一个Topic,生产者按照一定的先后顺序发布消息;消费者按照既定的先后顺序订阅消息,即先发布的消息一定会先被客户端接收到。
顺序消息2.0简介
消息队列RocketMQ版全新推出顺序消息2.0特性,该特性具有以下特点:
- 高并发:顺序消息2.0的无主一致性架构极大地提高了顺序消息的吞吐量。
- 高可用:顺序消息2.0的无主一致性架构使其拥有更完善的负载均衡策略和故障节点自适应恢复能力。
- 无热点:顺序消息2.0拥有更完善的集群负载均衡策略,解决了顺序消息的热点问题。
- 如需使用顺序消息2.0特性,请确保您的消息队列RocketMQ版实例是企业铂金版。
- 仅TCP Java ons-client v1.8.7.1.Final及以上版本的SDK支持顺序消息2.0。
全局顺序消息
对于指定的一个Topic,所有消息按照严格的先入先出(FIFO)的顺序来发布和消费。
- 适用场景
适用于性能要求不高,所有的消息严格按照FIFO原则来发布和消费的场景。
- 示例
在证券处理中,以人民币兑换美元为Topic,在价格相同的情况下,先出价者优先处理,则可以按照FIFO的方式发布和消费全局顺序消息。
分区顺序消息
对于指定的一个Topic,所有消息根据Sharding Key进行区块分区。同一个分区内的消息按照严格的FIFO顺序进行发布和消费。Sharding Key是顺序消息中用来区分不同分区的关键字段,和普通消息的Key是完全不同的概念。
- 适用场景
适用于性能要求高,以Sharding Key作为分区字段,在同一个区块中严格地按照FIFO原则进行消息发布和消费的场景。
- 示例
- 用户注册需要发送发验证码,以用户ID作为Sharding Key,那么同一个用户发送的消息都会按照发布的先后顺序来消费。
- 电商的订单创建,以订单ID作为Sharding Key,那么同一个订单相关的创建订单消息、订单支付消息、订单退款消息、订单物流消息都会按照发布的先后顺序来消费。
阿里巴巴集团内部电商系统均使用分区顺序消息,既保证业务的顺序,同时又能保证业务的高性能。
全局顺序消息与分区顺序消息对比
在控制台创建顺序消息使用的不同类型Topic对比如下。
Topic的消息类型 | 是否支持事务消息 | 是否支持定时和延时消息 | 性能 |
---|---|---|---|
无序消息(普通、事务、定时和延时消息) | 是 | 是 | 最高 |
分区顺序消息 | 否 | 否 | 高 |
全局顺序消息 | 否 | 否 | 一般 |
消息类型 | 是否支持可靠同步发送 | 是否支持可靠异步发送 | 是否支持Oneway发送 |
---|---|---|---|
无序消息(普通、事务、定时和延时消息) | 是 | 是 | 是 |
分区顺序消息 | 是 | 否 | 否 |
全局顺序消息 | 是 | 否 | 否 |
注意事项
使用顺序消息时,请注意以下几点:
- 建议同一个Group ID只对应一种类型的Topic,即不同时用于顺序消息和无序消息的收发。
- 对于全局顺序消息,建议消息不要有阻塞。同时运行多个实例,是为了防止工作实例意外退出而导致业务中断。当工作实例退出时,其他实例可以立即接手工作,不会导致业务中断,实际工作的只会有一个实例。
顺序消息常见问题
- 同一条消息是否可以既是顺序消息,又是定时消息和事务消息?
不可以。顺序消息、定时消息、事务消息是不同的消息类型,三者是互斥关系,不能叠加在一起使用。
- 顺序消息支持哪些地域?
支持消息队列RocketMQ版所有公共云地域和金融云地域。
- 为什么全局顺序消息性能一般?
全局顺序消息是严格按照FIFO的消息阻塞原则,即上一条消息没有被成功消费,那么下一条消息会一直被存储到Topic队列中。如果想提高全局顺序消息的TPS,可以升级实例配置,同时消息客户端应用尽量减少处理本地业务逻辑的耗时。
- 顺序消息支持哪种消息发送方式?
顺序消息只支持可靠同步发送方式,不支持异步发送方式,否则将无法严格保证顺序。
- 顺序消息是否支持集群消费和广播消费?
顺序消息暂时仅支持集群消费模式,不支持广播消费模式。
在文档使用中是否遇到以下问题
更多建议
匿名提交