消息队列 — 异步是解耦的代价，也是它的全部价值Kafka vs RabbitMQ vs SQS · Delivery Semantics · Backpressure · Dead Letter Queue

问题场景与约束

设计一个电商「订单事件总线」：用户下单后，订单服务产生一条 order.created 事件，要被 5 类下游 各自独立消费——库存扣减、积分发放、推荐更新、数据仓库入仓、风控审计。这些下游处理速度天差地别：库存扣减 2ms，数仓批量入仓一条要 200ms。

硬约束：

• 规模：日订单 5000 万，大促峰值 50 万 events/s（含订单的下游放大）。
• 不丢单：订单事件丢一条 = 一笔钱对不上。要求至少一次（at-least-once） 投递。
• 下游可独立扩缩：数仓慢，不能拖垮库存；任一下游挂掉，恢复后能补上积压。
• 同一订单的事件有序：created → paid → shipped 不能乱序，否则状态机错乱。
• 毒消息隔离：某条事件让某个消费者反复崩溃，不能阻塞整条流。

今天讲：为什么这个场景必须用消息队列而非同步 RPC、Kafka / RabbitMQ / SQS 怎么选、投递语义的本质、backpressure 与消费积压、以及 DLQ 怎么兜底毒消息。

高层架构

核心思路：一份事件、多个独立 Consumer Group，各自维护 offset，互不影响——这是 pub/sub fan-out。Producer 用 ack=all + 幂等保证不丢；按 order_id 分区保证单订单有序；慢消费者积压只影响自己；重试耗尽的消息进 DLQ 不阻塞主流。

关键技术点

1. 选型：Log (Kafka) vs Broker (RabbitMQ) vs Managed (SQS)

核心 trade-off：留存可重放的日志 vs 灵活路由的智能 broker vs 零运维的托管队列。

原理：三者是三种不同的抽象。Kafka 是分布式 append-only log：消息写入 partition 后不因被消费而删除，consumer 只是移动自己的 offset，因此天然支持多订阅者 fan-out、回放历史、高吞吐顺序 IO。RabbitMQ 是智能 broker：消息经 exchange 按 routing key 投到 queue，消费 ack 后即删除，强在灵活路由（topic/fanout/header exchange）和单条消息粒度控制。SQS 是 AWS 全托管队列：无需运维，弹性近无限，但功能最简（标准队列无序、FIFO 队列有序但限流）。

2. 投递语义：at-most-once / at-least-once / exactly-once

核心 trade-off：不丢 vs 不重 不可兼得（无幂等时）；工程上的「恰好一次」= 至少一次 + 幂等。

原理：投递语义取决于 ack 与处理的先后。At-most-once：先 ack（提交 offset）再处理——崩溃则消息丢失，绝不重复，适合可丢的指标采样。At-least-once：先处理再 ack——崩溃在 ack 前则重投，绝不丢失但可能重复，是绝大多数业务的默认选择。Exactly-once：网络层面不可达（两将军问题），但可以通过至少一次投递 + 消费端幂等/去重在「效果上」实现每条恰好生效一次。

def consume(msg):
    if dedup.exists(msg.event_id):   # 去重表 / 唯一约束
        commit_offset(msg); return     # 重复投递, 跳过
    process(msg)                       # 业务: 扣库存 / 加积分
    dedup.insert(msg.event_id)
    commit_offset(msg)                 # 先处理后提交 = at-least-once
    # 崩在 process 后 / commit 前 → 重投, 靠 dedup 兜住

3. Backpressure 与消费积压：慢消费者不能拖垮上游

核心 trade-off：buffer（吸收突发） vs drop / 限流（保护系统）——队列把同步背压变成了可观测的 lag。

原理：生产速率 > 消费速率时，消息堆积。同步 RPC 里这表现为调用方阻塞、线程耗尽、级联雪崩；消息队列把它转化为 consumer lag（offset 落后量），是一个可监控、可缓冲的指标。应对手段分两类：扩容消费（加 consumer，但受 partition 数上限——一个 partition 同组内只能被一个 consumer 消费）；限制生产（producer 限流 / 拒绝，把压力推回源头）。Kafka 的 log 模型让积压「躺在磁盘上」相对安全；RabbitMQ 队列积压在内存/磁盘则可能触发 flow control 阻塞 producer。

while True:
    batch = consumer.poll(max_records=500, timeout=100ms)
    lag = end_offset(partition) - current_offset
    if lag > HIGH_WATERMARK:
        scale_out_signal()        # 触发 autoscaler 加 consumer
    process_batch(batch)          # 批处理摊薄固定开销
    consumer.commit()             # 批量提交一次 offset

4. Dead Letter Queue：毒消息的隔离区

核心 trade-off：无限重试（阻塞队列） vs 丢弃（丢数据） vs DLQ（隔离 + 留证据）。

原理：某条消息因数据畸形、下游 bug、依赖永久不可用而反复处理失败，称为毒消息（poison message）。若无限重试，它会卡住整个 partition / queue（尤其有序队列，后面的消息全被堵）；若直接丢，则丢数据无追溯。DLQ 的做法：重试 N 次仍失败，把消息连同失败上下文移到一个专门的死信队列，主流继续前进；之后人工或自动分析 DLQ，修复后 redrive 回主队列重放。

def handle(msg):
    try:
        process(msg)
    except NonRetryable as e:     # 畸形数据, 重试无意义
        to_dlq(msg, reason=e); return
    except Retryable as e:
        if msg.attempts >= MAX_RETRY:
            to_dlq(msg, reason=e, attempts=msg.attempts)
        else:
            requeue(msg, delay=backoff(msg.attempts))

扩展与优化

• 分区数要预留：partition 数决定消费并行度上限，且减少 partition 很麻烦（会破坏 key→partition 映射）。建 topic 时按未来峰值估容量，宁多勿少（但太多会增加 broker 元数据与 rebalance 开销）。
• 有序性的代价：全局有序 = 单 partition = 无法并行。本场景只需单订单有序，所以按 order_id 分区——既有序又能横向扩展。这是「分区键即并行单元」的核心权衡。
• Tiered Storage：Kafka 把冷数据卸到对象存储（S3），让长留存（回放、合规审计）不再受本地磁盘限制。
• Schema Registry：用 Avro/Protobuf + schema registry 做兼容性演进，避免上游改字段打挂所有下游（事件总线的隐形杀手）。
• 多区域 / 灾备：MirrorMaker 2 / uReplicator 跨区复制；要想清楚 active-active 下的 offset 与去重问题。

常见陷阱与面试问题

面试可能追问：

1. Kafka 和 RabbitMQ 的本质区别？什么场景非 Kafka 不可、什么场景 RabbitMQ 更合适？
2. at-least-once 怎么做到「效果上 exactly-once」？幂等 key 放哪、去重表怎么清理？
3. 一个 topic 100 个 partition，consumer group 里 150 个 consumer，会发生什么？
4. 消费积压了 1 亿条，怎么快速追上？有哪些手段、各自代价？
5. 有序队列里出现一条毒消息，整条队列卡死，怎么办？DLQ 怎么设计？
6. Producer ack=0/1/all 分别什么语义？什么时候会丢消息？

深入资源

• 《Designing Data-Intensive Applications》Ch 11 §Stream Processing（Kleppmann）：消息系统、log、投递语义最完整的工业级讨论。
• Confluent — Exactly-Once Semantics Are Possible: Here's How Kafka Does It：幂等 producer + 事务的权威讲解。
• Confluent Docs — Message Delivery Guarantees for Apache Kafka：三种投递语义的官方定义与配置。
• Cloudflare — Using Apache Kafka to process 1 trillion inter-service messages：trillion 级 message bus 的真实架构与踩坑。
• Uber — Disaster Recovery for Multi-Region Kafka at Uber：超大规模 Kafka 的多区域容灾实践。
• AWS — Using dead-letter queues in Amazon SQS：DLQ、redrive、FIFO 阻塞行为的官方文档。

深入思考