TL;DR

  • 场景: 传统 IBM MQ 与新系统共存，需要开源、可运维、可扩展、一致性/可靠性
  • 结论:
    • RabbitMQ: 适合「可靠性优先的业务解耦」
    • RocketMQ: 适合「事务/顺序/延迟消息」
    • Kafka: 适合「数据管道/日志/流处理」
  • 产出: 选型对照表 + 部署注意事项 + 错误速查卡

中间件选型原则

选型标准

  1. 开源: 必须开源以保证透明度和自主权
  2. 流行度: 近期趋势技术，社区活跃
  3. 核心功能需求:
    • 消息传输可靠性
    • 集群支持能力
    • 出色的性能

RabbitMQ

概述: 基于 AMQP 协议，轻量级且易于部署。

优点

  1. 轻量高效:

    • 安装包小（几十 MB）
    • 秒级启动
    • 支持 Docker

  2. 灵活路由:

    • Direct Exchange: 精确路由键匹配
    • Fanout Exchange: 广播到所有绑定的队列
    • Topic Exchange: 支持通配符匹配

  3. 多语言支持:

    • 官方支持 Java、.NET、Python
    • 社区支持 30+ 语言

缺点

  1. 消息积压问题: 队列超过 10 万条消息时，吞吐量下降 50%+
  2. 性能限制:
    • 持久消息: 约 50,000-80,000 TPS
    • 非持久消息: 约 100,000-150,000 TPS
  3. Erlang 技术栈: 插件开发需要 Erlang 知识

RocketMQ

概述: 阿里巴巴开源的分布式消息中间件，基于 Java。

典型应用场景

  1. 顺序消息处理（如订单状态变更）
  2. 分布式事务消息（如电商系统）
  3. 实时流计算
  4. 消息推送通知

优点

  1. 功能全面:

    • 发布/订阅和 P2P 模式
    • 消息顺序、事务消息、定时消息、消息追踪

  2. 对开发者友好:

    • Java 实现，源码结构清晰
    • SPI 扩展机制支持

  3. 性能:

    • 平均响应时间 < 3ms
    • 单机: 10W+ TPS
    • 集群模式: 百万级吞吐

缺点

  1. 生态集成: Prometheus 集成有限
  2. 运维复杂: 多副本同步配置复杂

Kafka

概述: 为高吞吐设计的分布式流处理平台。

优点

  1. 高可靠性: 多副本机制确保不丢失数据
  2. 出色的稳定性: LinkedIn、Uber 验证；MTBF 高达 99.99%
  3. 丰富的特性: Exactly-once 语义、事务消息、消息重放
  4. 生态兼容: 与 Hadoop、Spark、Flink 深度集成
  5. 出色性能:
    • 单机: 100,000+ TPS
    • 集群模式: 百万级 TPS

技术特性

  1. 可扩展架构:

    • 基于分区的水平扩展
    • Consumer Group 机制实现线性消费扩展

  2. 持久存储:

    • 默认 7 天保留
    • 顺序读写 + 页缓存技术

  3. 副本与容错:

    • 多副本支持（通常 3 副本）
    • ISR 机制确保数据一致性

整体对比

FeatureRabbitMQRocketMQKafka
语言ErlangJavaJava/Scala
协议AMQPCustomCustom
TPS50K-150K100K+100K-2M
LatencyLowVery LowMedium
OrderingSupportedSupportedSupported
TransactionSupportedStrongSupported
EcosystemGoodModerateExcellent

选型建议

  1. 选择 RabbitMQ:

    • 可靠性优先于性能
    • 复杂路由需求
    • 中等吞吐量需求（数万 TPS）

  2. 选择 RocketMQ:

    • 需要事务消息支持
    • 需要顺序消息
    • 金融/交易系统

  3. 选择 Kafka:

    • 高吞吐量需求（数十万+ TPS）
    • 数据管道/日志处理场景
    • 需要与大数据生态集成

错误速查

RabbitMQ 问题

症状根因修复
吞吐量下降，延迟抖动队列积压、内存压力检查队列深度；通过队列拆分、TTL+DLQ 减少积压

RocketMQ 问题

症状根因修复
发送超时NameServer 路由不一致、Broker 压力确保 NameServer HA；优化 Broker 参数

Kafka 问题

症状根因修复
Consumer Lag 上升分区不足、下游慢增加分区；优化批处理；控制 rebalance
ISR 收缩Broker I/O 瓶颈升级磁盘/网络；调整副本参数