【背景】 带 3 年团队，最近两次技术评审都卡在同一个问题：一个「下单成功后发积分/写审计日志/通知下游」的旁路操作，研发想直接发 Kafka，理由是"标准做法、以后好扩展"；我倾向先做本地重试表（outbox 思路的简化版：业务库事务内写一条 pending 记录，后台 worker 扫表重试，指数退避 + 最大次数 + 死信人工队列）。两边都能自圆其说，最后靠投票定的——这件事让我觉得我们缺一套可复用的判据，而不是每次都现场辩论。
【常见分歧，我见过三种做法】
- MQ 优先派：异步解耦、削峰、重试、顺序、回溯都是现成的；本地重试表要自己造轮子（扫表调度、退避、幂等、死信），维护成本被低估。
- 本地表优先派：业务库事务里落一条记录天然"不丢"，比"先写库再发消息"的中间态简单；MQ 反而引入 broker 依赖、消费延迟、consumer group 运维，对低频旁路是杀鸡用牛刀。
- 看量级派：QPS < 某阈值、消息生命周期 < 某时长、不需要跨服务消费，就用本地表；否则上 MQ。但"某阈值"具体是多少，没人说得清。
【我的倾向与理由】 我倾向把判据收敛成三个硬条件，同时满足才用 MQ：
- 有第二个（或未来的第二个）独立消费者：只有单一消费方时，MQ 的解耦收益是虚的，本地表 + worker 就是一条"进程内总线"；
- 消息生命周期 > 进程重启周期：需要跨重启、跨机器、可回溯（rebalance/复投）的，本地表其实也能做到（表就是持久化），但 MQ 的分区与 offset 语义更省事；
- 吞吐或削峰需求真实存在：能给出峰值/均值比的数据。说不出来的"以后可能峰值高"，我按没需求算。
不满足时，本地重试表 + 幂等消费（消费端按业务主键去重，这条无论哪种方案都逃不掉）是我默认方案。理由：依赖面小、故障模式可控（最坏就是 worker 停了，表里数据还在，扫出来就能追），而且本地表本身可以平滑升级为 outbox + MQ（worker 从"直接执行"改成"投递 MQ"），反过来降级就没那么顺了。
一个常被忽略的细节：本地重试表的扫描一定要带退避分桶（比如按 next_retry_time 落 1s/5s/30s/2min 几个桶，worker 按桶轮询），否则表一多，全表扫 + WHERE next_retry_time < now() 就是定时抖动源，这个我在 500 万行级别的表上踩过。
【想听大家】
- 你们团队有没有一条写下来的、可执行的判据（而不是口头共识）？阈值定在哪，依据是什么数据？
- 本地重试表做到什么量级（行数 / QPS / 重试深度）开始痛到必须迁 MQ？迁移时消费端幂等键怎么从"本地表主键"切到"MQ 消息 ID"，有没有不留双写窗口的做法？
- 有没有"上了 MQ 又退回来"或"本地表扛不住被迫上 MQ"的真实案例，当时的量级和触发点是什么？
- 顺带一问：如果消费端幂等是必做项，"at-least-once + 幂等"和"exactly-once"的差距，在你们业务里到底体现在哪（成本？故障率？还是纯粹是面试话术？）。
欢迎带数据来，纯观点也行，我按场景整理成判据清单沉淀下来。
0赞
0收藏
0楼层