消息队列选型（Java 视角）

• 各自吞吐水平
• 架构与吞吐的关系
• 选型

吞吐量大致排序：Kafka > RocketMQ > RabbitMQ。Kafka 基于磁盘顺序写 + 分区并行 + 零拷贝，吞吐百万级/秒，适合大数据流；RocketMQ 基于磁盘顺序写 + 队列并行，吞吐数十万级/秒，适合高吞吐消息；RabbitMQ 基于内存 + 确认机制，吞吐相对较低（数万~几十万级），更侧重可靠性与路由灵活。吞吐差异源于架构：Kafka/RocketMQ 倾向批处理与日志追加，RabbitMQ 每条确认开销大。选型：需要极致吞吐（日志、流计算）用 Kafka；高吞吐 + 可靠投递（交易、订单）用 RocketMQ；中等吞吐 + 灵活路由用 RabbitMQ。

吞吐是架构决定的（日志追加 vs 逐条确认）。按业务吞吐量需求与可靠性/路由需求综合选型。

• 各自可靠性机制
• 持久化与副本
• 确认与幂等

可靠性上三者都支持"至少一次（at-least-once）"并可配合幂等实现"不丢不重"。Kafka：acks=all + 多副本 + 幂等/事务，可靠性高（副本同步）；RabbitMQ：Publisher Confirms + 队列持久化 + Quorum Queue 多副本，可靠性高；RocketMQ：同步刷盘 + 从副本 + 事务消息 + 消费 ack，可靠性高。差异：Kafka 靠副本与 ISR 保证副本一致性，RocketMQ 支持同步刷盘与多副本，RabbitMQ 靠确认与仲裁队列。三者都需消费端 ack 与幂等共同保证端到端不丢。选型上可靠性要求高的交易场景（RocketMQ 事务消息、Kafka 事务）各有优势。

可靠性 = 发送确认 + 存储持久副本 + 消费确认。三者都具备，但侧重点不同（Kafka 副本、RocketMQ 事务、RabbitMQ 确认）。

• 各自运维难度
• 组件与依赖
• 监控与调优

运维复杂度大致：Kafka > RocketMQ > RabbitMQ。Kafka 依赖 KRaft（原 ZooKeeper 已移除）、多 broker、分区副本管理、监控指标多，配置复杂，运维难度高；RocketMQ 有 NameServer/Broker 组件，运维中等，功能多（事务、延迟消息）；RabbitMQ 相对轻量，但集群/镜像/仲裁队列、内存与磁盘管理需注意，运维中等偏易。监控上 Kafka 需 JMX/Prometheus 全面监控（副本、积压），RocketMQ 有 Dashboard，RabbitMQ 有管理界面。选型：小团队/轻量用 RabbitMQ，中等用 RocketMQ，大规模流式用 Kafka（需专业运维）。

运维复杂度与功能丰富度、组件数量、监控需求相关。越强的吞吐与功能往往运维越复杂。

• Stream 的能力
• 内存/持久化/吞吐边界
• 适用场景

Redis Stream 作为轻量消息队列，能力包括消费者组、PEL、ACK、阻塞消费、at-least-once，适合小规模、低延迟、与 Redis 生态集成的场景。边界：一是数据受内存限制，无法承载海量历史（可持久化但弱于 MQ 的磁盘日志）；二是吞吐有限（单线程，不如 Kafka/RocketMQ）；三是持久化与副本语义弱于专业 MQ（RDB/AOF 与故障恢复复杂）；四是功能少（无分区扩展、无事务、无延迟级别等）。Redis 官方建议 Stream 仅用于轻量消息场景，不适合大规模高吞吐、需长时保留、需强一致性的场景。当消息量/可靠性/重放需求上升时，应迁移到 Kafka/RocketMQ。

Stream 的边界是"轻量"，超出内存/吞吐/可靠性/功能需求就是边界，需评估数据规模与可靠性要求决定是否用专业 MQ。

• 各维度对比
• 选型矩阵
• 场景决策

选型矩阵维度：吞吐（Kafka 最高 > RocketMQ > RabbitMQ）、可靠性（三者都高，各有侧重：Kafka 副本、RocketMQ 事务、RabbitMQ 确认）、延迟（RabbitMQ/RocketMQ 低延迟、Kafka 吞吐优先延迟略高）、生态（Kafka 大数据/流处理生态最强，RocketMQ 阿里云/Java 生态强，RabbitMQ 通用 AMQP 生态、Spring 集成好）。决策：大数据流/日志/事件溯源用 Kafka；高吞吐 + 可靠投递 + 事务消息（订单/交易）用 RocketMQ；灵活路由/低延迟/通用集成用 RabbitMQ；轻量低延迟用 Redis Stream。矩阵按"吞吐需求、可靠性等级、延迟要求、生态依赖"综合打分选型。

选型不是单一指标，而是按吞吐/可靠性/延迟/生态四维矩阵匹配业务场景，结合团队运维能力与现有技术栈。

• 日志追加与分区有序
• rebalance 对消费的影响
• Java 消费端处理

Kafka 的日志语义：消息按 offset 追加到分区日志，分区内有序、可重放（seek 到任意 offset）；消费者组内分区被一个消费者消费，保证分区内有序。rebalance 影响 Java 消费端：消费者加入/退出/超时触发 rebalance，分区重新分配，期间消费中断、offset 可能重提交，导致重复消费。Java 消费端需处理：一是幂等（rebalance 后可能重复消费）；二是处理慢（max.poll.interval 超时）引发 rebalance 的调优；三是用 Cooperative 协议减少中断；四是监听 rebalance 回调（ConsumerRebalanceListener）做清理/提交。分区有序 + rebalance 是 Java 消费端可靠与有序的基础。

Java 消费端要在"分区有序"与"rebalance 重分配"之间保证正确：幂等消重复、合理 poll 避免触发 rebalance、监听回调管理位移。

• 自建 vs 云托管
• 成本、运维、SLA
• 选型决策

自建 Kafka：成本可控（硬件资源）、可定制、无厂商锁定，但需自建运维（集群部署、监控、扩缩容、补丁），SLA 靠自身保障，运维人力成本高。云托管 MQ（SQS/阿里云 RocketMQ）：省运维、弹性伸缩、提供高 SLA（如 99.95%）、免运维监控，但按量计费（成本随规模增长）、有厂商锁定与数据出网成本。选型：规模小/团队小/追求 SLA 用云托管；规模大/需深度定制/有运维能力/数据合规自建用 Kafka。决策因素：数据量、团队运维能力、SLA 要求、成本预算、合规需求。云托管适合"快速上线 + 高可用"，自建适合"大规模 + 定制 + 成本可控"。

自建 vs 云托管是"控制权/成本 vs 省运维/SLA"的权衡。核心看运维能力、规模与 SLA 要求。

• RocketMQ 半消息 + 回查
• Kafka 事务（协调器 + 幂等）
• 两者差异

RocketMQ 事务消息：先发半消息（prepare，消费者不可见），执行本地事务，成功返回 COMMIT 使半消息可见，失败返回 ROLLBACK；本地事务状态未知时 broker 回查（checkLocalTransactionState）确认。它把"本地事务"与"消息发送"通过半消息 + 回查耦合，实现最终一致，不依赖跨系统事务协调。Kafka 事务：通过事务协调器（transaction coordinator）与 transactional.id，把消息写入多个分区 + 消费偏移放在一个原子事务（read_committed），但它只协调 Kafka 内部，不介入数据库，跨系统需 Outbox。差异：RocketMQ 事务消息面向"业务本地事务 + 发消息"（事务消息 API），Kafka 事务面向"Kafka 内部跨分区/跨主题原子"；RocketMQ 半消息机制是其特征。

RocketMQ 事务消息用"半消息+回查"桥接业务本地事务，Kafka 事务用"协调器+幂等"桥接 Kafka 内部。两者解决不同层面的原子性。

• 流处理（高吞吐）
• 任务队列（可靠分发）
• 事件溯源（日志重放）

业务驱动选型：流处理（实时计算、日志、指标）需要高吞吐、多消费者、可重放，选 Kafka（分区日志 + 消费者组 + 流处理生态）；任务队列（订单、异步任务、削峰）需要可靠分发、灵活路由、ack 重试，选 RabbitMQ/RocketMQ（确认、重试、死信）；事件溯源（事件日志、状态重建）需要持久化、重放、有序，选 Kafka/Pulsar（日志语义 + 重放）。决策依据是业务形态：流处理要吞吐与重放，任务队列要可靠与路由，事件溯源要持久与有序。选型前先明确业务类型的核心诉求。

选型是"业务类型 -> 核心诉求（吞吐/可靠/持久/有序）-> MQ 特性"的映射。流处理、任务队列、事件溯源诉求不同。

• JMS 兼容与迁移
• Artemis 相比经典 ActiveMQ 的改进
• 迁移成本

Artemis（ActiveMQ Artemis，5.x 起成为 ActiveMQ 核心）是 JMS 兼容的下一代消息中间件，API 兼容 JMS，因此既有 JMS 技术栈（ConnectionFactory/JmsTemplate/@JmsListener）迁移成本低——Spring 的 JMS 抽象无需改动即可连接 Artemis。相比经典 ActiveMQ（5.x 之前的 Broker 引擎），Artemis 改进：基于 Netty 的非阻塞 IO（高吞吐）、支持 AMQP/MQTT/STOMP 多协议、更好的集群与高可用（replication）、更现代的存储（append-only journal）、更好的性能与可扩展性。迁移成本：API 层兼容，主要成本在部署/配置（连接信息、协议端口）与运维切换，业务代码基本不变。

Artemis 是 ActiveMQ 的现代引擎，JMS API 兼容使迁移成本低，改进在性能、协议支持与集群高可用。

• 消费限流
• 批量拉取
• 死信与重放

消息积压治理：一是消费限流——控制消费速率（如 max.poll.records、prefetch、速率限制），避免消费端过载；二是批量拉取——一次拉取多条批量处理（batchListener、批量消费），提升吞吐；三是死信队列——把无法处理的消息转入死信，避免阻塞正常消息消费；四是重放——积压缓解后从积压点重放（seek/回源）处理。配合：先定位积压原因（消费慢/死信阻塞/下游慢），批量消费提升吞吐，限流保护下游，死信隔离失败消息，重放补齐积压。监控 lag（积压量）是治理前提。Java 侧用 @KafkaListener 批量 + 并发 + 死信处理 + seek 重放组合。

积压治理是"提升吞吐（批量）+ 保护下游（限流）+ 隔离失败（死信）+ 补齐（重放）"的组合，先监控 lag 定位原因。

• RocketMQ 半消息时序
• Kafka 事务协调器
• 回查差异

RocketMQ：先发半消息（prepare，不可见），执行本地事务，返回 COMMIT/ROLLBACK；本地事务状态未知时 broker 回查（checkLocalTransactionState）。时序是"半消息 -> 本地事务 -> 提交/回滚 -> 回查兜底"。Kafka：通过事务协调器 + transactional.id，beginTransaction -> 发送消息（同事务）-> commitTransaction 原子提交；不需半消息，靠协调器与日志记录事务状态，消费者 read_committed 只读已提交；Kafka 无"回查本地业务"机制（它不介入业务本地事务，只协调 Kafka 内部读写）。差异本质：RocketMQ 事务消息桥接"业务本地事务 + 发消息"（有回查），Kafka 事务协调"Kafka 内部跨分区/主题"（无业务回查，跨系统需 Outbox）。

RocketMQ 事务消息面向业务本地事务（半消息+回查），Kafka 事务面向 Kafka 内部原子（协调器+幂等），范围与回查机制不同。

• Kafka 分区有序
• RocketMQ 队列有序
• 顺序消费实现

Kafka 分区内有序：消息按 offset 追加到分区，消费者组内一个分区被一个消费者串行消费，保证分区内有序；用 key 哈希路由使相关消息进同一分区。RocketMQ 队列内有序：消息写入 Queue，MessageListenerOrderly 用队列锁串行消费 Queue 内消息保证有序；用 key 哈希/指定选择 Queue。异同：两者都是"分区/队列内有序 + 跨分区不保证"，并行度 = 分区/队列数；Kafka 天然分区内有序（日志追加 + 单消费者），RocketMQ 顺序消费需显式 MessageListenerOrderly（加锁）。跨分区/队列的全局有序两者都不支持，需单分区 + 业务 key 路由。

两者顺序粒度都是"分区/队列"，Kafka 靠日志+单消费者天然有序，RocketMQ 靠顺序消费监听器加锁实现，跨分区不保证全局有序。

• 削峰填谷与异步解耦
• 引入 MQ 的成本
• 不适合场景

削峰填谷：MQ 承接瞬时高峰请求，下游按能力消费，避免打垮下游；异步解耦：生产者与消费者解耦，异步处理。适用场景：高峰流量平缓（秒杀、下单）、异步任务（通知、日志）、多系统解耦。不适合场景：需要强一致/实时同步返回（交易卡单、需立即确认）、数据量很小（引入 MQ 成本大于收益）、对延迟极敏感（MQ 增加延迟）、无需削峰/解耦的简单同步调用。引入 MQ 的代价：增加复杂度（运维、一致性、幂等、监控）、消息可能丢失/重复、延迟增加。应评估"是否真的需要削峰/解耦/缓冲"，避免过度设计。

MQ 的价值在削峰/解耦/缓冲，代价是复杂度与一致性。强一致、实时返回、小数据量场景不宜引入 MQ。

• 消费者扩容
• 批量消费
• 死信处理与监控

消息堆积治理：一是消费者扩容——增加消费者（Kafka 上限分区数，RocketMQ 上限队列数），提升并行度；二是批量消费——一次拉取多条批量处理，提升吞吐；三是死信处理——把无法消费的消息转死信，避免阻塞堆积；四是监控指标——监控 lag（积压量）、消费速率、处理耗时，定位堆积原因。配合：先监控 lag 量与消费速率判断是"投递多"还是"消费慢"，消费慢则扩容/批量/优化下游，失败消息死信隔离，积压高峰后按需重放。监控指标是治理前提，告警可及时响应。

堆积治理是"扩容提并行 + 批量提吞吐 + 死信隔离失败 + 监控定位"，指标驱动、闭环治理。

• 延迟级别（18 级）
• 定时消息原理
• 精度限制

RocketMQ 延迟消息用"延迟级别"（默认 18 级：1s、5s、10s、30s、1m、2m... 等），发送时指定 delayTimeLevel，broker 按级别把消息调度到对应延迟队列，到期后转投正常队列。定时消息（5.x 支持任意时间戳）通过 Message.setDelayTimeMs/schedule 精确到指定时间。精度限制：延迟级别是离散的（只能选预定义级别，不能任意秒数，5.x 已支持任意毫秒）；延迟消息由 broker 定时扫描（schedule 线程）触发，精度受扫描间隔影响（非精确到毫秒级）；延迟消息积压会影响调度精度。Java 侧用 RocketMQ 客户端 API 设置延迟级别/时间即可。

RocketMQ 延迟消息基于"延迟级别 + 定时扫描"，精度受离散级别与扫描间隔限制，5.x 支持任意定时时间但精度仍非毫秒级。

• RocketMQ 延迟级别
• Kafka 时间轮（TimingWheel）
• 实现差异

RocketMQ 延迟消息用"延迟级别"：把消息归入预定义的 18 个延迟级别队列，broker 定时扫描到期消息转投，实现简单但延迟是离散的（只能选级别）。Kafka 本身不内置延迟消息，但可用"时间轮"（TimingWheel，如 Kafka 的 TimingWheel/DelayedOperation）实现延迟调度：把延迟任务按时间桶分层轮转，到期触发，支持任意时间的精确调度（毫秒级），效率高（O(1) 插入）。差异：RocketMQ 是离散级别、broker 定时扫描；Kafka 时间轮是精确的哈希轮 + 层级，可任意延迟。若需 Kafka 延迟消息，需自行实现或扩展（如延迟 topic 或第三方）。选型：对延迟精度要求高用时间轮式实现。

延迟级别是"离散 + 定时扫描"，时间轮是"精确 + 哈希轮分层"，时间轮精度更高、扩展性更好，实现更复杂。

• Pulsar 存储计算分离
• BookKeeper 分段存储
• 与 Kafka 集成存储差异

Pulsar 采用"存储计算分离"架构：Broker 无状态负责读写，底层用 BookKeeper 存储（ledger 分段日志）。数据按 Segment 分段追加到 BookKeeper，支持流式卸载（tiered storage 到 S3/GCS）。差异：Kafka 是"存储计算耦合"（broker 既处理请求又存本地磁盘日志），分区固定每个 broker；Pulsar 存储与计算分离，Broker 可水平扩展，数据分层存储（热数据在 BookKeeper，冷数据可卸载到对象存储），扩容/缩容更灵活，数据可长期保留。差异体现在：存储 vs 计算松耦合、Segment 管理与分层存储、broker 无状态高可用。Pulsar 更适合需要长保留、弹性扩展、多租户的场景。

Pulsar 存储计算分离靠 BookKeeper 与 Segment 分层，Kafka 存储计算耦合靠本地日志。这决定了两者扩展性、保留能力与多租户差异。