[!info] related notes

• 所属 MOC：Messaging & Queues MOC、Backend 常用中间件与基础设施 MOC
• 主笔记：Apache Kafka、RabbitMQ
• 通用语义：消息投递语义、幂等消费者

Kafka 与 RabbitMQ 的选型边界

[!abstract] 核心结论 Kafka 更接近可长期保留和重放的分区事件日志；RabbitMQ 更接近通过 Exchange 路由到 Queue、由 Consumer ACK 的消息 Broker。先判断业务需要 Event Log 还是 Routed Work Queue，再比较吞吐、延迟和运维成本。

核心模型对比

Kafka
Topic → Partitioned Append-only Log
Consumer tracks Offset
Record remains until Retention / Compaction

RabbitMQ
Publisher → Exchange → Queue → Consumer
Broker tracks Delivery / ACK
Message normally leaves Queue lifecycle after ACK

对比表

维度	Kafka	RabbitMQ
核心模型	Durable Partitioned Log	Exchange + Queue + Binding
消费进度	Consumer Offset	Broker Delivery + ACK
数据保留	按 Retention / Compaction	ACK 后通常完成 Queue 生命周期
Replay	一等能力	普通 Queue 不是主模型；可用 Stream / 重投设计
路由	Topic、Key、Partition	Direct / Topic / Fanout / Headers
顺序	Partition 内日志顺序	Queue Delivery 顺序，业务完成顺序受并发/重试影响
横向扩展	Partition Parallelism	多 Queue / Consumer Parallelism
Retry / DLQ	常由 Topic 和应用策略组织	Broker 路由模型更自然
多下游	独立 Consumer Group	独立 Queue 绑定同一 Exchange
典型负载	CDC、Telemetry、Event Streaming	Job、Command、Task Routing

场景判断

订单事件给多个下游，并允许以后重放

order-created
├─ inventory group
├─ analytics group
├─ audit group
└─ recommendation group

如果吞吐高、保留历史、下游各自维护进度并需要 Replay，优先 Kafka。

上传图片后生成缩略图

upload completed
→ thumbnail queue
→ one worker processes
→ ACK / retry / DLQ

这是典型 Work Queue，RabbitMQ 更自然；小规模项目也可考虑 Redis-backed Job Queue。

数据库 CDC

DB change log
→ event stream
→ multiple projections

Kafka 的 Retention、Offset、Partition 和生态更匹配。

复杂 Routing Key

order.cn.vip
order.jp.normal
order.*

RabbitMQ Topic Exchange 通常比大量 Topic 和应用侧路由更直观。

顺序不是一句“谁保序”

Kafka

同一 Key 进入同一 Partition，可获得 Partition 内顺序。但并发处理、Retry 和异步写下游仍可能改变业务效果顺序。

RabbitMQ

Queue Delivery 有序，但多个 Consumer、不同处理耗时、NACK / Redelivery 会改变完成顺序。

设计前明确要求的是：

global order
per-entity order
broker delivery order
or final business state order

可靠性关注点

Kafka

producer ACK
replication / ISR
offset commit
consumer idempotency
transaction scope

RabbitMQ

publisher confirm
routing / mandatory return
queue durability / quorum
consumer ACK / prefetch
redelivery / DLQ

两者都无法消除网络不确定性，因此应用层 Message ID、幂等和业务约束仍然重要。

Exactly-once 不是第一选型条件

先问它覆盖到哪里：

• Producer → Broker；
• Broker 内部流处理；
• Offset / ACK；
• 外部 PostgreSQL；
• 支付或邮件 API。

跨外部系统的“业务只发生一次”通常仍依赖唯一约束、幂等键、Outbox、CDC、状态机和补偿。

性能比较的正确方式

不要只说“Kafka 吞吐高，RabbitMQ 延迟低”。真实性能取决于：

• Message Size；
• Batch / Compression；
• Replication / Durability；
• ACK / Confirm；
• Partition / Queue Topology；
• Consumer Logic；
• Disk / Network；
• Backlog 与 Retention。

产品模型匹配通常比未经测量的性能口号更重要。

决策树

需要长期保留、多个独立下游、Replay 或 CDC？
├─ Yes → Kafka
└─ No
   ↓
需要 Work Queue、复杂路由、逐条 ACK、Retry / DLQ？
├─ Yes → RabbitMQ
└─ No
   ↓
已有 Redis，任务简单、规模小？
├─ Yes → Redis Stream / Redis-backed queue
└─ No  → 按真实流量、语义和运维能力做 PoC

面试回答骨架

我不会先用吞吐量做结论。Kafka 的核心是 Partitioned Durable Log，Consumer 用 Offset 独立消费，适合 Retention、Replay、CDC 和多下游事件流；RabbitMQ 的核心是 Exchange、Queue、Binding 和 ACK，适合 Work Queue、复杂路由、Retry 与 DLQ。两者都要处理重复、幂等和跨数据库一致性，最终要结合顺序范围、保留需求、积压模式、可靠性和团队运维能力选择。

Related notes

• Apache Kafka
• RabbitMQ
• Redis