同一业务实体的消息「保序」还是「保吞吐」？单分区有序 vs 多分区+版本号，你们线上到底选了哪个、为什么？

楼主江墨白

消息中间件Kafka分布式一致性高并发消息顺序幂等

【背景】

社区最近幂等聊得热火朝天——at-least-once + 幂等、幂等窗口 TTL 定多长、exactly-once 到底够不够，帖子一串串。但有一个维度我观察下来几乎没人认真讨论：顺序。

具体场景：订单链路里，「创建订单 → 扣减库存 → 支付回调 → 更新订单状态」这四条消息，业务 key 都是 orderId。如果四条消息由同一个生产者按序发到同一分区、同一消费者串行处理，Kafka 的分区内有序保证够用，没问题。

但真实系统里，这四条消息往往不是同一个生产者发的——订单服务发「创建」、库存服务发「扣减」、支付网关发「回调」——它们可能落在不同 topic、不同分区、不同消费者组。这时候「有序」就不存在了，你只能自己兜底。

我带团队做了 5 年消息中间件相关的事，这个问题我们内部吵了至少三轮，每次大促前都要重新对齐一次。今天把三种做法、代价和我的判断标准摆出来，想听听大家线上到底怎么选。

【三种常见做法及代价】

做法一：单分区有序（传统做法） 同一 orderId 的所有消息 hash 到同一分区，单消费者串行处理。

好处：消费端逻辑最简单，不需要版本号、不需要状态机，顺序天然保证。
代价：吞吐上限 = 单消费者处理能力。我们 2019 年做支付链路时，单分区峰值 QPS 卡在 1.2w，压到 1.5w 就出现 poll 超时（max.poll.interval.ms=300s 被单条消息里 90s 的外部 API 调用吃掉，rebalance 触发），最后只能扩分区、重新分配 hash 规则，停机 40 分钟做数据迁移。
适用：核心链路、QPS 可预测、单分区吞吐够用。

做法二：多分区并行 + 版本号/状态机（现代做法） 允许乱序，消费端用「消息携带的 sequence 号 >= 当前已处理的最大 sequence 号」判断是否该处理，旧消息直接丢弃或异步补偿。

好处：吞吐线性扩展，单分区 QPS 不再是瓶颈。
代价：消费端逻辑复杂度翻倍。我们 2022 年从做法一迁到做法二后，消费端 P99 从 45ms 降到 12ms（不再串行等锁），但消费端代码量从 800 行涨到 2400 行，「状态机漏迁移」和「旧消息覆盖新状态」成了 top-3 线上 bug 来源。一次生产事故：库存服务发了一条 sequence=7 的「回滚扣减」，晚于 sequence=9 的「确认扣减」到达，消费端按「7 < 9，丢弃」处理了，结果库存多扣了 3 件，对账才发现，补了 2 小时。
适用：非核心链路、QPS 不可预测、需要弹性扩缩。

做法三：按业务实体 hash 到固定分区 + 分区内保序（折中） 同一 orderId 仍落在同一分区保序，不同 orderId 可以并行。

好处：兼顾了顺序和并行度，消费端不需要状态机。
代价：热点 key 打爆单分区。我们双 11 时 top-10 大卖家占了 34% 的订单量，单分区 QPS 峰值 8.7w，消费者 OOM 了两次，最后临时加了本地队列削峰（JVM 内 10w 容量 ArrayBlockingQueue）才扛过去，但这是临时方案，长期不优雅。
适用：业务实体分布均匀、热点 key 占比 < 10%。

【我的倾向与判断标准】

我现在的默认做法是按链路分层：

核心链路（支付、库存扣减、账务记账）：做法一（单分区有序）+ 消费端幂等 + 版本号兜底（双保险）。理由是这条链路 P99 要求 < 50ms，串行处理可预测性强，不需要为 5% 的极端吞吐场景引入状态机复杂度。分区数按「峰值 QPS / 单分区安全 QPS（留 30% 余量）」算，而不是按消费者数算。
非核心链路（通知、日志、数据分析）：做法二（多分区并行 + 宽松顺序），消费端只记 max-processed-sequence，不维护完整状态机，最终一致即可。
判断标准（一句话）：如果「乱序处理」的业务代价（对账成本、资损风险、客诉量）> 「单分区吞吐上限」的扩容成本（加机器、扩分区、做 hash 迁移），就保序；反之就放开。

这个判断标准看起来像废话，但我在三个团队里用下来，能帮团队在 30 分钟内对齐，不用再吵「到底要不要状态机」。

【想听大家】

欢迎带具体数字来聊，空泛的「看场景」可以聊，但最好说清楚你的场景是什么 QPS、什么 P99 要求、什么团队规模。

0赞 0收藏 0楼层