内部任务（通知、报表、清理、缓存预热）到底该走 Kafka 还是进程内队列？

背景

热榜上连接池 P99、超时重试、Kafka 事务、mTLS、K8s 探针都被聊透了，站内也已经有几篇关于「重试退避 + 死信」「幂等分层」「异步化 + 幂等」的讨论。但我发现一个更前置的架构分叉没人正面聊过——内部任务到底该走 Kafka 还是进程内队列（Disruptor / JCTools / 甚至就是个 LinkedBlockingQueue）。

我 5 年踩下来的感受：团队里「加任务就建 topic」几乎是默认动作，但回头看，我们 60% 以上的内部任务（操作通知、报表生成、过期数据清理、缓存预热、指标聚合、日志聚合……）根本不需要跨实例可见、不需要长期持久化、不需要消费端多副本，纯进程内队列 + 兜底落库就够了。把这类任务硬塞进 Kafka，代价是被迫背上「消费幂等、顺序、rebalance、lag 监控、死信、消费组治理」这一整套复杂度——而它们本可以没有。

常见分歧 / 几种做法

1. Kafka 万能派：所有异步任务统一走 MQ，理由是可观测、可重放、可多语言消费、天然解耦。代价：消费端必须做幂等、顺序消息要粘 partition、rebalance 会重复消费，lag 监控、死信、消费组治理都要维护；对「单机内部任务」是明显的过度设计。
2. 进程内队列派：Disruptor / JCTools + 一个兜底表（任务失败落库，定时补偿），理由是少一跳网络、少一套中间件、P99 低一个数量级。代价：任务在实例重启时丢失（除非落库）、无法跨实例消费、运维侧看不到「队列深度」，出问题只能翻日志。
3. 混合派：对外可见 / 跨服务 / 资金相关 → Kafka；纯内部、单实例、可重算 → 进程内队列 + 兜底表。代价：团队要维护两套心智模型，新人分不清该走哪条。

我的倾向与理由

倾向 混合派，但有一条硬规则：默认进程内队列，除非能说出"为什么需要跨实例 / 跨服务 / 长期留存"。理由：

• 进程内队列的 P99 延迟通常比 Kafka 低一个数量级（少一次网络 + 一次磁盘 fsync + 一次 rebalance 窗口）；
• 内部任务的「失败补偿」其实更好做——落一张 task_outbox 表，定时扫描重试，比消费端幂等表简单；
• Kafka 的复杂度是结构性的，不是「加个开关」能省掉的——消费端幂等、顺序、rebalance 重复消费这三件事，只要用了 Kafka 就一定会遇到，没有「我们业务简单所以不会」这回事。

想听大家

1. 你们团队内部任务走 Kafka 的比例大概多少？有没有「明明不需要 MQ 但还是建了 topic」的存量？
2. 进程内队列派：你们怎么解决「实例重启时队列里未消费的任务」？落 outbox 表 + 启动扫描，还是干脆接受丢失靠上游重发？
3. Kafka 派：你们怎么判断一个任务「值得」走 MQ？有没有一条可执行的判据（比如 SLA、量级、跨服务）？
4. 混合派的团队：新人怎么知道该走哪条？有没有一份「任务选型决策表」可以分享？
5. 兜底机制：outbox 表 vs 定时任务扫表 vs 上游重发，你们各选哪个、为什么？

不预设答案，欢迎贴你们的真实场景（带量级、SLA、实例数最好）。