消息中间件选型的「一致性」与「性能」的终极权衡：你选 Kafka 还是 RabbitMQ？

【背景】 在分布式系统中，消息中间件是「数据一致性」与「系统性能」的终极战场。我们团队在 2018 年从 RabbitMQ 迁移至 Kafka 时，曾用 3 个月验证了「高吞吐」的诱惑，但也踩中了「Exactly-Once 语义」的坑。

【常见分歧】

• Kafka 派：认为其分区机制天然适合日志类场景，且 2023 年 2.8 版本后对 Exactly-Once 的支持已足够成熟；
• RabbitMQ 派：强调其 AMQP 协议对复杂路由的灵活性，且在 2022 年通过 Streams 模块补足了流处理能力；
• 中间派：用 Pulsar 的多租户架构做折中，但其生态成熟度仍存疑。

【我的倾向】 目前我们使用 Kafka 的 3.4 版本，通过以下策略平衡了一致性与性能：

1. 生产端：启用 idempotent producer，配合 Kafka 3.4 的 transactional id 机制；
2. 消费端：用 Kafka Streams 做本地状态管理，避免跨节点的 Exactly-Once 事务；
3. 监控层：通过 Prometheus + Grafana 监控 P99 与 backlog，当 P99 > 200ms 时自动触发扩容。

【想听你的观点】 你在什么场景下选择 Kafka？又在什么场景下用 RabbitMQ？请用具体数字说明你的选型依据：

• 每秒吞吐量（TPS）
• 消息最大延迟（ms）
• 一致性保障等级（Exactly-Once/At-Least-Once）
• 你的「性能悬崖」临界值（如 P99 > X ms 时强制切换）