Kafka 顺序消息到底值多少工程成本：单 partition 保序 vs 业务 ID 哈希分 partition vs 放弃全局顺序只保业务内有序，你们线上怎么取舍？

【背景】

我带过 3 个团队做过 Kafka 消息链路，每次遇到「同一业务流的消息必须按序消费」的需求，方案就分裂成 3 派，而且每派都有「我们线上就是这么跑的，没问题」的底气。

举个具体的：去年做一个支付对账链路，上游每笔交易产生 3~7 条事件（创建、风控、清算、通知），要求同一笔交易的事件严格按序到达下游记账服务。当时 3 个组的方案分别是：

• A 组：单 partition，靠 Kafka 天然保序。QPS 峰值 1200，单 partition 扛住了，但扩容只能加 consumer 不能加 partition。后来 QPS 翻到 3000 的时候 partition 成了瓶颈，加了 partition 之后顺序性又破了，最后靠「业务 ID 哈希到固定 partition」兜底，但热点 key 又成了新问题。
• B 组：按交易 ID 哈希到 64 个 partition。顺序性没问题，但热点交易（大客户批量下单）集中在少数 partition，峰值单 partition QPS 飙到 8000，consumer 端 poll 超时被踢出 group，rebalance 风暴持续了 40 分钟。
• C 组：放弃全局顺序，只在业务层做状态机校验（当前状态 + 事件类型 = 合法下一状态）。顺序性靠「乱序到达时拒绝并 requeue」实现，requeue 3 次后丢进 DLQ 人工处理。

【常见分歧 / 几种做法】

1. 全局顺序 vs 业务内顺序：到底需要哪种？很多团队默认要「全局顺序」，但真正拆开看，90% 的场景只要「同一业务 ID 内有序」，跨业务 ID 的顺序根本没人关心。
2. partition 粒度：按业务 ID 哈希是最常见的做法，但热点 key 怎么办？加 partition 数？引入本地内存队列做 key 级串行？还是直接接受部分乱序？
3. 生产端 vs 消费端保序：Kafka 只保证 partition 内顺序。消费端如果多 consumer 线程处理同一 partition（线程池消费），顺序性就丢了。你们是在 producer 端保证 partition 内有序，还是在 consumer 端做线程级串行？
4. 顺序性的代价：单 partition 意味着吞吐上限 = 单 partition 的写入/读取速率。你们线上单 partition 峰值 QPS 多少？超过多少就开始考虑「顺序性降级」？

【我的倾向与理由】

如果让我重新设计上面的对账链路，我会选 C 组方案（状态机校验兜底）+ 一个补充：producer 端按交易 ID 哈希到 partition 保证「大概率有序」，consumer 端用状态机校验兜底「万一乱序」。理由：

• 状态机校验的额外成本极低（一次 DB 查状态 + 一个条件判断，P99 增加 < 2ms），比维护 partition 映射关系和热点 key 治理简单得多；
• 热点 key 问题彻底消失，因为不依赖 partition 粒度，扩容就是加 partition；
• 代价是「乱序消息需要 requeue 或跳过」，但实际线上乱序率 < 0.01%（主要出现在 rebalance 窗口内），requeue 3 次兜底足够。

但我不确定这在「高 QPS + 低延迟」场景下还成立——如果 P99 要求 < 50ms，requeue 的 RTT 成本（跨机房 3~8ms × 3 次）可能就不划算了，还是得回到 partition 保序。

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

1. 你们线上「顺序消息」的实际 QPS 和 partition 数是多少？单 partition 峰值扛了多少？什么时候你们开始觉得「顺序性」成了瓶颈？
2. 热点 key 你们怎么处理的？加 partition？本地队列串行？还是直接接受部分乱序 + 业务层补偿？
3. 有没有人踩过「consumer 端多线程消费导致顺序性丢失」的坑？怎么发现的、怎么修的？（我见过一个案例：consumer 用 8 线程池处理同一 partition，偶发顺序乱，排查了 3 天才定位到线程池）
4. 你觉得「状态机校验兜底」和「partition 保序」哪个在你们的场景下 ROI 更高？给个具体的 QPS / P99 / 团队规模，方便大家对号入座。