顺序消息到底要保到哪一级？全局顺序 / 分区顺序 / 单键顺序，你们线上到底怎么定？

【背景】 带团队做过订单履约、支付对账、IM 三条链路，发现"保顺序"这件事，成本差异能差出 10 倍以上，但团队里对"到底要保到哪一级"经常没共识——写代码的人默认"顺序消息"三个字就完事了，没人在设计评审时把粒度掰开谈。

我把它拆成四档，成本从低到高、语义从弱到强：

1. 不保序：producer 直接发，consumer 侧靠"版本号 / 状态机 / 幂等键"兜底乱序。适合事件溯源、最终一致、下游本来就幂等的场景。
2. 单键顺序：按业务键（orderId / merchantId / userId）hash 到 partition，同 key 严格 FIFO，跨 key 并行。Kafka 的 partition key、RocketMQ 的 MessageQueue 选择器都是这一档。
3. 分区顺序：一个业务域一个 partition，域内全序，跨域并行。常见于"一个商户的所有流水必须有序"这种需求。
4. 全局顺序：单 partition + 单 consumer，全链路严格 FIFO。吞吐直接打骨折，但实现最简单、心智负担最小。

【常见分歧 / 几种做法】

• 团队 A：默认全局顺序，"简单不出错"——结果 partition 数=1，producer 侧排队，P99 从 20ms 涨到 300ms。
• 团队 B：默认单键顺序 + 消费端状态机——出过一次"重放时状态机漏了一个中间态"的 bug，线上补了 3 天才收敛。
• 团队 C：分区顺序 + 消费端不保序（靠版本号丢弃旧消息）——出过一次"broker 重启后版本号回退"的故障，因为 producer 侧版本号是本地自增的。
• 团队 D：干脆不保序，下游全幂等 + 事件溯源回放——成本最高，但语义最干净，适合审计 / 回放型业务。

【我的倾向与理由】 我默认走 单键顺序 + 消费端状态机，理由：

• 全局顺序 90% 的场景是过度设计——业务真正需要的只是"同一个订单的状态迁移有序"，不是"所有订单的流水有序"。
• 单键顺序把吞吐打散到 partition 数，consumer 侧还能并行，成本可控。
• 消费端状态机 + 幂等键是"最后一道兜底"，即使 broker 重放 / 分区 rebalance 导致乱序，也能靠版本号丢弃旧消息收敛——但版本号必须全局单调（雪花 / 数据库发号），不能本地自增。
• 全局顺序我只在两个场景用：审计日志回放、金融级对账流水——这两个场景吞吐本来就低，全局顺序的代价可以接受。

【想听大家在什么场景下怎么选】

1. 你们线上有没有被迫上全局顺序的场景？最后是怎么妥协的（降吞吐 / 拆业务 / 加下游兜底）？
2. 单键顺序 + 状态机踩过什么坑？版本号回退、rebalance 乱序、重放风暴，你们各自怎么处理的？
3. 有没有团队直接放弃顺序性、靠"事件溯源 + 幂等"扛下来的？成本到底高多少，值不值？
4. 一个具体的争点："同一个 key 的乱序"和"不同 key 的乱序"，下游能不能用同一套幂等逻辑兜底？ 我见过两种做法，想听听大家的取舍。

欢迎贴你们线上的真实案例，越具体越好（partition 数、key 设计、consumer 并发度、出过什么故障）。