第 33 章 消息队列：可靠性三件套

本章解决"消息会不会丢、会不会重、会不会乱"三个问题，并给出积压、延迟消息与选型的判据。

学习目标

读完本章，你应当能够：

1. 说清 MQ 的四个核心价值与它引入的三类新问题，并判断哪些场景不该引入 MQ；
2. 沿"生产者 → Broker → 消费者"三段逐段列出丢失原因与对应防线，给出每段"最多能丢多少"的量化判断；
3. 用 LEO、HW、ISR、leader epoch 解释 Kafka 的持久化与副本机制，推导 HW 截断为什么造成数据不一致；
4. 论证"至少一次语义下重复不可避免"，在给定业务下选出幂等方案、设计幂等键与去重表治理策略；
5. 区分全局有序、分区有序、业务键有序三种层次，指出 Kafka 分区内有序被破坏的两个具体原因；
6. 用"生产速率 vs 消费速率 + Lag 曲线"定位积压性质并给出按代价排序的处理手段，同时画出时间轮结构、比较延迟消息的四种实现与事务消息的两阶段回查，最后按四个维度完成 MQ 选型。

前置知识检查

33.1 为什么引入 MQ：四个收益与三类代价

三类新代价必须一起答，只答收益是半个答案（三件套这一章存在的理由就是这三类代价）：

• 可用性下降：同步调用只有两个依赖方，引入 MQ 后有生产者、Broker、消费者三段加存储集群，链路可用性是各段之积，0.999 × 0.999 × 0.999 ≈ 0.997，比单跳低一个数量级；生产者若同步阻塞式发送，Broker 故障会直接挂住上游请求。
• 一致性变复杂：同步调用里"下游成功"是调用栈里的返回值；异步化后它变成未来才发生的状态，于是必须处理丢失、重复、乱序三种偏差 —— 这就是"三件套"的来源。
• 系统复杂度上升：多了一个必须监控、扩容、演练的中间件；链路从一次 RPC 变成长达数秒的异步流程，排障要跨三个系统看 TraceID（见第 35 章 35.6 节）。
• 不该用 MQ 的四类场景：要求强一致且下游必须立刻返回结果（如扣款与入账要同一个事务结论）；调用链只此一次、无扇出、下游稳定，没有解耦收益却白增一跳网络与新故障点；需要同步的查询结果（查询是"读"，MQ 是"写后通知"，语义不匹配）；消息量极小且偶发，运维一个集群的成本远超收益。

33.2 消息丢失的三个环节与各自的防线（第一大必考：必须逐段拆开，因为三段防线不同、责任方也不同）

1
2
3
4

  生产者 Producer              Broker（存储）            消费者 Consumer
  send(msg) ──①网络+确认──►  页缓存 → 磁盘   ──③拉取+位点──►  处理业务 → 提交位点
         ◄──── ack/回调 ────  副本复制(ISR)
   丢这↑"发出去了没人收到"   丢这↑"收到了没落稳/没复制"   丢这↑"处理完了位点丢了/跳了"

33.2.1 环节① 生产者 → Broker

根因是发送方使用"发后即忘"语义：send() 立刻返回，内核缓冲区里的数据在连接断开或 Broker 未持久化时直接消失。

生产者还必须在回调失败时重试、重试仍失败时落库补偿 —— 只配 acks=all 而不处理回调失败，等于把丢消息的责任推给 Broker，这是最常见的错答。

33.2.2 环节② Broker 内部

Broker 收到后有两道关卡：刷盘与副本。异步刷盘让消息先进页缓存（page cache）就返回 ack，吞吐是同步刷盘的数倍到十倍，但机器掉电（断电、内核 panic）会丢掉未刷盘的数据；进程崩溃不丢 —— 数据已在内核页缓存里，进程死而内核存活，这是常被答错的一点。同步刷盘等落盘才 ack，每次写加一次磁盘写延迟（SSD 约 100 μs ~ 1 ms，机械盘约 5~10 ms），吞吐掉一个数量级。Kafka 不做同步刷盘，把可靠性交给副本；RocketMQ 提供 SYNC_FLUSH/ASYNC_FLUSH。副本参数是一组，必须同时说：replication.factor（副本因子）决定存几份，配 3 表示能容忍 2 台同时挂而不丢数据；min.insync.replicas（最小同步副本数）要求 acks=all 时至少这么多个副本确认写入才算成功，默认 1，必须改成 2 或更多，否则 acks=all 退化成"只要 leader 自己写成功"；unclean.leader.election.enable 默认 false，设为 true 后 ISR 全挂时允许落后很多的副本直接当 leader，用可用性换数据丢失，因为它缺失的那段日志会被永久截断。

量化判断（副本因子 3、min.insync.replicas=2）：

33.2.3 环节③ Broker → 消费者

“先处理业务再提交位点"的顺序为什么不能反 —— 只要提交与处理之间有间隙，故障就必然落在间隙里：

1
2
3
4
5

顺序A（正确）：拉取 → 处理业务 → 提交位点
   崩溃于"处理完、未提交" → 重启后重复消费该批 → 偏差 = 重复（至少一次）
顺序B（错误）：拉取 → 提交位点 → 处理业务
   崩溃于"提交后、处理前" → 重启后从位点之后开始 → 这条消息永远不被处理
   偏差 = 丢失（至多一次）

只要提交与处理之间有间隙，故障就必然落在间隙里 —— 选择"先处理后提交"就是把偏差定向到重复（可被幂等消除，见 33.4 节），而不是丢失（无法事后恢复），可靠性工程的通用手法即"把误差往可修的那一侧推”。消费失败的重试与死信：消费抛异常时不提交位点、按退避策略重试，超过阈值的消息投入死信队列（dead letter queue, DLQ）并告警；注意死信不等于丢弃（要有补偿入口），且重试必须限次且退避，否则一条毒消息（poison message）会永久阻塞该分区 —— RocketMQ 用 %RETRY% 主题与延迟等级实现重试，失败 16 次后进 %DLQ%。

33.3 Kafka 的持久化与副本机制

33.3.1 分区、副本与 ISR

1

  分区 = 并行消费上限与有序单位；副本只提供冗余（rf=3 时 P0/P1/P2 的 leader 分别为 B1/B2/B3）

分区（partition）是 Kafka 的并行单位与有序单位：同一分区内消息有确定顺序，跨分区没有。副本只复制 leader 的日志，不承担生产与消费流量（Kafka 2.4+ 起支持有限度的 follower 读用于就近消费）。

**ISR（in-sync replica，同步副本集合）**是"与 leader 保持同步的副本集合"，含 leader 自己，判定标准由 replica.lag.time.max.ms（默认 30 s）决定：follower 只要在该时间内追平过 leader 的 LEO 就留在 ISR 里 —— 这是"时间"标准而非"条数"标准，短暂抖动不会立刻把副本踢出，持续追不上才会。收缩时若 ISR 大小 < min.insync.replicas，acks=all 的写入被拒（NotEnoughReplicasException），代价是可用性下降而数据不丢；扩张时 follower 追平到 LEO 后重新加入，加入前它落后于 HW 的部分必须先截断再重新拉取。

33.3.2 LEO 与 HW：为什么消费者只能读到 HW 之前的消息

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

   分区日志（同一份数据在 leader 与两个 follower 上的进度）
   偏移量:  0    1    2    3    4    5    6    7
            ┌────┬────┬────┬────┬────┬────┬────┬────┐
   leader   │ m0 │ m1 │ m2 │ m3 │ m4 │ m5 │ m6 │    │  LEO = 7
            └────┴────┴────┴────┴────┴────┴────┴────┘
                                ▲
                                └── HW = 5 ← 消费者可见边界（只能读 [0,5)）
   follower1│ m0 │ m1 │ m2 │ m3 │ m4 │ m5 │    │    │  LEO = 6
   follower2│ m0 │ m1 │ m2 │ m3 │ m4 │    │    │    │  LEO = 5 ← 决定 HW 的那个
   规则：HW = min(所有 ISR 副本的 LEO) = "所有副本都已持久化的最大偏移量"

• LEO（log end offset）：某副本下一条要写入的消息的偏移量，即该副本日志的末尾；**HW（high watermark，高水位）**是 min(ISR 中所有副本的 LEO)，代表"即使 leader 立刻挂掉、换成任意 ISR 副本，这段数据也一定存在"。
• 消费者只能读到 HW 之前：若允许读 HW 之后，消费者可能读到只有 leader 有的 m6，而此时 leader 崩溃、follower2 当选（其 LEO=5），m6 会被截断消失 —— 消费者"看到"过一条历史里不存在的消息。把可见性边界压到 HW，等于把"读到的数据一定会被保留"变成硬保证。

33.3.3 HW 截断的不一致与 leader epoch 的解法

Kafka 官方文档明确承认 HW 机制的缺陷：HW 的传播是异步的，副本恢复时可能发生"日志被错误截断"。

1
2
3
4
5
6

 ① 初始：leader A、follower B 均为 [m0..m5]，HW = 5，两端一致
 ② B 因网络抖动离开 ISR，A 继续写入 m6；此时 A 的 LEO = 7，HW 仍 = 5
 ③ A 崩溃，B 当选新 leader（ISR 只剩它），而 B 不知道 m6 存在
 ④ A 重启作为 follower 向 B 拉取，B 报自己的 LEO = 6 → A 只能把 m6 截断（丢失）
 ⑤ 危险场景：A 的 HW 曾被推到 6（某中间副本短暂进过 ISR），而 B 上其实没有 m5；B 当选后
    A 按 B 的 LEO 截断，把 B 缺失的 m5 一并删掉 → 两个副本各有一半、最终都缺（静默损坏）

leader epoch（leader 纪元）的解法：给每次 leader 换届分配单调递增编号，并在日志里记录"每个 epoch 的起始偏移量"（epoch cache）。副本恢复时不再用"当前 LEO"这种易失的瞬时值判断截断点，而是先比较 epoch：follower 把"自己的最新 epoch + 该 epoch 的起始偏移量"发给 leader；leader 若发现对方 epoch 更旧，就告知该 epoch 的结束偏移量；follower 截断到那个位置后重新拉取。截断点由日志自身的元数据决定，而不是由对端当前写到哪里决定，避免了"用一个已变化的量去判断历史的终点" —— 这与 Raft 用 (term, index) 判定日志新旧同源（见第 34 章 34.3 节）。

33.3.4 acks 三种取值的可靠性对比

记忆锚点：acks 决定"等谁"，min.insync.replicas 决定"至少等几个"，unclean.leader.election 决定"不够时要不要用脏副本顶上"—— 三者是一组。

33.4 消息重复的根因与幂等实现

33.4.1 重复为什么不可避免

MQ 只提供三种投递语义：至多一次（可能丢、不重复）、至少一次（不丢、可能重复）、精确一次（不丢不重）。前两者是"二选一"，因为网络超时无法区分"消息没到"和"对方的确认丢了" —— 这是分布式系统的固有性质，不是实现缺陷。至少一次下重复有两条独立来源：① 生产者重试 —— Broker 写入成功但 ack 在网络上丢失，生产者超时重试，同一条消息在日志里出现两次；② 消费者提交失败 —— 业务处理完成、提交位点时崩溃或超时，重启后从旧位点重新消费。“重复不可避免，幂等必须做”：只要没有跨生产者与消费者的分布式事务（事务消息也只是把窗口缩小，见 33.8 节），就永远存在"业务已执行但位点未推进"的窗口。既然重复无法在设计上消除，就只能消除它带来的业务影响 —— 这就是幂等（idempotence）的定位：它不是优化，而是使用 MQ 的前置条件。

33.4.2 四种幂等实现方案对比

状态机的 SQL 写法（用 WHERE 兜住状态跃迁，靠影响行数判定是否重复）：

1
2
3
4
5

-- 关键在 WHERE status = 'UNPAID'：重复执行时第二次影响 0 行，
-- 于是"是否首次处理"由数据库的行锁与条件判断一次性给出，没有查询-判断竞态
UPDATE orders SET status = 'PAID', paid_at = NOW(), pay_no = #{payNo}
 WHERE order_id = #{orderId} AND status = 'UNPAID';
-- 返回 1 表示首次处理成功；返回 0 表示已处理过或状态不合法，直接 ACK 掉该消息

去重表（INSERT 冲突与业务写在同一事务）：

1
2
3
4
5
6
7
8
9

-- 幂等键上的唯一索引是全部保证的来源：并发重复消息只有一条能插入成功，
-- 另一条在数据库层面被拒，不依赖应用层的"先查再插"（那有竞态窗口）
CREATE TABLE consumed_msg (
    idempotent_key VARCHAR(64)  NOT NULL COMMENT '幂等键：业务单据号，天然去重',
    topic          VARCHAR(64)  NOT NULL COMMENT '来源主题，便于容量治理与回溯',
    consumed_at    DATETIME(3)  NOT NULL COMMENT '用于按时间归档清理',
    PRIMARY KEY (idempotent_key),
    KEY idx_topic_time (topic, consumed_at) COMMENT '给归档删除用，避免全表扫'
) ENGINE = InnoDB;

33.4.3 幂等键怎么生成：为什么业务单据号优于 UUID

去重表的容量治理：① 按时间归档 —— 只保留"最大重试窗口"内的记录；若最长重试链路是 24 小时（含死信重投），保留 3~7 天即有充分冗余，用 DELETE ... WHERE consumed_at < NOW() - INTERVAL 7 DAY LIMIT 5000 分批删除，避免长事务（见第 22 章 22.7 节）；② 分区表 —— 按 consumed_at 范围分区，删除退化为 DROP PARTITION，瞬间完成且不产生 undo 膨胀；③ 换存储 —— 下沉到 Redis（带 TTL）或布隆过滤器（Bloom filter），但布隆过滤器有假阳性且不能删元素、只能重建，假阳性会被误判为重复 → 造成漏处理，故只适合"重复代价远低于漏处理代价"的场景。

33.5 顺序消息的三种保证层次

“分区有序就够了"的推理：绝大多数顺序需求是"同一个订单的状态变更不能乱”，不同订单之间互不相关；把粒度收窄到订单后，并行度从 1 恢复到分区数 —— 用"业务维度隔离"换回并行度。

33.5.1 Kafka 分区内有序被破坏的两个原因（必考）

原因一：生产者重试导致的乱序。

1
2
3
4
5
6

 max.in.flight.requests.per.connection = 5（默认，允许 5 个请求在途）
 ① m1 因超时被判失败进入重试队列；② m2 成功写入，日志中 m2 排在前面
 ③ 重试的 m1 随后到达并追加 → 最终顺序 m2, m1  ← 乱序
 解法：enable.idempotence=true 给每条消息附 (producerId, epoch, seq)，Broker 按 seq
       去重并拒绝乱序追加；此时 in.flight 最大可到 5 而仍保序。或把 in.flight 降到 1，
       代价是吞吐显著下降，通常不选

原因二：消费者多线程消费破坏处理顺序。

1
2
3
4
5
6
7
8

 拉取线程一次拉到 [m1..m10]（同一分区，有序），提交给线程池并发处理
 线程 A 取 m1（慢，下游 200 ms），线程 B 取 m2（快，20 ms）
 → 业务侧先看到 m2 的效果  ← 顺序被破坏，位点提交也变得无法界定
 解法：① 单线程消费该分区（并行度靠分区数提供）；
       ② 按业务键二次分发：拉取线程把消息按 order_id 哈希投到 N 个内存队列，
          每队列一线程串行消费 —— 顺序以业务键为界，不牺牲整体吞吐；
       ③ 消费时对业务键加分布式锁（见第 34 章 34.5 节），但锁只保证互斥、
          不保证先后，仍需配合版本号或序列号判定新旧

RocketMQ 的做法：生产者用 MessageQueueSelector 显式选队列（业务键取模选 MessageQueue），替代 Kafka 的隐式哈希；消费者用 MessageListenerOrderly，其内部对每个 MessageQueue 加本地锁，确保一个队列同一时刻只被一个线程消费，并向 Broker 申请队列的分布式锁，避免 rebalance 后两个实例同时消费同一队列。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// 用业务键显式选队列：让"同一订单"必然落到同一队列，顺序保证的边界由此确定
producer.send(msg, new MessageQueueSelector() {
    @Override
    public MessageQueue select(List<MessageQueue> queues, Message msg, Object arg) {
        String orderId = (String) arg;
        // 取模而不是随机：随机会让同一订单散落到不同队列，顺序保证直接失效
        int index = Math.abs(orderId.hashCode()) % queues.size();
        return queues.get(index);
    }
}, orderId);

33.6 消息积压的排查与处理（第三大必考：第一步不是扩容而是定性）

积压是"生产者发得太快"还是"消费者消费得太慢"？两者方向相反。

处理手段按代价从低到高排序：① 增加消费者实例（前提是实例数 < 分区数）—— 上限就是分区数：第 p+1 个消费者会完全空闲（Kafka 的分配粒度是分区），还要触发 rebalance 让全体停顿，“加机器就能解决积压"只在当前实例数少于分区数时成立；② 提高单条消费速度 —— 批量消费（max.poll.records 调大、批量写库）、把同步调用改异步/并行、去掉无谓的重试退避、优化下游慢 SQL 或慢接口，这是收益最高且无副作用的一档；③ 增加分区数 —— 三个硬约束：Kafka 分区数只能增不能减；增加分区会改变 key % 分区数 的映射，导致同一业务键的新老消息落到不同分区，破坏业务键有序；分区越多，故障时的 leader 选举与 rebalance 越慢、文件句柄与内存开销越大；迁移比例：分区数从 N 增到 N+1 时旧键 k 的落点由 k mod N 变为 k mod (N+1)，会发生迁移的键占比约 N/(N+1)（只有满足 k mod N == k mod (N+1) 的键不动），N=10 时约 10/11 ≈ 90.9%，一次翻倍（N → 2N）约 1/2 的键迁移 —— 所以扩容必须选在低峰、且最好一次性翻倍；④ 临时扩容后紧急消费（“转存”） —— 积压量超过业务容忍窗口时：临时写一个只转发不处理的消费者（转到分区数大得多的临时主题），再用大量消费者并行处理，同时另起一路按正常速率消费原主题，双写去重由幂等层保证；但转存会重新分配分区、丢失顺序，只适用于无序消息；⑤ 丢弃或降级 —— 对可丢消息（埋点、非关键通知）用 seekToEnd() 跳过积压区间并记录丢弃量，把资源让给关键消息。

消费慢的三大根因：① 单条处理有重 I/O —— 逐条查库、逐条调远程接口；一次 RPC 同机房 RTT 约 0.1_{0.5 ms，算上服务端处理往往 10}100 ms，逐条处理 1000 条就是数十秒；② 同步调用串行 —— 消费逻辑里 .get() 阻塞等待，吞吐 = 1/单次耗时，解法是批量化或异步编排（见第 31 章 31.6 节）；③ 锁竞争 —— 为保序加了粗粒度锁、去重表唯一索引上热点键冲突频繁、或与在线业务争同一行的记录锁，解法是缩小锁粒度到业务键（见 33.5.1 的二次分发）、把去重放到内存 + 异步落库。

33.7 延迟消息与定时消息

延迟消息的共同结构是”消息在未来的某个时刻才可被消费"（下单 30 分钟未支付关单、支付成功后 15 秒推送、失败后按 1s/5s/30s 退避重试）。

33.7.1 时间轮的结构与多层设计

单层时间轮的问题是：要支持 24 小时、精度 1 秒，需要 24 × 3600 = 86400 个槽位，内存与空推进成本都不可接受。多层时间轮的解法是把"精度"与"跨度"分离 —— 低层管精度、高层管跨度，只在低层空转。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 多层时间轮（tickMs = 1 s，wheelSize = 60，层数 = 3）→ 总跨度 60³ = 216000 s = 60 h
  第三层（跨度 1 h）  ┌──┬──┬──┬ ... ──┬──┐  指针每 3600 s 走一格
 第二层（跨度 60 s） ┌──┬──┬──┬ ... ──┬──┐   指针每 60 s 走一格
 第一层（跨度 60 s，tickMs = 1 s）┌──┬──┬──┬ ... ──┬──┐ 指针每 1 s 走一格
                                  ▲ 当前槽位：放入"1 s 内到期"的任务
 加入"90 s 后到期"：90 s > 第一层跨度 60 s → 上升；90 s ≤ 第二层跨度 60×60 s
   → 放入第二层第 (90/60)=1 格（配合当前指针的剩余量计算轮数）
 到期路径：第二层指针走到该格 → 整格任务**降级重新插入第一层**（按剩余时间精确定位），
          第一层指针走到对应槽位 → 取出执行
 复杂度：O(1) 插入、O(1) 到期取出；代价是"降级"时的重新插入与每个任务的轮数（round）记账

Kafka 的 TimingWheel：位于 kafka.utils.timer 包，用于延迟生产（delayedProduce）、延迟拉取、延迟删除等内部定时任务。实现特征是单层 + 按需扩容 —— tickMs 与 wheelSize 由 SystemTimer 给定（如 tickMs=1 ms、wheelSize=20，即每格 1 ms、一轮 20 ms），当任务超时时间超过一轮时不加层，而是把任务放到溢出轮（overflow wheel）里，用更大的 tickMs 重新组织；每个 TimerTaskList（槽位）是双向链表并挂在一个 DelayQueue 上，只有到期槽位才被取出执行，避免每秒扫描所有任务。

精确延时的通用工程方案（追问"如果是 47 分钟后提醒呢"）：① Redis ZSet + 轮询 —— ZADD delay_queue <到期时间戳> <消息ID>，另起线程每秒 ZRANGEBYSCORE delay_queue 0 now LIMIT 0 100 取到期任务并 ZREM 删除；持久、精度秒级，多实例靠 ZREM 返回值做"抢到才执行"的竞争控制，缺点是轮询决定秒级精度上限；② 定时扫描数据库 —— 索引建在 (status, execute_at)，用 SELECT ... WHERE status='PENDING' AND execute_at <= NOW() LIMIT 200 FOR UPDATE SKIP LOCKED 让多实例并行取任务（SKIP LOCKED 避免实例间互等），适合分钟级；③ 组合方案 —— ZSet 做短期秒级精确触发，数据库或 MQ 定时消息做长期持久化，重启后由数据库重建 ZSet。

33.8 事务消息

“下单成功后发一条扣库存消息” —— 若先执行本地事务再发消息，发消息失败就破坏了业务；若先发消息再执行本地事务，本地事务回滚就产生了一条不该存在的消息（下游会扣掉不存在的库存）。这与 binlog 与 redo log 必须一致是同一类问题（见第 21 章 21.5 节），只是两个资源从"日志与数据页"变成了"数据库与 MQ”。

33.8.1 RocketMQ 两阶段流程与回查

1
2
3
4
5
6
7
8
9

 生产者                     Broker                     本地数据库
   │ ① 发送半消息(half msg)   │                            │
   │ ────────────────────────►│ 存入 RMQ_SYS_TRANS_HALF_TOPIC
   │ ◄────────────────────────│ 返回成功（消息对消费者不可见）
   │ ② 执行本地事务 ──────────────────────────────────────►│
   │ ◄──────────────────────────────────────────────────────│
   │ ③ commit → 消息转入真实主题（可见）；rollback → 删半消息 │
   │     ④ Broker 迟迟没收到 ③（生产者崩溃/网络断）→ 回查     │
   │ ⑤ 生产者查本地事务表/业务表判定 final 状态 → 再次 commit/rollback

为什么必须有回查：第 ③ 步的提交指令本身是一个网络请求，它可能丢失，此时生产者不知道 Broker 收没收到、Broker 不知道本地事务的结论 —— 若 Broker 保守地直接回滚，本地事务已提交但消息被删，下游永远收不到；若保守地直接投递，本地事务可能回滚了消息却发了。回查把"猜"变成了"问"：Broker 反查生产者"这笔本地事务到底成没成"，生产者查本地事务表或业务表的状态字段给出确定答案。这就是 2PC 里协调者宕机后需要"反查参与者"的同构问题，本质是"决议的持久化不能只存在于内存或单次网络消息里"。代价与边界：回查需要生产者实现 TransactionCheckListener，回查次数有限（超限默认回滚）；半消息期间消息不可见，消费延迟等于本地事务耗时，因此事务消息不能承载"必须立刻被消费"的消息。

33.8.3 三种"跨系统写"的方案对比

Kafka 事务的适用边界必须说清：transactional.id 用于跨会话标识同一生产者（结合 epoch 实现"僵尸生产者隔离" —— 旧会话的写入会被 Broker 拒绝），isolation.level=read_committed 让消费者忽略未提交或被中止事务的消息。但它不覆盖对外部数据库的写入，所以"消费-写库"这条链路仍要靠 33.4 节的幂等实现端到端正确。

33.9 主流 MQ 选型对比

按四个维度给结论：吞吐优先（日志采集、埋点、流处理、数据管道）选 Kafka —— 它把"磁盘顺序写 + sendfile 零拷贝 + 批量压缩 + 分区并行"做到极致，且堆积能力是设计前提；延迟优先（在线业务异步解耦、需秒级以内端到端响应）选 RocketMQ 或 RabbitMQ —— RabbitMQ 低堆积时延迟最低但堆积一多就崩，RocketMQ 在"高吞吐 + 低延迟 + 原生延迟/事务消息"之间最均衡；功能丰富度（事务消息、延迟消息、消息轨迹、死信与重试策略、广播/集群消费）选 RocketMQ，若还需要多租户、跨地域复制、队列与流两种模型、存算分离弹性则选 Pulsar；运维成本优先（小团队、无需深度定制）选 RabbitMQ（上手最快，但必须接受堆积性能差的硬约束），若团队已有 Kafka 经验，继续用 Kafka 的大规模运维成本反而低于引入一套新中间件。

本章小结

自测题

Q1（推导）Kafka 集群 replication.factor=3、min.insync.replicas=1、acks=all、unclean.leader.election.enable=true。请指出这套配置下"消息可能丢失"的所有路径，并给出最小改动方案。

Q2（推导）消费者采用"先提交位点、再处理业务"的顺序。请分析故障发生时的一致性后果，并说明为什么工程上普遍选择相反的次序。

Q3（设计）订单支付成功后发消息通知积分服务。请设计幂等方案，说明幂等键怎么生成、去重表怎么治理，并解释为什么不让 Redis SETNX 单独承担。

Q4（计算/设计）某主题有 8 个分区、8 个消费者实例，Lag 持续线性增长，生产速率 8 万条/秒、消费速率 5 万条/秒，已积压 4000 万条。你按什么顺序处理？请给出数量级推算。

Q5（辨析）判断下列说法：① “Kafka 支持精确一次语义，所以消费端不用做幂等”；② “时间轮就是用定时任务每秒扫一次所有延迟消息”；③ “RabbitMQ 的 TTL 加死信队列能实现任意精度的延迟消息，效果和 RocketMQ 的 18 级延时一样”。

面试高频问题与陷阱

延伸阅读

• Apache Kafka 官方文档：Replication、Design — Message Delivery Semantics、Exactly-Once Semantics 章节，以及 KIP-101（用 leader epoch 替代 HW 做日志截断）与 KIP-98（事务与幂等生产者）；
• Apache RocketMQ 官方文档：Transaction Message、Scheduled Message（18 级延时等级）、Message Queue Selector 与顺序消费章节；RabbitMQ 官方文档：Time-To-Live and Expiration、Dead Letter Exchanges；
• Kafka 源码：core/src/main/scala/kafka/log/Log.scala（HW/LEO 推进与截断）、clients/.../producer/internals/Sender.java（在途请求与 enable.idempotence）、server-common/.../timer/TimingWheel.java（时间轮实现）；
• 另见第 26 章 26.2 节（主从复制的丢数据窗口）、第 21 章 21.5 节（两阶段提交的崩溃点分析）、第 34 章 34.3 节（Raft 用 (term, index) 判定日志新旧的同源思想）、第 35 章 35.9 节（接口幂等的落地）。