在高并发场景下，如果业务侧重复杂路由、严格顺序和高可靠性，优先选 RabbitMQ；如果侧重海量数据吞吐、日志收集和流式处理，优先选 Kafka。
先说结论：两者设计哲学不同，RabbitMQ 是智能路由代理，Kafka 是分布式日志流，高并发不等于只选 Kafka。
- 适合：RabbitMQ 适合交易、订单、任务调度；Kafka 适合日志、埋点、大数据同步。
- 重点看：消息是否允许丢失、是否需要回溯历史数据、运维团队技术储备。
- 别忽略：Kafka 依赖 ZooKeeper 或 KRaft 的运维复杂度，RabbitMQ 队列堆积后的性能下降风险。
选型核心指标
选型不是比谁性能更高，而是比谁更匹配业务场景。先确认以下三点再决定：
- 吞吐量量级：如果消息量在万级到十万级每秒，两者都能胜任；如果达到百万级每秒且主要是日志流，Kafka 更有优势。
- 消息可靠性：金融级交易要求消息绝不丢失且顺序严格，RabbitMQ 的 ACK 机制和队列模型更成熟；大数据场景允许少量重复但要求高吞吐，Kafka 更合适。
- 运维成本：Kafka 集群部署和调优复杂度高于 RabbitMQ，如果团队没有专门的大数据运维经验，RabbitMQ 上手更快。
架构与存储差异
RabbitMQ 和 Kafka 的核心差异在于架构模型和存储方式。RabbitMQ 实现了 AMQP 协议，核心是“交换器 - 队列”模型，生产者将消息发给交换器，交换器根据路由键将消息存入队列，消费者从队列拉取消息，消息消费后通常会被删除。这种模型适合复杂的路由逻辑和即时消费场景。
Kafka 的核心抽象是分布式持久化日志，消息按主题分区存储，消费者通过维护偏移量来读取消息，消息不会被立即删除而是保留一定时间。这种设计使得 Kafka 具有极高的吞吐量，支持消息回溯，但牺牲了部分实时性和复杂路由能力。性能表现依赖硬件与配置，通常 Kafka 在顺序写场景下吞吐量更高，RabbitMQ 在低延迟复杂路由场景下表现更稳。
实操验证与压测
按照以下步骤进行技术选型验证，建议使用官方提供的压测工具进行基准测试：
- 定义业务指标：明确预期的消息吞吐量、延迟要求（毫秒级还是秒级）、消息保留时间。
- Kafka 压测命令示例：
bin/kafka-producer-perf-test.sh `--topic` test-topic `--num-records` 1000000 `--record-size` 1024 `--throughput` 10000 `--producer-config` config/producer.properties - RabbitMQ 压测命令示例：
rabbitmq-perf-test `--id` "bench-test" `--uri` amqp://guest:guest@localhost:5672 `--size` 1024 `--rate` 10000 `--confirm` - 架构匹配度检查：如果需要复杂的路由规则（如根据消息头路由），RabbitMQ 的 Exchange 类型更丰富；如果需要多消费者组重复消费同一份数据，Kafka 的分区模型更天然支持。
- 故障演练：模拟 Broker 节点宕机，验证消息是否丢失，消费是否能自动恢复。
关键配置参数对比
高并发场景下，默认配置往往无法满足需求，需针对关键参数进行调优：
| 参数项 | Kafka 配置 | RabbitMQ 配置 | 影响说明 |
|---|---|---|---|
| 消息确认 | acks=all | publisher_confirm=true | 确保消息不丢失，但会增加延迟 |
| 批量发送 | batch.size=16384 | 客户端聚合 | 增大批次可提升吞吐量 |
| 预取数量 | N/A | prefetch_count=10 | 控制消费者负载，避免堆积 |
| 持久化 | log.segment.bytes | durable=true | 影响磁盘 IO 和重启恢复速度 |
高可用配置注意
生产环境必须配置高可用，避免单点故障导致数据丢失：
- Kafka 副本机制：创建 Topic 时设置
replication.factor >= 3，并配置min.insync.replicas=2，确保 ISR 集合中至少有 2 个副本同步成功才确认写入。 - RabbitMQ 镜像队列：经典队列需配置 Ha-Policy 为
ha-mode: all或nodes；推荐使用 Quorum Queues（仲裁队列）以获得更好的一致性和容错能力。 - 版本兼容性：Kafka 客户端与服务端版本差异可能导致协议不兼容，升级前需查阅官方兼容性矩阵。
监控与验收标准
选型落地后，通过以下指标验证系统是否健康，以下为参考阈值：
- 积压监控：观察队列或分区 lag 值，RabbitMQ 关注 Queue 长度（建议<10000），Kafka 关注 Consumer Lag（建议<1000）。
- 延迟统计：记录消息生产时间戳与消费时间戳的差值，确认是否满足业务 SLA（如 P99 < 50ms）。
- 错误日志：检查中间件日志是否有频繁的 Rebalance、Connection Reset 或 Nack 信息。
- 资源水位：监控磁盘 IO 等待和网络带宽，Kafka 对磁盘顺序写依赖较高，RabbitMQ 对内存和网络更敏感。
常见坑与排查
- Kafka 消息顺序：Kafka 仅保证分区内有序，如果需要全局有序，需要特殊设计，不要默认认为 Kafka 能保证全局顺序。
- RabbitMQ 队列堆积：当消息堆积过多时，RabbitMQ 性能可能显著下降，需要配置镜像队列或启用懒队列模式（Lazy Queue）。
- 运维依赖：旧版本 Kafka 强依赖 ZooKeeper，运维链路长；新版本虽支持 KRaft，但需确认客户端支持情况。
- 消息重复消费：网络抖动可能导致 ACK 丢失，消费者需实现幂等性逻辑，避免数据重复处理。