Kafka
最初由 LinkedIn 为解决海量日志收集问题而设计，其本质是一个分布式提交日志（distributed commit log）系统，而非传统意义上的消息队列。它的核心优势在于高吞吐、持久化存储和可回溯性。Kafka 将消息以追加写（append-only）方式顺序写入磁盘，并利用操作系统的页缓存（page cache）和零拷贝（zero-copy）技术，极大减少了 I/O 开销，单集群轻松支撑每秒数十万甚至上百万条消息的写入。同时，所有消息在 broker 上持久化保存，消费者通过维护 offset 来控制消费进度，这意味着即使消费者宕机数日，重启后仍可从指定时间点或偏移量重新消费历史数据。这一特性使其在日志聚合、用户行为埋点、监控指标上报、数据库变更捕获（CDC）以及作为 Flink、Spark 等流处理引擎的数据源等场景中无可替代。
然而，Kafka 的消费模型基于拉取（pull-based），消费者需主动轮询获取消息，若处理逻辑缓慢，会导致消费延迟（lag）累积。此外，Kafka 仅保证单一分区（partition）内的消息顺序，若业务需要全局严格有序（如订单状态变更），必须将所有相关消息路由至同一分区，这会限制水平扩展能力。虽然自 0.11 版本起支持事务以实现 exactly-once 语义，但配置复杂且对性能有一定影响，通常不推荐在高频交易类业务中使用。
RabbitMQ
RabbitMQ 是一款遵循 AMQP（Advanced Message Queuing Protocol）标准的传统企业级消息代理（message broker）。它的设计目标是提供可靠、灵活、语义丰富的消息传递服务。RabbitMQ 支持多种交换器（Exchange）类型，包括 direct（精确匹配）、topic（模式匹配）、fanout（广播）和 headers（基于消息头路由），允许开发者根据业务需求构建复杂的路由拓扑。例如，一个订单创建事件可同时被库存服务、物流服务和积分服务订阅，而无需生产者关心具体消费者。
在可靠性方面，RabbitMQ 提供了完善的机制：消息可标记为持久化（persistent），队列也可配置为持久化，配合发布确认（publisher confirms）和消费者手动 ACK（acknowledgement），确保消息在 broker 故障或消费者异常时不会丢失。镜像队列（Mirrored Queues）进一步提升了高可用性。这些特性使 RabbitMQ 成为金融交易、支付回调、订单状态通知等对消息可靠性要求极高的场景的首选。但其代价是吞吐量相对较低，单机通常在 1–2 万 QPS 左右，难以应对大数据量或高频事件流的压力。此外，RabbitMQ 默认采用推模式（push-based），broker 主动将消息推送给消费者，若消费者处理能力不足，可能导致内存溢出或连接中断，需合理配置 prefetch count 以平衡负载。
RocketMQ
RocketMQ 由阿里巴巴内部研发并开源，定位于云原生时代的高性能业务消息中间件，试图在 Kafka 的高吞吐与 RabbitMQ 的丰富语义之间取得平衡。它采用主从架构（现支持 Dledger 集群实现自动选主），通过顺序写 CommitLog 和 ConsumeQueue 索引分离的设计，兼顾了写入性能与查询效率。RocketMQ 的突出优势在于其原生支持多种高级消息特性。
首先是顺序消息：通过 MessageQueueSelector 接口，可将同一业务实体（如订单 ID）的消息路由到同一个 MessageQueue，从而保证严格 FIFO 顺序，且无需牺牲整个 Topic 的吞吐。
其次是事务消息：采用“半消息 + 本地事务执行 + 状态回查”机制，生产者先发送一条不可见的半消息，执行本地数据库事务后再提交或回滚消息，若 broker 未收到最终状态，则主动回调生产者检查事务结果。这一模式优雅地解决了分布式事务中“本地操作与消息发送原子性”的难题，广泛应用于电商下单、资金转账等场景。
第三是延迟消息：内置 18 个延迟级别（从 1 秒到 2 小时），直接调用 setDelayTimeLevel 即可实现订单超时取消、优惠券过期提醒等功能，无需依赖死信队列等复杂变通方案。这些开箱即用的能力，加上十万级每秒的吞吐量和良好的中文生态，使 RocketMQ 成为国内互联网企业的主流选择。
为了更清晰地把握 Kafka、RabbitMQ 与 RocketMQ 三者的核心差异，以下从多个关键维度进行系统性对比：
| 维度 | Kafka | RabbitMQ | RocketMQ |
|---|---|---|---|
| 核心定位 | 分布式日志流平台 | 企业级消息队列（AMQP） | 云原生业务消息中间件 |
| 典型吞吐量 | 百万级/秒 | 1–2 万/秒（单机） | 10 万+/秒 |
| 消息模型 | Topic-Partition（拉模式） | Exchange-Queue-Binding（推模式为主） | Topic-MessageQueue（拉模式） |
| 持久化 | 默认持久化，磁盘存储 | 需显式开启，内存+磁盘 | 默认持久化，CommitLog 顺序写 |
| 消息回溯 | ✅ 原生支持（按 offset 或时间） | ❌ 消费即删，无法回溯 | ✅ 支持按时间回溯 |
| 顺序性 | 单 Partition 内严格有序 | 单 Queue 有序（需单消费者） | 原生支持顺序消息（按 Key 路由） |
| 事务消息 | ✅（0.11+，配置复杂） | ❌（需业务补偿） | ✅ 原生支持（半消息+回查） |
| 延迟消息 | ❌（需外部调度） | ⚠️ 死信队列 + TTL（间接实现） | ✅ 内置 18 级延迟（1s–2h） |
| 路由能力 | 弱（仅靠 key 分区） | ✅ 强（Direct/Topic/Fanout/Headers） | ✅ 支持 Tag 和 SQL92 过滤 |
| 可靠性保障 | 副本 ISR + acks=all | 持久化队列 + 手动 ACK + 镜像队列 | 同步刷盘 + 主从复制 + 消息轨迹 |
| 消费失败处理 | 手动控制 offset | 死信队列（DLX） | 重试队列 + 死信队列 |
| 协议支持 | 自定义二进制协议（基于 TCP） | AMQP、MQTT、STOMP 等 | 自定义协议（兼容部分 JMS） |
| 运维复杂度 | 高（依赖 ZooKeeper/KRaft，调优项多） | 中（Erlang 技术栈，集群配置复杂） | 中（NameServer 轻量，Dashboard 完善） |
| 典型应用场景 | 日志收集、埋点、流计算、CDC | 订单通知、支付回调、服务解耦 | 电商交易、金融核心、延迟任务 |
Redis 虽然常被用作缓存，但其数据结构也支持轻量级队列功能。通过 LPUSH/RPOP 或更可靠的 BRPOPLPUSH 命令，可实现简单的生产者-消费者模型；而 Redis Stream 则提供了更接近专业 MQ 的能力，支持消费者组、ACK 机制和消息回溯。由于所有操作在内存中完成，Redis 队列具有极低的延迟和极高的吞吐（可达十万级/秒），非常适合瞬时流量削峰（如秒杀请求缓冲）、非关键异步任务（如发送营销邮件、记录非核心日志）等场景。尤其当系统已部署 Redis 作为缓存时，复用其队列能力可避免引入新组件，降低架构复杂度。
然而，Redis 并非为消息传递而生，其可靠性存在天然短板。尽管可通过 AOF 持久化减少数据丢失风险，但在主从切换或持久化间隔内仍可能丢消息。List 模式下，消息一旦被 RPOP 取出即从队列消失，若消费者处理失败，消息将永久丢失；Stream 虽支持 XACK，但缺乏重试队列、死信队列等企业级特性。因此，Redis 队列绝不应承担任何不可容忍丢失的核心业务消息传递任务。
在实际工程实践中，选型应基于一套清晰的决策框架。首先评估消息规模与吞吐需求：若日均消息量达亿级以上或峰值 QPS 超过 10 万，Kafka 几乎是唯一选择；若在万级 QPS 以内，RabbitMQ 或 RocketMQ 更合适。其次考察可靠性要求：金融、支付等场景必须选择具备强持久化与 ACK 机制的 RabbitMQ 或 RocketMQ；而可容忍少量丢失的日志、监控数据则可用 Kafka 或 Redis。第三，分析消息语义需求：是否需要事务？是否需要延迟投递？是否要求严格顺序？RocketMQ 在这些方面提供最完整的原生支持。第四，考虑现有技术栈与运维能力：若团队已熟练掌握 RabbitMQ，且业务无特殊需求，不必强行迁移至 Kafka；若项目已重度依赖 Redis，且队列任务简单，可暂用其 Stream 功能，但需制定兜底补偿策略。
此外，还需警惕若干常见陷阱。例如，在 Kafka 中，初始创建 Topic 时若 partition 数设置过少，后续扩容虽可增加 partition，但会导致历史消息与新消息的 key 分布不一致，破坏顺序性；在 RabbitMQ 中，每个消费者默认建立独立 TCP 连接，微服务实例数激增时可能耗尽 broker 的文件描述符；在 Redis 中，若使用 List 而非 Stream，务必通过 BRPOPLPUSH 实现“取出即备份”，并在处理成功后手动删除备份消息，否则故障时数据将不可恢复。
综上所述，Kafka、RabbitMQ、RocketMQ 和 Redis 各有其明确的定位与适用边界。Kafka 是日志与流处理领域的王者，RabbitMQ 是企业级可靠消息的典范，RocketMQ 是高并发业务消息的全能选手，而 Redis 则是轻量级异步任务的便捷工具。技术选型的本质不是追求“最先进”，而是寻找“最合适”。只有深刻理解业务需求、数据特征与系统约束，才能做出稳健、可持续的架构决策，避免因中间件错配而付出高昂的重构代价。在分布式系统日益复杂的今天，这种基于场景的理性选择，远比盲目追逐技术潮流更为重要。