RabbitMQ默认不保证消息顺序消费，必须通过单队列+单消费者+单线程或按业务ID分区等架构设计实现；多消费者因推模式无全局锁必然乱序；重试需隔离，幂等必做。
消息顺序性在 RabbitMQ 中根本不可靠
RabbitMQ 本身不保证跨队列、跨消费者、甚至单队列多消费者的消息全局顺序。它只承诺“单个 channel 上、单个 queue、单个 consumer 按发送顺序投递”——但这个前提在微服务里几乎不存在：你不可能让所有订单事件都由同一个 consumer 实例处理，也不可能把所有业务都压在一个 queue 里。
常见误操作包括：用 routing key 分发到不同 queue 后再合并消费；或以为开启 channel.Qos(1, 0, false) 就能保序——它只是限制未确认消息数，不干预投递时序。
- 若业务强依赖顺序（如“创建→支付→发货”），必须在消息体中显式携带
sequence_id或parent_id字段，由消费者按序缓存+重排 - 更稳妥的做法是聚合为单事件：把“用户下单后立即扣库存”拆成两个独立事件（
OrderCreated+InventoryReserved），用业务 ID 关联而非靠投递顺序 - RabbitMQ 的
x-max-priority队列不能替代顺序控制——优先级只影响同一批待投递消息的调度，不改变已入队消息的位置
Kafka 是唯一能靠分区保障局部顺序的选项
Kafka 的顺序性基于 partition：同一 key（如 order_id）的所有消息一定落到同一 partition，而每个 partition 内部严格 FIFO。这是它和 RabbitMQ 最本质的区别。
但要注意：这个“顺序”仅对单 partition 有效；一旦消费者组扩容、rebalance，partition 分配可能变化，旧 offset 读取仍能保序，但新分配的 partition 不会继承历史顺序上下文。
立即学习“go语言免费学习笔记（深入）”；
- 生产者必须设
Key字段（如sarama.StringEncoder(orderID)），否则默认 round-robin 分区，彻底打乱顺序 - 消费者组必须稳定——避免频繁启停导致 rebalance，否则可能重复消费或跳过中间消息
- 不要用
WriteMessages批量写入时混入不同 key 的消息，否则同一 batch 内顺序无法保证；单条发送或按 key 分批
Go 客户端里最容易忽略的顺序陷阱
用 sarama 发送时，默认配置下 config.Producer.RequiredAcks = sarama.WaitForLocal（只等 leader 写入本地日志），这会导致网络抖动时消息乱序提交；而 streadway/amqp 的 channel.Publish 默认无确认机制，连“是否发出”都无法验证。
-
sarama必须设config.Producer.RequiredAcks = sarama.WaitForAll，否则 replica 同步延迟会让下游看到“跳号” -
streadway/amqp要调channel.Confirm()+channel.NotifyPublish()，否则ch.Publish()返回即认为成功，实际可能路由失败或 Broker 拒绝 - 所有客户端都要禁用自动重试：sarama 的
config.Producer.Retry.Max设为 0，amqp 的 publish 不做重试封装——重试本身就会破坏顺序，应由业务层按 sequence_id 主动补偿
业务层兜底比中间件保序更可靠
无论选 RabbitMQ 还是 Kafka，只要网络不可靠、Broker 重启、Consumer 崩溃，就可能丢消息、重复、乱序。指望中间件 100% 保序，等于把一致性责任推给基础设施。
- 每个事件结构体必须带
event_id string和causation_id string（前序事件 ID），消费者用 Redis ZSET 缓存最近 N 条消息，按causation_id拼接链路 - 关键状态变更（如订单状态机）必须走数据库 version 字段 +
UPDATE ... WHERE version = ?，失败则重拉上游事件重放 - 不要在 consumer handler 里直接调
http.Post或grpc.Call——这又回到伪异步，一旦下游超时，本条消息卡住，后续全阻塞
