问题现象

做技术选型时，团队最容易卡住的一步是把消息中间件当成通用组件：既然两者都能收发消息，随便挑一个应该都行。真正上线后问题才集中暴露。

现象一：用 RabbitMQ 承接日志采集和埋点数据，峰值时段队列迅速积压，磁盘被撑满，运维只能临时扩容；而同样的数据量换到 Kafka 上却稳如磐石。

现象二：用 Kafka 做业务系统的异步解耦（下单后发通知、扣库存、生成凭证），原本期望「消费一次就是一次」，结果因为消费端 bug 重放消息，同一笔订单被重复处理，出现重复扣减。

现象三：需要按规则把消息分发到不同的下游服务（比如按地区、按会员等级路由），用 Kafka 实现后写了一堆自定义 topic 和分发逻辑，维护成本远超预期。

现象四：为了「先进」选用了 Kafka，但团队对它内部的消费者组、分区、位移提交机制理解不足，出问题不敢重启，也不敢改分区数，陷入不敢动的状态。

现象五：选了 RabbitMQ 之后才发现，业务需要回溯三天前的数据重新计算，而消息在被确认消费的那一刻就已经删除了，历史数据无从找回。

原因分析

表面上是两个产品都叫「消息队列」，实际它们的设计目标完全不同。

投递语义不同。RabbitMQ 是传统的消息代理，消息被消费者取出并确认（ack）后就从队列中删除，它维护每个消息的状态：已投递、已确认、未确认。这种「阅后即焚」的模型天然适配任务分发，但不适合做数据留存。Kafka（以及 RabbitMQ 的 Stream 队列）底层是一个只追加的不可变日志，消息写入后不会被删除