对标 Kafka：何时选谁

4.1架构对照：智能 broker vs 不可变日志

RabbitMQ 把状态、路由、ack 记账都压在 broker 里，消息 ack 即删；Kafka 的 broker 只追加不可变字节，不路由、不删除，消费进度由消费者自己用 offset 持有。

这条分叉在 01 章 §1.4 已被立为全教程的轴心。这里把它摆到 Kafka 旁边逐项展开：同一个"消息从生产者到消费者"的过程，两套系统把哪些职责放在了哪一侧。

底层机制（比文档深一层）：差异的根在"谁持有消费游标"。RabbitMQ 的 broker 为每个 queue 维护一份消息集合，每次投递分配一个 delivery tag 并把消息从 Ready 移到 Unacked；收到 ack 就从存储里抹掉这条。游标在 broker 内部，且是单调销毁的——读过的位置不再存在。Kafka 反过来：broker 把每个 partition 写成一个仅追加的 segment 文件序列，写入即定型，broker 对"谁消费到哪"一无所知；offset 是消费者自己提交到 __consumer_offsets 这个内部 topic 里的一个数字。因为消息不随消费而变，多个消费者读同一份字节互不干扰，任何一个都能把自己的 offset 倒回去重读。一句话：RabbitMQ 的状态机活在 broker 里，Kafka 的状态机活在消费者里。

4.2投递与消费：push/prefetch vs pull/offset

RabbitMQ 把消息 push 给消费者，用每消费者的 prefetch（最多多少条未 ack 在途）限流；Kafka 让消费者 pull——按 offset 长轮询拉取，速率由消费者自己定。

底层机制（比文档深一层）：RabbitMQ 的 push 是 broker 通过 basic.deliver 主动把消息帧推到消费者的 channel 上。流控的唯一旋钮是 prefetch（basic.qos 的 prefetch count）：它限定一个消费者最多有多少条"已推送但未 ack"的消息在途。prefetch 设 1，broker 推一条、等 ack、再推下一条，延迟最低但吞吐受单条往返限制；prefetch 设大，在途消息多、吞吐高，但若消费者处理慢，这些消息全卡在它手里（Unacked），其它空闲消费者也分不到。Kafka 的 pull 是消费者发 fetch 请求带上 offset，broker 用 long-poll——有数据立即返回，没数据则挂起到 fetch.max.wait.ms 再返回空，避免空轮询打爆 CPU。消费者一次能拉 max.poll.records 条，处理完再拉下一批，速率完全自控；一个慢消费者只是自己 offset 前进得慢，partition 里的数据不动，它随时能追上。push 把"会不会压垮消费者"的风险交给 broker 的 prefetch 旋钮去兜；pull 把这个风险从系统里消除了——消费者永远不会被喂太多。

4.3顺序与重放：RabbitMQ 的顺序为何易碎

Kafka 在一个 partition 内提供全序，同 key 进同 partition 即有序；RabbitMQ 按队列到达顺序投递，但 competing consumers 让完成顺序错位，requeue 还会把消息重新插回队列（常在头部），"FIFO 队列"不等于"FIFO 处理"。

消费并行与重放也在 01 章 §1.4 埋下了伏笔。这里把它和 Kafka 的 consumer group 摆在一起看。

底层机制（比文档深一层）：Kafka 的顺序来自"同 key 哈希到同一 partition + 一个 partition 在组内只归一个消费者"这两条的合力——同一实体的消息走同一条单线日志，被同一个消费者按 offset 顺序读，所以有序。RabbitMQ 的队列投递是按到达顺序的，但顺序在两处断裂：其一，competing consumers——broker 把消息一人一条地派给多个消费者，谁先处理完不取决于谁先拿到，msg-1 给了消费者 A、msg-2 给了消费者 B，B 更快，于是 msg-2 先完成，完成顺序和到达顺序脱钩。其二，requeue——一条被 nack 或因消费者断连而退回的消息，会被重新插入队列，常常插在队首（取决于版本与配置），于是它越过了本来排在它后面的消息，顺序当场被打乱（这个 requeue 回插的细节，01 章 §1.4 的状态机图里画过那条回环）。结论很反直觉：RabbitMQ 的 queue 是 FIFO 的数据结构，但一旦有并行消费或重投，得到的不是 FIFO 的处理。

要在 RabbitMQ 上复刻 Kafka 那种"按 key 有序又能并行"，得动用 consistent-hashing exchange（一致性哈希交换机，按消息 key 哈希到固定的某个 queue），把相关消息全路由到同一个 queue，再给该 queue 配单一活跃消费者（single active consumer，同一时刻只有一个消费者在消费这个队列）。等于用"一 key 一队列、一队列一消费者"手工搭出 Kafka 的 partition 语义——能做到，但要自己拼装，而 Kafka 里这是默认行为。

4.4吞吐与延迟：真实数字与原因

Kafka 在吞吐上压倒性领先，但赢的是吞吐不是单条延迟——在低负载下 RabbitMQ 的端到端延迟反而更低。

Confluent 2024 的基准测试（i3en.2xlarge 实例、3 个 broker、1 KB 消息、3 副本、4 producer/4 consumer）给出一组常被引用的数字：

底层机制（比文档深一层）：Kafka 赢吞吐有四个叠加的原因。① 顺序磁盘写——partition 是仅追加文件，每个字节只在一条优化了近十年的代码路径上落盘一次，顺序写对机械盘和 SSD 都远快于随机写。② OS page cache——Kafka 不自建缓存层，直接复用 Linux 页缓存，读多写少时数据热在内核内存里。③ zero-copy（零拷贝）——用 sendfile 把文件数据从页缓存直接送到网卡，不经过用户态的来回拷贝。④ producer 批量——基准里 producer 攒批至多 1 MB、最多等 10 ms（linger），把多条消息合成一次写、一次 fsync，把固定开销摊薄。RabbitMQ 的上限来自相反的设计：它要为每一条消息做路由匹配、维护 Ready/Unacked 状态、记 ack 账，逐条记账的固定开销无法摊薄；更关键的是每个队列由单个 Erlang 进程处理（single-process-per-queue bottleneck，03 章 §3.2 拆过），一个队列的吞吐被一个进程的单核能力封顶，30K msg/s 以上就撞到 CPU 墙。

4.5选型决策：RabbitMQ、Kafka、还是 Streams

复杂路由 / 每消息工作流 / RPC / 低延迟中等吞吐 → RabbitMQ；高吞吐事件流 / 重放 / 事件溯源 / 多独立消费者读同一份流 → Kafka；想要重放与扇出但留在 RabbitMQ 生态且吞吐要求不极端 → RabbitMQ Streams。

底层机制（比文档深一层）：第三个选项 RabbitMQ Streams 是 RabbitMQ 对 Kafka 的正面回应（GA 自 3.9，super-streams 分区在 4.x 稳定）。它是一个仅追加、可复制的日志，消费是非破坏性的——消费者按 x-stream-offset 附着到日志的某个位置（first / last / 某个 offset / 某个 timestamp），读过不删，可重放，多个消费者读同一份。4.2 进一步加了服务端 AMQP 1.0 的 SQL 风格 filter expression（服务端按表达式过滤，只下发命中的消息）。这把 Kafka 的几项核心能力搬进了 RabbitMQ：留存、重放、扇出给多读者。但它不等于 Kafka：一个 stream 仍然没有 classic/quorum 队列的 TTL / DLX / priority / 逐消息持久化语义；RabbitMQ 官方文档也直言——没有任何持久化队列类型能在吞吐上匹敌一个日志系统。所以 Streams 是从 RabbitMQ 这一端向 Kafka 收敛，而非完全取代；与此同时 Kafka 在 2024 年补上了 tiered storage（分层存储，热数据在本地盘、冷数据下沉到对象存储，便宜地长期留存并重放）。两个系统正从相反的出身互相靠拢：一个加日志语义，一个加廉价长留存。