按「经典消息队列」和「Kafka 兼容流平台」分开看。Kafka 现默认 KRaft（不必再上 ZooKeeper）。
经典消息 / 流平台
| 名称 | 模型 | 事务 | 顺序 | 延时消息 | 多租户 | 典型场景 | 主要短板 |
|---|---|---|---|---|---|---|---|
| Kafka | 日志式发布订阅 | 支持 | 分区内有序 | 需业务或外部实现 | ACL / 配额模拟 | 大数据、事件溯源、日志 | 运维与存储成本偏高 |
| Pulsar | 队列 + 流 | 支持 | 分区 / Key 有序 | 原生任意延时 | 原生租户 / 命名空间 | 云原生、多租户、队列流合一 | 组件多（Broker + BookKeeper） |
| RocketMQ | 点对点 + 发布订阅 | 强 | ShardingKey 有序 | 原生（分级 / 定时） | 支持 | 电商、金融、事务消息 | 国际生态小于 Kafka |
| RabbitMQ | 点对点 + 发布订阅 | 部分（Confirm / 事务） | 单队列有序 | TTL + DLX 模拟 | vhost | 复杂路由、传统集成 | 海量吞吐不如日志型 |
| NATS JetStream | 发布订阅 + 流 | 弱 / 不强调 | 有序消费者 | 定时交付 | 账户隔离 | 微服务、IoT、低延迟 | 能力面小于 Kafka 全家桶 |
| Redis Streams | 流 + 消费者组 | 不支持 | 单 Stream 有序 | 需业务模拟 | DB / 前缀隔离 | 已有 Redis、轻量实时 | 不是专用 MQ，持久与堆积有上限 |
| NSQ | 发布订阅 | 不支持 | 弱保证 | 不支持 | 弱 | 简单高吞吐任务 | 语义简单、生态窄 |
| ActiveMQ | JMS 点对点 + 主题 | 支持 | 弱于分区模型 | 插件 / TTL | vhost | 遗留 Java / JMS | 性能与云原生体验一般 |
Kafka 兼容 / 云原生流平台
协议兼容 Kafka 客户端，主打更简单运维或更低存储成本。
| 名称 | 实现路径 | 存储 | 延迟取向 | 兼容性 | 核心亮点 | 主要短板 | 适合 |
|---|---|---|---|---|---|---|---|
| Apache Kafka | 原版 | 本地盘 + 分层存储（KIP-405） | 低～中 | 基准 | 生态最全（Connect / Streams / ksqlDB） | JVM、扩缩与跨 AZ 成本 | 要完整生态、自管或 MSK 等 |
| Redpanda | C++ 重写 | 本地盘 + 分层 / Iceberg Topics | 极低（亚 10ms 级常见） | 高（偶有边缘差异） | 单二进制、无 JVM、运维简单 | 许可证（BSL）限制需注意 | 低延迟、要简单自管 |
| AutoMQ | Kafka 代码 + 换存储 | WAL + 对象存储（S3 等） | 中（可调） | 极高（原生 Kafka 测试） | 存算分离、长保留成本低、弹性好 | 强依赖云盘 / 对象存储设计 | 云上长保留、成本敏感 |
| WarpStream（Confluent） | Go，S3-native | 基本直接对象存储 | 高（数百 ms 级常见） | 核心 API；事务等能力需核对 | 磁盘less、BYOC / 托管省心 | 不适合硬实时 | 日志 / 观测等可容忍延迟 |
推荐
- 大数据 / 事件流 / 生态最全 → Kafka（自管或云托管）。
- 低延迟 + 运维简单、Kafka 协议 → Redpanda。
- 云上长保留、要压存储与弹性成本 → AutoMQ；可容忍较高写入延迟的托管向 → WarpStream。
- 多租户 + 队列流合一 → Pulsar。
- 事务 / 顺序 / 电商金融 → RocketMQ。
- 复杂路由、传统集成 → RabbitMQ。
- 轻量低延迟微服务 → NATS；已有 Redis → Redis Streams。