[!info] related notes

• 上层入口：Backend Engineering MOC、Backend 常用中间件与基础设施 MOC
• 相邻地图：Distributed Systems MOC、Reliability Engineering MOC
• 具体实现：Apache Kafka、RabbitMQ、Redis Stream
• 架构入口：事件驱动架构

Messaging & Queues MOC

知识总览

filters:
  and:
    - 'file.ext == "md"'
    - 'file.inFolder("z")'
    - 'this.file.links.contains(file)'
    - 'file.path != this.file.path'
formulas:
  knowledge: 'file.asLink(title)'
properties:
  formula.knowledge:
    displayName: 知识
  note.description:
    displayName: Description
  note.mastery:
    displayName: Mastery
views:
  - type: table
    name: 知识总览
    order:
      - formula.knowledge
      - note.description
      - note.mastery
    columnSize:
      formula.knowledge: 280
      note.description: 760
      note.mastery: 56

[!abstract] 核心认识 消息系统把生产者和消费者在时间、部署与处理速度上解耦，但同时引入重复、乱序、积压、ACK、重试和跨系统一致性。先学可靠性语义，再学具体 Broker。

先区分三种意图

Command / Job
→ “请某个 Worker 完成这件事”

Event
→ “这件事已经发生，感兴趣的下游可以响应”

Event Log
→ “事件历史需要长期保留、独立消费和重放”

产品可能覆盖多个模式，但业务语义不能混用。

推荐阅读顺序

1. Async Task Queue：为什么把慢任务移出请求链路。
2. 事件驱动架构：Producer、Event、Consumer 与耦合边界。
3. 消息投递语义：at-most-once、at-least-once 与 exactly-once 边界。
4. 幂等消费者：重复投递怎样不重复产生业务效果。
5. Backpressure：消费者跟不上时怎样限制在途和积压。
6. 分布式事务：DB 与 Broker 的可靠双写。
7. Apache Kafka：Partitioned Log、Offset、Retention 与 Replay。
8. RabbitMQ：Exchange、Queue、ACK、Routing 与 DLQ。
9. Kafka 与 RabbitMQ 的选型边界。

一条消息的可靠生命周期

Producer
  ↓ publish + id
Broker / Log
  ↓ durable accept / confirm
Consumer
  ↓ process business effect
Business DB / External API
  ↓
ACK / Offset Commit
  ↓ failure handling
Retry / DLQ / Alert / Replay

每个箭头都要定义失败窗口，而不是笼统说“消息可靠”。

三种重点实现

模型	代表	核心进度	最自然的场景
Durable Partitioned Log	Kafka	Consumer Offset	Event Stream、CDC、Replay
Routed Queue	RabbitMQ	Delivery + ACK	Job、Command、复杂路由、DLQ
Lightweight Stream	Redis Stream	Consumer Group + PEL	已有 Redis 的中小规模消息场景

Kafka

重点：Topic / Partition / Offset、Producer ACK、Replication / ISR、Consumer Group、Rebalance、Retention、Replay、Lag 与 KRaft。

RabbitMQ

重点：Exchange / Queue / Binding、Publisher Confirm、Consumer ACK、Prefetch、Retry / DLX、Quorum Queue。

Redis Stream

重点：Entry ID、Consumer Group、Pending Entries、Claim、Trim 和“何时应该升级为专用消息平台”。

五个核心故障窗口

1. Producer 发送后超时，不知道 Broker 是否已接收；
2. Broker 已持久化，但 Producer 没收到 Confirm；
3. Consumer 已写业务库，但 ACK / Offset Commit 丢失；
4. ACK / Offset 先提交，业务处理随后失败；
5. DB 已提交，事件却没有发布。

对应手段可能包括 message ID、幂等键、唯一约束、manual ACK、offset 管理、Transactional Outbox、CDC、DLQ 和补偿。

选型原则

需要长保留 + 独立消费 + Replay / CDC？
→ Kafka

需要 Work Queue + Routing + Retry / DLQ？
→ RabbitMQ

已有 Redis，任务简单且规模有限？
→ Redis Stream / Redis-backed queue

不要只用“吞吐高低”选型，先匹配数据模型和故障语义。

面试检查表

• ACK / Offset Commit 应该放在业务处理之前还是之后？
• at-least-once 为什么是常见工程选择？
• exactly-once 到底覆盖 Broker 内部还是外部业务副作用？
• Consumer Lag / Queue Depth 上升时如何区分生产过快、消费变慢和分区不均？
• poison message 为什么不能无限立即重试？
• DB + Broker 双写为什么需要 Outbox / CDC？
• 顺序要求是全局、Partition 内、Queue delivery，还是业务最终效果顺序？

Related notes

• Backend 常用中间件与基础设施 MOC
• Distributed Systems MOC
• Reliability Engineering MOC