顺序保证的边界
消息中间件的顺序保证通常是“分区内有序”而不是全局有序：同一个分区里的消息按追加顺序被消费，跨分区没有先后关系。因此保序的做法是把需要保序的消息用同一个业务键（订单号、账户号、设备 ID）做分区键，让它们进入同一分区。全局顺序需要单分区或全局协调，代价是吞吐与并行度大幅下降，通常只在小流量且确有全局时序要求的场景使用。
基本信息
| 分区键 | 选业务实体键（订单号、账户号），保证实体级有序 |
|---|---|
| 生产端 | 同一键的消息按序发送，避免并发重排 |
| 消费端 | 单分区单并发消费；多线程消费会打乱顺序 |
| 重试影响 | 重试队列或延迟重投会让消息后到，顺序被破坏 |
典型使用场景
- 订单状态流转：同一订单的创建、支付、发货消息必须按序处理
- 账户流水：同一账户的加减操作顺序影响余额结果
- 设备指令下发：同一设备的配置与重启指令顺序错误会导致异常
- 数据同步：同一行的变更事件按序应用，避免用旧值覆盖新值
- 风控决策：同一用户的连续行为事件按序评估才有意义
保序方案对照
| 方案 | 保证范围 | 代价 |
|---|---|---|
| 单分区 | 全局有序 | 吞吐受限 |
| 业务键分区 | 实体级有序 | 跨实体顺序不保证 |
| 消费端串行 | 分区内有序 | 并发度受限 |
| 序号校验 | 检测乱序并缓冲重排 | 实现复杂度上升 |
分区与消费要点
分区与消费要点
生产：producer.send(topic, key = order_id, value = event)
# 同一 order_id 恒定映射到同一个分区
消费：每个分区只由一个消费线程处理
# 线程数 = 分区数，不要再在分区内开线程池
异常：失败消息不要直接投递到主 topic 的尾部
# 可用序号或状态版本号丢弃过期消息
# 并发消费同一分区必然乱序，是保序场景最常见的破坏点使用要点
- 需要全局有序的场景先评估是否真的必要：全局单分区会牺牲并行度，吞吐代价高
- 给消息带上业务版本号或序号：消费端可据此丢弃过期消息，作为保序之外的第二道防线
- 重试与死信流程要保序：重投的消息排在队尾会破坏顺序，重试队列需按键处理
- 分区键变更等于顺序保证变更：调整分区键之前要评估对现有消费逻辑的影响
需要全局有序的场景先评估是否真的必要：全局单分区会牺牲并行度，吞吐代价高，很多业务其实只需要实体级有序。
消费端重试是保序的隐性破坏点：失败消息被投回队尾后，同键的后续消息会先被处理，业务需要序号或版本号来识别并丢弃过期消息。