RocketMQ 顺序消息靠分区有序，真碰上需要全局强顺序的业务，加个业务层序号成本到底高多少
RocketMQ 的顺序消息仅支持分区有序，无法实现全局有序。强行在业务层通过全局序号、排序缓冲区、去重和断点续跑等机制实现全局顺序，会带来显著的状态管理、测试和运维复杂度，成本远高于直觉。更优方案是采用单线程顺序消费加异步分发，或换用原生支持全局顺序的中间件。
标签: #RocketMQ
共 4 篇文章
订单超时取消时，消息重试用指数退避还是直接扔死信？我们把三种策略放一起跑了一遍
订单超时取消场景下，三种消息处理策略的压测对比显示：业务补偿通过状态校验实现零资损，表现最稳；指数退避在低故障率时延迟友好，但瞬时故障会放大问题；死信队列必须配合监控和人工处理，否则易引发积压和顺序混乱。选择需权衡实时性、开发成本和容错能力。
压到极限才见真章：Kafka、RocketMQ、Pulsar 在不同分区下堆积到接近崩盘时，延迟到底差多少
在极端分区（最高5000）和高堆积（TB级）条件下，对Kafka、RocketMQ和Pulsar进行物理集群压测。结果显示，Kafka延迟恶化最可控，呈渐进式增长；RocketMQ在2000分区时出现性能断崖，延迟飙升至秒级；Pulsar在分区超500后几乎不可用，架构开销导致指数级恶化。性能断崖根因各异，选型需匹配业务瓶颈。
RocketMQ 事务消息和 RabbitMQ 确认机制，在拆微服务后保证数据一致性上，各自适合什么场景？
RocketMQ 事务消息通过两阶段提交实现消息发送与本地事务的原子性，适合“先发消息后落库”的强一致性场景；RabbitMQ 确认机制配合本地事件表，以“先落库后发消息”实现最终一致性，适合允许秒级延迟的业务。选型取决于业务对实时性和运维复杂度的权衡，且需注意回查逻辑与 Outbox 扫描的实现细节。