2.1.6 MQ（消息队列）：容量、性能、积压与线上排障

本篇目标：面对“生产 12,000 条/秒、消费 8,000 条/秒”这类问题，不停留在“加消费者”，而是能算出积压、磁盘、网络、分区、恢复时间和下游承载边界；面对生产失败、消费者掉线、磁盘满、热点分区、再均衡抖动、重试风暴和代理节点故障，能拿证据、先止血、再根治并完成业务对账。

1. 容量模型：先定义流量、资源与恢复目标

1.1 从消息速率推导端到端容量

容量规划不是单独计算 Broker（代理节点）的吞吐，而是把生产速率 P、单条消息大小 S、复制因子 R、保留时长 T、消费速率 C、峰值持续时间 D 和目标恢复时间 Tr 放进同一个模型。核心公式是：积压变化率 = P - C；原始写入带宽约为 P × S；考虑复制后的集群内部写流量近似为 P × S × R；保留容量近似为 P × S × T × R ÷ 压缩比。实际预算还要加入索引、段文件、协议、重试和 30% 至 50% 的安全余量。

数据演绎 1： 生产 12,000 条/秒、消费 8,000 条/秒、持续 600 秒，则净增 4,000 条/秒，积压为 2,400,000 条。若单条 2 KiB（千字节），正文约 4.58 GiB（吉字节）；三副本且压缩比 2:1 时，磁盘新增约 6.87 GiB（吉字节），再按 40% 余量准备约 9.62 GiB（吉字节）。峰后生产降为 2,000 条/秒，消费仍为 8,000 条/秒，净消化 6,000 条/秒，理论 400 秒恢复；若要求 200 秒恢复，总消费能力至少要达到 2,000 + 2,400,000 ÷ 200 = 14,000 条/秒，并先确认数据库和外部接口能承受。

flowchart LR
  P[生产速率 P] --> Q[积压量]
  C[消费速率 C] --> Q
  S[消息大小 S] --> B[字节吞吐]
  R[副本因子 R] --> D[磁盘与复制网络]
  T[保留时长 T] --> D
  Q --> RT[恢复时间 = 积压 / 净消费能力]
  B --> D

图中箭头表示容量因果关系：速率差先形成积压，消息大小把条数换成字节，副本和保留再放大存储；恢复时间只有在消费能力大于当前生产能力时才有有限值。

热门面试题

1. 问题（容量公式）：如何从业务峰值估算 MQ（消息队列）容量？

   • 考点：条数、字节、副本、保留与恢复目标。
   • 回答思路：先算流入和流出，再算资源放大，最后用压测修正。
   • 详细答案：先按业务峰值和持续时间计算积压条数，再用平均和高分位消息大小换算字节；Broker（代理节点）侧要乘复制因子和保留时长，并加入索引、协议、重试、死信与安全余量。消费侧不能只看实例数，而要用单实例实测服务率乘可并行度，并把数据库连接、第三方配额和顺序键作为上限。最后用峰值消息分布做压测，验证最老消息年龄和恢复时间是否达到目标。
   • 进阶追问：为什么不能直接按平均消息大小计算？
   • 进阶回答：高分位大消息会让批次条数下降、网络包变大、垃圾回收和磁盘写延迟上升；平均值会掩盖尖峰，所以至少同时计算平均值和 P99（99 分位响应时间），并限制异常大消息。

2. 问题（恢复能力）：为什么“消费等于生产”仍然不安全？

   • 考点：安全余量和积压恢复。
   • 回答思路：说明没有净消费能力就无法消化历史积压。
   • 详细答案：消费能力刚好等于生产速率时，正常期只能维持当前水位，任何发布、抖动、再均衡或下游变慢都会形成积压，而系统没有剩余能力恢复。容量设计必须同时满足稳定流量和目标恢复时间，例如已有 240 万条积压、入口仍有 2,000 条/秒且要求 200 秒恢复，就需要至少 14,000 条/秒的有效消费能力，而不是 2,000 条/秒。
   • 进阶追问：安全余量固定设为 30% 可以吗？
   • 进阶回答：不能机械固定。流量波动、扩容耗时、外部配额和业务时效不同，应以历史峰值、故障持续时间、恢复目标和压力测试决定；资金与库存链路通常需要更严格余量。

3. 问题（项目落地）：WMS（仓储管理系统）活动前如何证明队列容量够用？

   • 考点：容量验收和业务不变量。
   • 回答思路：从流量回放、故障注入和业务对账三方面回答。
   • 详细答案：使用脱敏后的真实消息大小和键分布回放峰值，模拟一个消费者组掉线、一个 Broker（代理节点）故障和数据库耗时翻倍；记录入口、出口、积压斜率、最老消息年龄、磁盘预计写满时间和恢复时长。库存裁决仍由数据库条件更新保证，消息只传播结果。恢复后按事件号与库存流水对账，确认无静默丢失、重复被幂等吸收且库存不变量成立。
   • 进阶追问：压测只达到峰值一分钟够吗？
   • 进阶回答：不够。必须覆盖计划中的峰值持续时间和峰后恢复阶段，否则看不到磁盘累积、长尾、缓存热度下降、再均衡以及恢复流量对下游的二次冲击。

1.2 磁盘、保留、副本与水位治理

磁盘事故通常不是“突然满”，而是写入速率、保留删除速度和副本追赶之间失衡。容量告警要从使用率升级为“预计写满时间”：剩余可用字节 ÷ 最近窗口净增长字节/秒。同时区分数据保留导致的正常增长、删除任务失效、热点分区集中、副本重建和死信异常增长。高水位用于停止非关键写入，低水位用于恢复，二者之间保留滞回区，避免反复启停。

数据演绎 2： 一个节点可用空间 1.2 TiB（太字节），当前已用 900 GiB（吉字节），净增长 18 MiB（兆字节）/秒，剩余约 329 GiB（吉字节），理论约 5.2 小时写满。若仅在 90% 使用率告警，处理窗口可能不足；应在预计写满 12 小时和 6 小时分别触发预警与事故。将非关键主题保留从 7 天临时降至 2 天，只能在业务确认可重建且审计要求允许时进行，支付和库存事实流不能为腾空间盲删。

stateDiagram-v2
  [*] --> 正常: 磁盘低于 70%
  正常 --> 预警: 预计 12 小时写满
  预警 --> 限流: 预计 6 小时写满
  限流 --> 保护: 使用率超过 90%
  保护 --> 恢复观察: 扩容或清理后低于 75%
  恢复观察 --> 正常: 增长率稳定 30 分钟
  恢复观察 --> 限流: 增长率反弹

图中使用“预计写满时间”触发动作，比单一百分比更早暴露高速增长；恢复必须经过低水位和观察窗口，不能空间刚释放就立刻放开全部流量。

热门面试题

1. 问题（磁盘告警）：磁盘使用率 85% 是否一定是事故？

   • 考点：容量水位与增长斜率。
   • 回答思路：结合增长率、保留删除和业务等级判断。
   • 详细答案：85% 只是静态快照。若净增长为零且删除稳定，可能仍有充足时间；若每秒增长 50 MiB（兆字节），几小时内就会写满。应看预计写满时间、各目录分布、最大分区、保留删除滞后和副本追赶。支付、库存主题要优先保护，非关键日志可限流或缩短保留，但必须遵守可重建和审计边界。
   • 进阶追问：能否直接删除最老的消息文件？
   • 进阶回答：不能绕过 Broker（代理节点）的保留管理手工删除活跃段，否则可能破坏索引、副本一致和消费位移。应先调整合法保留策略、迁移分区或扩容，并保留操作审计。

2. 问题（副本放大）：为什么 Broker（代理节点）恢复后磁盘和网络反而更忙？

   • 考点：副本追赶与前台流量竞争。
   • 回答思路：说明落后副本需要回放缺口。
   • 详细答案：故障节点恢复后，落后的副本要从 Leader（领导者）读取缺失日志并写盘，形成额外读、网络和写放大；若同时进行分区迁移，可能与生产和消费争抢资源。恢复策略应限制副本同步和迁移并发，优先关键主题，观察同步副本集合、复制延迟和前台 P99（99 分位响应时间）延迟，避免“恢复动作”制造第二次事故。
   • 进阶追问：副本越多是否越可靠？
   • 进阶回答：副本提高容错，但增加写放大、存储和恢复成本。还必须配合确认策略、最小同步副本数、跨故障域部署和演练，否则副本数量本身不等于可恢复性。

3. 问题（支付保留）：磁盘紧张时为什么支付消息不能优先删除？

   • 考点：审计、对账和恢复点目标。
   • 回答思路：从权威事实和重放窗口回答。
   • 详细答案：支付消息常参与状态收敛、账务对账和异常补偿，删除可能使尚未处理或需要重放的流水失去证据。应先保护数据库权威账务和 Outbox（发件箱），限制低价值通知、统计或可重建投影；若必须缩短支付流保留，要确认已归档、所有消费组位移安全、对账完成并经过审批，而不是临场拍脑袋。
   • 进阶追问：数据库已有支付流水，消息是否可随时删除？
   • 进阶回答：数据库能作为补数来源，但重建速度、字段完整性和顺序语义未必等价。需事先验证补数工具和恢复时间满足目标，不能在事故中首次尝试。

1.3 网络、批量、压缩与消息大小

吞吐不是只有条数。小消息逐条发送会让系统受请求次数、系统调用和协议头限制；批量能摊薄固定开销，压缩能减少网络和磁盘，但增加 Producer（生产者）与 Broker（代理节点）的 CPU（中央处理器）消耗和批次等待。大消息则会占用网络缓冲、拉长单次复制和消费时间，引发垃圾回收及头阻塞。调优要围绕端到端延迟、吞吐、CPU（中央处理器）和失败重发成本一起权衡。

数据演绎 3： 20,000 条/秒、每条 1 KiB（千字节）时，正文约 19.5 MiB（兆字节）/秒。若每批 1 条且每请求附加 200 B（字节），仅协议额外约 3.8 MiB（兆字节）/秒；每批 100 条时，请求头开销降到约 0.038 MiB（兆字节）/秒。压缩比 3:1 后正文网络约 6.5 MiB（兆字节）/秒，但批次等待若从 2 毫秒增到 20 毫秒，低流量场景的响应时间也会增加约 18 毫秒。

flowchart LR
  M[100 条消息] --> B[Producer（生产者）聚合批次]
  B --> Z[压缩]
  Z --> N[网络发送]
  N --> W[Broker（代理节点）追加与复制]
  W --> F[Consumer（消费者）批量拉取]
  F --> X[分批执行业务]

图中生产批次和消费批次不是同一个事务边界；某条业务失败时要能定位到消息标识，不能因为批量而整批无界重试。

热门面试题

1. 问题（批量）：批量越大吞吐越高吗？

   • 考点：固定开销、等待和失败窗口。
   • 回答思路：说明收益先增后受边界限制。
   • 详细答案：批量能摊薄网络请求、系统调用和刷写开销，但过大会增加组批等待、单批内存、一次失败的重发量与消费者处理时长，还可能超过请求或消息上限。应在真实消息大小下测试吞吐和 P99（99 分位响应时间）延迟，以业务最大等待时间和下游批处理能力选取区间，而不是只追求最大批次。
   • 进阶追问：支付事件适合大批量吗？
   • 进阶回答：通常更重视低延迟和可追踪性，可用小批量摊薄开销，但不能为了吞吐积攒过久；每笔仍需独立幂等键和状态结果。

2. 问题（大消息）：为什么不应把导出文件直接放进 MQ（消息队列）？

   • 考点：大消息对共享基础设施的影响。
   • 回答思路：改为对象存储加引用。
   • 详细答案：大文件会占用代理节点网络、磁盘页缓存和消费者内存，拉长复制与失败重传时间，容易阻塞同分区的小消息。更稳妥的设计是文件写入对象存储，消息只携带任务号、对象地址、校验值和版本；消费者下载后校验，文件生命周期由任务状态和清理作业管理。
   • 进阶追问：引用对象被提前删除怎么办？
   • 进阶回答：对象保留期必须覆盖消息保留、最大重试和人工恢复窗口；消费者发现不存在时进入可审计失败状态，由补偿任务重新生成或人工处理。

3. 问题（压缩）：开启压缩后网络下降但延迟升高，如何判断是否合理？

   • 考点：资源换延迟的量化权衡。
   • 回答思路：联合看组批等待、CPU（中央处理器）和端到端时效。
   • 详细答案：先分解生产组批、压缩、代理节点处理和消费解压耗时，确认延迟来自等待还是 CPU（中央处理器）饱和；再看带宽下降是否解除瓶颈。如果轨迹分析允许秒级延迟，压缩收益可能合算；支付状态通知要求百毫秒级，就要缩短等待或使用更快算法。最终以业务时效和故障重发成本验收。
   • 进阶追问：压缩比是否可以写死进容量公式？
   • 进阶回答：不可以。压缩比依赖字段重复度、批次和算法，应从生产样本按高低流量分别测量，并为不可压缩消息保留余量。

1.4 分区、队列、消费者并发与预取

有效并发受四个上限共同约束：分区或队列数、消费者实例与线程数、业务键顺序粒度、下游资源。Kafka（分布式日志消息系统）同一 Consumer Group（消费者组）中一个 Partition（分区）同一代只分配给一个成员；RocketMQ（分布式消息队列）的 MessageQueue（消息队列）和 RabbitMQ（消息队列）的队列/Consumer（消费者）模型也必须结合顺序、负载均衡和 Prefetch（预取）分析。预取过小导致网络往返多，过大则把消息囤在慢消费者内存并造成分配不公平。

数据演绎 4： 8 个 Partition（分区），单消费者稳定 1,000 条/秒，理论组吞吐上限约 8,000 条/秒；启动 12 个消费者仍有 4 个空闲。若某热点键占 35% 流量，即 4,200 条/秒，却落在单一 Partition（分区），该分区上限 1,000 条/秒，每秒积压 3,200 条，而其他分区可能空闲。盲目扩容消费者无效，需治理热点键、合并事件或在业务允许的顺序粒度上重新分片。

flowchart TB
  K1[普通键 65%] --> P1[Partition（分区）0..6]
  K2[热点键 35%] --> P2[Partition（分区）7]
  P1 --> C1[7 个 Consumer（消费者）]
  P2 --> C2[1 个 Consumer（消费者）]
  C2 --> L[单分区积压]
  X[额外 4 个 Consumer（消费者）] -.无可分配分区.-> P2

图中总消费者数量充足，但热点 Partition（分区）仍只有一个活动消费者，说明“总吞吐平均值”会掩盖局部饥饿。

热门面试题

1. 问题（并发上限）：为什么增加消费者后吞吐没有变化？

   • 考点：可并行度和瓶颈定位。
   • 回答思路：依次检查分区、热点、顺序和下游。
   • 详细答案：先确认是否还有可分配的 Partition（分区）或队列，再按分区看 Consumer（消费者） Lag（延迟）而不是只看总量；若是热点键或严格顺序，新增实例无法分担。即使分区足够，数据库连接、锁竞争、第三方配额和 CPU（中央处理器）也可能成为瓶颈。通过实例忙闲、分区速率和下游耗时确定限制后再扩容。
   • 进阶追问：直接增加分区有什么副作用？
   • 进阶回答：会增加文件、元数据、恢复和再均衡成本；哈希取模改变后，同一键的新旧消息可能跨分区，需以版本化路由或消费端序号防止状态倒退。

2. 问题（预取）：RabbitMQ（消息队列）的 Prefetch（预取）为什么会影响公平性？

   • 考点：未确认消息的客户端占用。
   • 回答思路：说明消息从队列转为消费者在途后不再可见给其他消费者。
   • 详细答案：Prefetch（预取）过大时，快拿到配额但处理变慢的消费者会持有大量未确认消息，其他空闲消费者拿不到这些任务，队列可见积压可能下降但端到端年龄仍升高。应根据单条处理时间、消费者内存和期望并行度设置，并监控未确认数、单消费者处理时长与重投递率。
   • 进阶追问：预取设为 1 一定最公平吗？
   • 进阶回答：更接近逐条分配，但网络往返和确认开销增加，吞吐可能下降。应在公平、吞吐和处理时长波动之间压测取值。

3. 问题（顺序扩容）：严格顺序消费如何扩容？

   • 考点：全局顺序与键内顺序的代价。
   • 回答思路：先缩小顺序范围，再按键分片。
   • 详细答案：全局顺序意味着单队列或单分区，天然限制并发。多数业务真正需要的是同一订单、库存单位或运单内顺序，可以按稳定业务键路由到多个分区，不同键并行；消费端用版本号拒绝倒退。若确实要求全局顺序，只能接受吞吐上限并通过单线程内部批量、优化下游和主备恢复提升，而不能虚构并行顺序。
   • 进阶追问：热点订单仍然很慢怎么办？
   • 进阶回答：同一实体不能随意拆序，可合并高频中间事件、只保留状态跃迁，或把耗时副作用异步到不影响状态机顺序的后续通道。

2. 积压与恢复

2.1 Consumer（消费者） Lag（延迟）、消息年龄与恢复时间

Consumer（消费者） Lag（延迟）是生产位移与已提交或已处理位移的差，但它只表示数量差，不能单独代表业务影响。排障要联合最老消息年龄、增长斜率、消费成功率、处理耗时和预计恢复时间。Kafka（分布式日志消息系统）按 Partition（分区）看位移差；RocketMQ（分布式消息队列）看 MessageQueue（消息队列）消费差、消费时间戳和重试；RabbitMQ（消息队列）同时看 Ready（待投递）与 Unacked（未确认），否则消息可能只是从代理节点搬到消费者内存。

数据演绎 5： 生产 12,000 条/秒、消费 8,000 条/秒，10 分钟积压 240 万条。此时限流将生产降到 5,000 条/秒，并扩容到 13,000 条/秒，净消化 8,000 条/秒，理论 300 秒恢复。若下游数据库只能稳定 10,000 次/秒，则 13,000 条/秒会制造超时，假设 20% 重试会额外产生 2,600 条/秒，实际有效恢复显著变差。正确方案是消费控制在数据库安全水位，并把批量写、合并和低优先级延后纳入恢复计划。

sequenceDiagram
  participant P as Producer（生产者）
  participant Q as MQ（消息队列）
  participant C as Consumer（消费者）
  participant D as 数据库
  P->>Q: 12,000 条/秒
  Q->>C: 8,000 条/秒
  Note over Q: 600 秒后积压 240 万条
  P->>Q: 限流到 5,000 条/秒
  C->>D: 受控提升到 10,000 条/秒
  Note over Q: 净消化 5,000 条/秒，约 480 秒恢复

图中选择 10,000 条/秒而不是盲目提升到 13,000 条/秒，是为了守住数据库安全水位；恢复慢一点也优于重试风暴导致二次崩溃。

热门面试题

1. 问题（指标口径）：Consumer（消费者） Lag（延迟）很高一定是消费者慢吗？

   • 考点：数量差与根因区分。
   • 回答思路：列出入口突增、提交异常、热点和下游慢。
   • 详细答案：不一定。可能是生产突增、单个热点分区、消费者实际完成但提交位移失败、再均衡暂停、毒消息阻塞或下游变慢。应按分区或队列比较生产速率、成功消费速率、处理耗时、提交位移、错误率和最老消息年龄，再结合实例日志与依赖指标建立时间线。
   • 进阶追问：位移提交正常就说明业务完成了吗？
   • 进阶回答：不一定，错误的先提交后处理会造成业务未完成却位移前进。必须核对提交顺序、业务流水和幂等记录，端到端成功以业务状态为准。

2. 问题（恢复估算）：积压恢复时间如何动态更新？

   • 考点：有效吞吐和滚动预测。
   • 回答思路：用成功消费减当前生产而不是配置能力。
   • 详细答案：每个滚动窗口取实际业务成功条数，扣除当前生产条数得到净消化速率，再用当前积压除以该速率；净速率小于等于零时直接判定不可恢复。还应按热点分区分别预测，加入重试、限流和扩容预热，并持续比较预测值与实际下降速度修正模型。
   • 进阶追问：为什么用业务成功而不是拉取条数？
   • 进阶回答：拉取后可能仍在处理、失败或重试，不能减少真实待完成工作；只有业务成功并进入可恢复确认边界才算有效消费。

3. 问题（止血）：积压时第一动作是扩容吗？

   • 考点：保护下游和证据优先。
   • 回答思路：先判断瓶颈和影响面，再选限流、隔离或扩容。
   • 详细答案：先确认生产是否仍在增长、消费者是否健康、下游是否已饱和以及关键业务时效。若外部依赖慢，扩容只会增加超时和重试，应先限流、暂停低优先级、隔离毒消息并保留证据；若分区和下游都有余量，再受控扩消费者。动作后观察净消化速度和错误率，不达预期立即回退。
   • 进阶追问：何时可以暂停生产？
   • 进阶回答：非关键投影和可重建事件可暂停；库存和资金事实不能静默丢弃，应继续写权威库和 Outbox（发件箱），或明确拒绝新业务并向用户返回可理解状态。

2.2 扩容、限流、降级与下游保护

恢复策略是一个受约束优化问题：在业务时效内尽快清空，同时不压垮数据库、缓存和第三方接口。可用手段包括入口限流、消费者扩容、批量写、同键合并、优先级隔离、暂停可重建投影和延迟非关键任务。每个动作都要定义启用阈值、最大强度、回退条件和业务补偿，不能把“提高线程数”当万能解。

数据演绎 6： 支付通知积压 900,000 条，渠道限额 3,000 次/秒，正常新增 1,000 条/秒，目标 10 分钟恢复需要净消化 1,500 条/秒，总调用 2,500 条/秒，低于配额，可以实现。若目标 5 分钟恢复，则总调用需 4,000 条/秒，超过配额；此时应接受 10 分钟目标、申请临时配额或合并非关键查询，不能靠 80 个消费者绕过限额。

flowchart TD
  A[积压增长] --> B{下游有余量?}
  B -->|有| C{分区或队列可并行?}
  C -->|有| D[受控扩消费者]
  C -->|无| E[合并热点或优化单通道]
  B -->|无| F[入口限流与优先级隔离]
  F --> G[暂停可重建任务]
  D --> H[观察净消化与错误率]
  E --> H
  G --> H
  H -->|反弹| F

图中扩容之前有两个前置判断：下游余量和可并行度。任何一个不成立，都要优先从限流、隔离或单通道优化入手。

热门面试题

1. 问题（下游保护）：为什么恢复积压时要主动降低消费速度？

   • 考点：有效吞吐与重试正反馈。
   • 回答思路：说明超过下游水位会降低成功率。
   • 详细答案：消费请求超过数据库或渠道容量后，排队、超时和锁竞争上升，失败消息进入重试，反而增加总流量并降低有效成功吞吐。把消费控制在安全水位，虽然配置吞吐较低，却能稳定减少积压。应以成功完成数、下游 P99（99 分位响应时间）延迟和错误率作为调速反馈，而不是以拉取数量为目标。
   • 进阶追问：如何确定安全水位？
   • 进阶回答：通过压测和历史运行曲线找出错误率、延迟开始陡升前的拐点，预留故障余量；生产恢复时再逐级放量并观察。

2. 问题（优先级）：同一个队列里如何优先处理支付事件？

   • 考点：资源隔离和公平性。
   • 回答思路：优先独立主题或队列，而不是客户端任意跳读。
   • 详细答案：资金状态和普通通知应在设计阶段拆成独立主题、队列、消费者组与资源配额，这样积压时可独立扩缩容和限流。若已混在一起，临时跳读可能破坏顺序和提交边界，应先通过业务类型过滤到隔离通道并建立补数账本，长期完成物理拆分。
   • 进阶追问：高优先级会不会饿死低优先级？
   • 进阶回答：会，所以要保留最低服务份额和最长等待告警；事故期可暂停可重建任务，但恢复后必须按账本补齐。

3. 问题（扩容回退）：消费者扩容后错误率上升怎么办？

   • 考点：变更可回退和反馈控制。
   • 回答思路：先回到最近稳定并发，再查下游和再均衡。
   • 详细答案：立即冻结继续扩容，按预设步长回退消费者或并发，把数据库连接、第三方配额和重试流量降回安全区；同时保留扩容前后时间线，检查是否连接池耗尽、锁等待、再均衡暂停或热点放大。恢复后通过小流量阶梯压测确定新上限，并把回退阈值自动化。
   • 进阶追问：回退会不会让积压继续增长？
   • 进阶回答：可能，但可预测的积压比下游崩溃更可控；同时入口限流和暂停低优先级，确保系统有净恢复路径。

3. 故障模式与证据链

3.1 生产失败、超时与重复发送

生产端“超时”是未知结果，不等于消息未写入。消息可能已持久化但确认响应丢失，Producer（生产者）重试就会重复；也可能根本未到 Broker（代理节点）。排障要关联业务事件号、客户端请求标识、目标 Topic（主题）/Queue（队列接口）、Partition（分区）、返回错误、代理节点日志和业务 Outbox（发件箱）状态。资金与库存链路优先保证权威事务与待发送事件不丢，再由发送器幂等重试。

数据演绎 7： 订单事件 evt-20260714-9001 在 10:00:00.120 发出，客户端 3 秒超时；代理节点日志显示 10:00:00.180 已落盘，确认包在网络抖动中丢失。客户端于 10:00:03.150 重试，消费者收到两次。消费表以 event_id 唯一约束，第一次写入 1 行，第二次影响 0 行并返回成功，最终业务只执行一次。若没有事件号和唯一约束，简单重试就可能重复扣减或重复通知。

sequenceDiagram
  participant O as Outbox（发件箱）发送器
  participant B as Broker（代理节点）
  participant C as Consumer（消费者）
  participant D as 业务数据库
  O->>B: evt-9001
  B->>B: 已持久化
  B--xO: 确认响应丢失
  O->>B: 超时后重试 evt-9001
  B-->>C: 两次投递
  C->>D: event_id 唯一插入
  D-->>C: 第一次成功，第二次冲突即幂等成功

图中重复来自确认窗口，不应靠“禁止重试”消除；正确做法是稳定事件号、生产重试和消费幂等共同形成可恢复链路。

热门面试题

1. 问题（超时语义）：生产消息超时后能否直接重发？

   • 考点：未知结果和重复窗口。
   • 回答思路：可以重发，但必须稳定标识并幂等。
   • 详细答案：超时可能是消息未写入，也可能已写入但确认丢失，所以为了避免静默丢失通常要重试；重试必须复用同一事件号，并由产品幂等能力和业务消费者唯一约束吸收重复。支付和库存还要从 Outbox（发件箱）按状态重发，不能重新执行原业务事务来“补消息”。
   • 进阶追问：查询代理节点确认存在后还需要消费幂等吗？
   • 进阶回答：仍需要。消费确认丢失、消费者宕机和再均衡都会导致再次投递，端到端副作用必须独立幂等。

2. 问题（生产失败排障）：生产成功率骤降时先看什么？

   • 考点：客户端、网络、代理节点和权限证据。
   • 回答思路：先界定影响面和错误分类。
   • 详细答案：按主题、机房、客户端版本和错误码拆分成功率，确认是超时、限额、权限、无 Leader（领导者）还是磁盘保护；对齐客户端延迟、网络丢包、代理节点磁盘与副本状态。止血时保护关键主题，关闭非关键重放，降低无界重试并启用 Outbox（发件箱）积压告警，恢复后按事件号补发和对账。
   • 进阶追问：为什么不能立即重启所有代理节点？
   • 进阶回答：会扩大选主、复制和连接重建，丢失现场证据。应先定位故障域，单点或分批处理并观察复制健康。

3. 问题（业务一致性）：消息发送成功但订单事务回滚怎么办？

   • 考点：双写不一致。
   • 回答思路：使用事务内 Outbox（发件箱）或等价事务消息边界。
   • 详细答案：不能在数据库事务提交前把可见业务事件直接发出，否则消费者会看到不存在的订单。常见做法是在同一数据库事务写订单和 Outbox（发件箱），提交后由发送器发布；或使用经过验证的事务消息方案并保留回查。消费者仍要验证状态机和幂等，不能把中间件事务扩张成跨系统强一致。
   • 进阶追问：Outbox（发件箱）发送器宕机怎么办？
   • 进阶回答：待发送记录仍在数据库，由多实例抢占或定时扫描恢复；需要租约、重试预算、死信与发送延迟监控。

3.2 消费者掉线、超时与 Rebalance（再均衡）抖动

消费者掉线既可能是真宕机，也可能是长时间垃圾回收、处理批次过大、网络隔离或事件循环被阻塞。协调端判定成员失效后触发 Rebalance（再均衡），分区转交给其他成员；如果业务已完成但 Offset（位移）未提交，会重复处理；如果先提交后处理，则可能丢业务。频繁扩缩容、滚动发布和慢成员会形成“加入、撤销、重新分配”的抖动，消费暂停又会放大 Consumer（消费者） Lag（延迟）。

数据演绎 8： 24 个 Partition（分区）、12 个消费者，每个处理 2 个分区，稳定能力 12,000 条/秒。4 个消费者因 90 秒的 Full GC（完全垃圾回收）失联，剩余 8 个需接管，重分配和缓存预热共停顿 40 秒；生产仍为 10,000 条/秒，先新增 400,000 条积压。恢复后有效消费 14,000 条/秒，净消化 4,000 条/秒，至少 100 秒清空；若消费者反复加入退出，恢复时间会不断重置。

sequenceDiagram
  participant C1 as Consumer（消费者）1
  participant G as Group Coordinator（消费组协调器）
  participant C2 as Consumer（消费者）2
  participant Q as Partition（分区）
  C1->>G: 心跳
  C1->>C1: 90 秒暂停
  G->>G: 会话超时，成员失效
  G->>C2: Rebalance（再均衡）并接管分区
  C2->>Q: 从已提交 Offset（位移）继续
  Note over C2,Q: 未提交但已完成的消息会再次处理

图中协调端只能依据心跳和已提交 Offset（位移）恢复，无法知道外部数据库副作用是否完成，因此消费幂等不能省略。

热门面试题

1. 问题（掉线定位）：消费者频繁掉线如何定位？

   • 考点：进程、运行时、网络和协调协议。
   • 回答思路：对齐失联时刻的心跳、暂停和处理耗时。
   • 详细答案：先按实例查看最后心跳、会话超时和退出原因，再对齐 JVM（Java 虚拟机）垃圾回收暂停、CPU（中央处理器）、线程栈、网络丢包和单批处理时长。如果实例活着但无法心跳，常见原因是处理线程阻塞、批次超时或事件循环被业务占用。止血时冻结发布与自动扩缩容，摘除异常实例，恢复后用故障注入验证不会再次失联。
   • 进阶追问：把会话超时调大能解决吗？
   • 进阶回答：只能降低短抖动误判，也会延长真实故障接管时间。根因仍需修复长暂停和阻塞，并按业务恢复目标选择参数。

2. 问题（重复窗口）：Rebalance（再均衡）为什么会造成重复消费？

   • 考点：业务完成与位移提交的非原子窗口。
   • 回答思路：用“处理成功后、提交前宕机”解释。
   • 详细答案：消费者完成数据库写入后尚未提交 Offset（位移）就被撤销分区，新成员只能从旧位移继续，消息被再次处理。正确取舍是先完成可幂等的业务副作用，再提交连续成功位移，让故障表现为可见重复而不是静默丢失；业务表以事件号或业务键加版本做唯一约束。
   • 进阶追问：在撤销回调里提交位移就绝对安全吗？
   • 进阶回答：仍可能超时或提交失败，也不能覆盖正在并发处理的空洞；需要停止拉取、等待有界任务、只提交连续成功位置，并让重复可吸收。

3. 问题（发布策略）：如何避免滚动发布引发再均衡风暴？

   • 考点：成员稳定性和变更节奏。
   • 回答思路：限制并行下线、等待分配稳定、配置可用机制。
   • 详细答案：按小批次下线消费者，每批等待分配与 Consumer（消费者） Lag（延迟）稳定后继续；避免自动扩缩容和发布同时改变成员数。Kafka（分布式日志消息系统）可结合版本支持的静态成员或协作式分配降低全量暂停；RabbitMQ（消息队列）则关注连接重建和未确认消息重投。无论产品，都要在变更前计算剩余容量是否能承受。
   • 进阶追问：发布期间积压增长是否立即回滚？
   • 进阶回答：看增长是否符合容量预算、预计恢复是否达标及错误率是否稳定；超过预设水位或出现业务失败就停止发布并回滚。

3.3 热点分区、Broker（代理节点）故障与副本恢复

热点分区表现为总集群资源仍有余量，但单个 Partition（分区）或 Queue（队列接口）的生产、消费、磁盘或网络达到上限。根因可能是大客户、单一库存单位、错误路由或分区 Leader（领导者）过度集中。Broker（代理节点）故障则需要区分控制面发现、Leader（领导者）切换、副本完整性、客户端元数据刷新和消费者恢复。恢复节点时还要防副本追赶抢占前台资源。

数据演绎 9： 32 个 Partition（分区）总生产 16,000 条/秒，平均 500 条/秒；其中 warehouse-01 占 6,000 条/秒并全部落在分区 7，单分区稳定上限 2,000 条/秒，所以每秒积压 4,000 条。10 分钟后该分区积压 240 万条，而总平均 Consumer（消费者） Lag（延迟）看起来只有每分区 75,000 条。需要按分区告警，并把可独立的库存单位再分片或合并同键变更，不能随机打散同一库存状态顺序。

flowchart LR
  K[热点业务键] --> P7[Partition（分区）7<br/>6,000 条/秒]
  P7 --> C7[单通道上限<br/>2,000 条/秒]
  P7 --> L[每秒积压 4,000 条]
  N[其他业务键] --> PX[其余 31 个 Partition（分区）]
  PX --> CX[集群资源仍有余量]

sequenceDiagram
  participant P as Producer（生产者）
  participant L1 as 旧 Leader（领导者）
  participant C as Controller（控制器）
  participant L2 as 新 Leader（领导者）
  P-xL1: 节点故障，写入失败
  C->>L2: 从合格副本选主
  P->>C: 刷新元数据
  P->>L2: 使用同一事件号重试
  Note over L2: 恢复后限制副本追赶对前台的冲击

第一张图解释热点的局部性，第二张图解释节点故障的恢复窗口；生产重试仍可能重复，不能把安全选主误解为端到端只处理一次。

热门面试题

1. 问题（热点判断）：如何区分集群容量不足和热点分区？

   • 考点：聚合指标与分布指标。
   • 回答思路：按分区比较流量、延迟、位移和键频率。
   • 详细答案：集群容量不足通常多数节点和分区同时接近资源上限；热点则是少数分区的生产、Consumer（消费者） Lag（延迟）、磁盘或网络显著偏高，其他分区空闲。应采样业务键频率，检查 Leader（领导者）分布和大消息，并按分区计算恢复时间。确认热点后先限制来源和合并事件，长期调整业务分片。
   • 进阶追问：增加分区能立即迁走已有积压吗？
   • 进阶回答：通常不能自动拆分既有分区日志；新分区影响未来路由，旧积压仍需原分区消费。迁移还要处理同键历史顺序和路由版本。

2. 问题（节点故障）：Broker（代理节点）宕机后的完整排障链路是什么？

   • 考点：发现、切换、客户端恢复和业务对账。
   • 回答思路：按时间线组织证据。
   • 详细答案：先确认故障节点、受影响主题和是否有不可用 Leader（领导者），检查同步副本和选主；限制非关键生产与重试，保护控制面和剩余节点。客户端刷新元数据后观察生产成功率、消费恢复和复制延迟；节点恢复时控制副本追赶。最后按事件号、位移和业务流水对账，验证超时重试的重复被幂等吸收。
   • 进阶追问：允许不干净选主能更快恢复吗？
   • 进阶回答：可能提高可用性但会选择落后副本，存在数据丢失风险。是否允许必须由 RPO（恢复点目标）决定，资金和库存通常不应为快速恢复牺牲已确认数据。

3. 问题（Leader 集中）：Leader（领导者）分布不均有什么影响？

   • 考点：数据面资源集中。
   • 回答思路：说明写、读和复制协调集中到少数节点。
   • 详细答案：生产和消费主要访问 Leader（领导者），分布不均会让少数节点网络、磁盘和请求线程过载，即使总容量充足也出现高延迟。应比较每节点 Leader（领导者）数与实际字节率，受控执行再平衡并避开高峰；长期在扩容、故障恢复和主题创建后自动检查分布偏斜。
   • 进阶追问：只按 Leader（领导者）数量均衡够吗？
   • 进阶回答：不够。不同分区流量和消息大小差异很大，要按字节、请求、磁盘和业务优先级加权。

3.4 重试风暴、毒消息与 Dead Letter Queue（队列接口）（死信队列）增长

重试的目的是真正可恢复的短暂故障，不是掩盖永久错误。立即无限重试会让一次依赖故障被放大为生产流量、消费流量、数据库连接和日志写入的多重压力。每条消息要有最大次数、指数退避、抖动、总时间预算和最终去向；参数错误、数据缺失或状态机非法的毒消息应快速隔离到 Dead Letter Queue（队列接口）（死信队列），并保留原事件、错误分类、版本和人工处置记录。

数据演绎 10： 正常 5,000 条/秒，外部接口失败率 40%，每条立即重试 5 次。粗略调用量为 5,000 × (1 + 0.4 + 0.4² + 0.4³ + 0.4⁴ + 0.4⁵) ≈ 8,300 次/秒；若故障是全失败，则放大到 30,000 次/秒。改成 10 秒、30 秒、120 秒三次退避，并在熔断期间暂停，可把瞬时冲击摊开；超过预算进入 Dead Letter Queue（队列接口）（死信队列），修复后按事件号受控重放。

stateDiagram-v2
  [*] --> 首次处理
  首次处理 --> 成功: 业务完成
  首次处理 --> 分类: 失败
  分类 --> 延迟重试: 可恢复且预算未耗尽
  延迟重试 --> 首次处理: 到期
  分类 --> 死信: 永久错误或预算耗尽
  死信 --> 修复审核
  修复审核 --> 受控重放: 已验证修复
  受控重放 --> 首次处理

图中的失败分类是关键决策点；没有分类的“统一重试”会把毒消息和依赖故障都变成风暴。

热门面试题

1. 问题（重试风暴）：如何判断积压由重试风暴引起？

   • 考点：原始流量与重试流量拆分。
   • 回答思路：比较事件号、尝试次数、错误类型和时间分布。
   • 详细答案：按原始事件和重试事件分别统计条数，查看同一事件的尝试次数、退避间隔与失败原因；若依赖错误上升后重试速率成倍增长、成功吞吐下降，就是正反馈。止血时暂停即时重试、熔断依赖、保护新消息和关键业务，随后按错误类型恢复，不让旧重试抢占全部容量。
   • 进阶追问：暂停重试会不会丢消息？
   • 进阶回答：不会等同于丢失，只要消息持久化、状态可查且有恢复账本。暂停是改变可见时间，之后按预算受控恢复。

2. 问题（死信增长）：Dead Letter Queue（队列接口）（死信队列）突然增长如何处理？

   • 考点：错误分类、影响面和可重放性。
   • 回答思路：先停止自动回灌，按版本和错误聚类。
   • 详细答案：先告警并冻结自动重放，按生产者版本、消息类型、错误码和业务键聚类，确认是否发布缺陷、字段变更或依赖故障；保存样本和原消息校验值。修复后先在隔离环境或小批量验证幂等与结果，再限速回灌，并监控失败是否回流。永久无效数据要有审计终态，不能循环进出死信。
   • 进阶追问：死信队列可以无限保留吗？
   • 进阶回答：不能。要按业务审计期设置保留，并将长期证据归档；同时建立未处置数量和年龄目标，避免把死信当垃圾场。

3. 问题（顺序重试）：顺序消息失败时跳过还是阻塞？

   • 考点：顺序正确性与可用性取舍。
   • 回答思路：按状态依赖判断是否允许越过。
   • 详细答案：若后续状态依赖前序，例如订单已支付后才能发货，不能无条件跳过；应短期有界重试，超过预算隔离该业务键而不是堵塞整个分区，并由状态机校验后续事件。若事件彼此独立，可记录失败后继续。选择必须写进业务契约，并通过序号和幂等保护。
   • 进阶追问：如何只隔离一个业务键？
   • 进阶回答：消费端维护键级暂停或把失败键转入专用补偿通道，主通道继续处理其他键；恢复时按版本顺序回放并验证状态不倒退。

3.5 外部依赖慢、Backpressure（背压）与级联故障

消费者吞吐往往由最慢外部依赖决定。连接池耗尽、第三方配额、数据库锁等待或缓存超时会让执行中任务增加，消息从“可见积压”转为线程和内存中的隐性积压。必须实施超时、并发隔离、限流、Circuit Breaker（熔断器）、有界队列和 Backpressure（背压）；对未知结果使用查询与对账，不能用立即重试制造更大压力。

数据演绎 11： 40 个消费线程，外部接口平均 100 毫秒时理论上限约 400 次/秒；接口变慢到 2 秒后，上限降为 20 次/秒。入口仍为 300 条/秒，每秒新增约 280 条，10 分钟积压 168,000 条。把线程扩到 400 只会把并发请求提高到 200 次/秒并占满连接，若对方配额 50 次/秒，超时更严重。正确止血是限到 40 次/秒、熔断非关键调用、入口降级，并与对方恢复后按可用配额计算回放速度。

flowchart LR
  Q[MQ（消息队列）] --> L[消费限流器]
  L --> B[Circuit Breaker（熔断器）]
  B -->|闭合| X[外部依赖]
  B -->|打开| R[延迟重试或降级]
  X -->|慢或失败| B
  L --> M[在途与积压指标]
  M -->|超过高水位| P[入口 Backpressure（背压）]

图中背压不是让 MQ（消息队列）凭空拒绝所有业务，而是把不可恢复状态传给入口，使新流量进入限流、排队页或明确降级。

热门面试题

1. 问题（隐性积压）：队列条数下降但业务仍然慢，可能是什么原因？

   • 考点：未确认和执行中任务。
   • 回答思路：检查消息是否被大量预取到消费者。
   • 详细答案：消息可能已从代理节点拉取，却囤在消费者内存、线程池或未确认集合中，队列可见条数下降并不代表完成。要联合看 Unacked（未确认）、在途任务、线程池队列、外部依赖耗时和业务完成时间；必要时降低 Prefetch（预取）和本地队列，把背压留在可观测、可持久化的消息系统中。
   • 进阶追问：本地线程池应该多大？
   • 进阶回答：由任务服务时间、依赖配额、内存和超时预算确定，并设有界队列；不能按 CPU（中央处理器）公式忽略网络依赖上限。

2. 问题（熔断恢复）：外部依赖恢复后为什么不能立即全量放开？

   • 考点：积压洪峰和半开探测。
   • 回答思路：阶梯放量并观察成功率。
   • 详细答案：故障期间已积累大量消息，全量放开会形成远超正常峰值的回放洪峰，使刚恢复的依赖再次过载。应先少量半开探测，确认延迟和错误率，再按配额阶梯提升；同时限制历史重试和新流量的份额，持续计算预计恢复时间，出现反弹立即降级。
   • 进阶追问：如何避免旧消息饿死新消息？
   • 进阶回答：按业务时效拆队列或设置配额，例如 70% 处理新消息、30% 恢复积压；资金状态则按状态机和截止时间设计优先级。

3. 问题（未知结果）：调用支付渠道超时后消费者应立即重试扣款吗？

   • 考点：外部副作用的未知状态。
   • 回答思路：先查单、复用幂等号，再决定补偿。
   • 详细答案：超时可能渠道已扣款但响应丢失，立即使用新请求号重试可能重复扣款。应持久化渠道请求号和处理中状态，优先查单或等待回调；确需重试时复用渠道支持的幂等号。最终通过渠道账单、内部流水和订单状态对账收敛，消息重试只负责驱动查询与状态机。
   • 进阶追问：渠道不支持幂等号怎么办？
   • 进阶回答：更要避免盲目重扣，使用查询、人工审核和账务冲正；接入层限制同一支付单并发，并保留完整请求证据。

4. 产品指标与事故闭环

4.1 Kafka（分布式日志消息系统）、RocketMQ（分布式消息队列）、RabbitMQ（消息队列）指标映射

三种产品指标名称不同，但都要回答五个问题：生产是否进入、代理节点是否安全持久化、消费者是否拿到、业务是否完成、失败是否可恢复。Kafka（分布式日志消息系统）重点看按分区 Consumer（消费者） Lag（延迟）、ISR（同步副本集合）、未充分复制分区、请求延迟和磁盘；RocketMQ（分布式消息队列）重点看生产/消费 TPS（每秒事务数）、消费差值、最老消费时间、Broker（代理节点）存储和重试；RabbitMQ（消息队列）重点看 Ready（待投递）、Unacked（未确认）、Publish（发布）/Deliver（投递）/Ack（确认）速率、连接/通道、内存/磁盘告警和 Quorum Queue（队列接口）（仲裁队列）副本健康。

数据演绎 12： RabbitMQ（消息队列）显示 Ready（待投递）从 200,000 降到 20,000，但 Unacked（未确认）从 5,000 升到 190,000，业务完成速率仍只有 1,000 条/秒，说明消息被高 Prefetch（预取）搬到消费者而非真正消化。Kafka（分布式日志消息系统）某组总延迟 100 万，其中一个分区 900,000，说明热点而非全组均匀慢。RocketMQ（分布式消息队列）消费差值不大但最老消息时间为 30 分钟，可能有少数毒消息或重试链路滞留。

flowchart TB
  S[业务事件号] --> P[生产指标]
  P --> B[Broker（代理节点）持久化与副本指标]
  B --> C[消费积压与确认指标]
  C --> D[业务数据库成功与幂等指标]
  D --> R[重试、死信与对账]
  R --> S

图中产品指标只覆盖中间链路，最终要回到业务事件号和权威状态形成闭环；任何单个 Ack（确认）都不能替代端到端验证。

热门面试题

1. 问题（Kafka 指标）：Kafka（分布式日志消息系统）积压排障最少看哪些指标？

   • 考点：分区、复制、消费组和业务完成。
   • 回答思路：按生产、代理节点、消费和业务四层回答。
   • 详细答案：看每分区入口条数与字节、Consumer（消费者） Lag（延迟）和最老消息年龄；代理节点看请求延迟、磁盘、ISR（同步副本集合）和未充分复制分区；消费组看成员、Rebalance（再均衡）、拉取与提交；业务看成功率、处理耗时、幂等命中和下游依赖。按时间线关联才能区分入口突增、复制异常、热点和业务慢。
   • 进阶追问：总 Consumer（消费者） Lag（延迟）下降就能解除事故吗？
   • 进阶回答：不能，还要确认关键分区、最老消息、业务成功和错误率恢复，并观察一段冷却窗口。

2. 问题（RocketMQ 指标）：RocketMQ（分布式消息队列）消费差值正常但用户仍说延迟，查什么？

   • 考点：消息系统完成和业务完成的差距。
   • 回答思路：检查最老消费时间、重试、业务线程池和下游。
   • 详细答案：消费位移差正常可能是消息已被拉取或返回成功，但业务异步线程仍积压，或失败进入重试/死信。应以消息键追踪生产时间、首次消费、重试次数和业务落库时间，检查消费线程池、重试队列、数据库与外部接口，不把代理节点位移等同于用户可见完成。
   • 进阶追问：消费返回成功但业务线程异步失败有什么风险？
   • 进阶回答：消息已确认，不会自动重投，形成静默丢业务。要么在业务完成后确认，要么把异步任务可靠落库并有独立补偿。

3. 问题（RabbitMQ 指标）：Ready（待投递）为零是否说明 RabbitMQ（消息队列）没有积压？

   • 考点：未确认和客户端囤积。
   • 回答思路：联合 Unacked（未确认）与业务完成速率。
   • 详细答案：Ready（待投递）为零只表示队列中暂无可投递消息，大量消息可能被 Prefetch（预取）到消费者成为 Unacked（未确认），或进入本地线程池。要看每连接/通道未确认数、处理时长、确认速率、重投递和业务成功。若慢实例囤积，应降低 Prefetch（预取）、限制本地队列并让任务重新公平分配。
   • 进阶追问：直接关闭慢消费者连接可以吗？
   • 进阶回答：可作为止血，但会导致未确认消息重投和重复副作用；必须先确认消费幂等，并控制重投洪峰。

4.2 标准事故流程、回归验证与复盘话术

成熟排障流程固定为：确认影响和业务等级，冻结高风险变更，建立统一时间线；采集生产、代理节点、消费、依赖和业务证据；选择可回退的止血动作；验证净消化与业务不变量；定位根因并长期修复；通过重放、对账和故障演练回归；最后复盘监控为何没有更早发现、容量为何没有余量、降级为何没有自动触发。事故话术必须说事实、数字和决策，不把“重启后好了”当根因。

数据演绎 13： 14:00 轨迹事件生产 12,000 条/秒，消费因数据库索引退化降到 8,000 条/秒；14:10 积压 240 万条，最老消息 200 秒。14:12 将非关键重算暂停，生产限到 6,000 条/秒；14:18 完成索引回退，消费恢复 14,000 条/秒，净消化 8,000 条/秒；约 300 秒后清空。15:00 按 2,400,000 个事件号与轨迹表核对，重复 1,842 条均被唯一约束吸收，缺失 0 条。

数据演绎 14： 10:30 支付通知 Dead Letter Queue（队列接口）（死信队列）每分钟新增 6,000 条，错误集中在客户端版本 v7.2 的字段映射。10:34 冻结发布并停止自动回灌，10:45 修复映射；抽取 500 条回放成功率 100%，随后按 1,000 条/秒、2,000 条/秒、3,000 条/秒阶梯恢复。以支付单号对账 180,000 条，状态差异 12 条进入人工查询，最终全部收敛。

flowchart TD
  A[告警与用户反馈] --> B[界定影响面和时间线]
  B --> C[冻结变更并保存证据]
  C --> D[限流、隔离、降级或受控扩容]
  D --> E{指标停止恶化?}
  E -->|否| C
  E -->|是| F[修复根因]
  F --> G[阶梯恢复与回归]
  G --> H[事件号、金额、库存或轨迹对账]
  H --> I[复盘与自动化改进]

sequenceDiagram
  participant M as 监控
  participant O as 值班工程师
  participant Q as MQ（消息队列）
  participant D as 下游数据库
  participant A as 审计与对账
  M->>O: 积压斜率和最老年龄告警
  O->>Q: 限制非关键消费与重试
  O->>D: 回退问题索引并确认水位
  Q-->>O: 净消费恢复为 8,000 条/秒
  O->>A: 按事件号核对 240 万条
  A-->>O: 缺失 0，重复均幂等吸收

第一张图是事故状态机，第二张图把“恢复”落到数字和业务对账；只有基础设施指标与业务不变量同时通过，事故才算关闭。

热门面试题

1. 问题（事故优先级）：MQ（消息队列）积压告警后第一分钟做什么？

   • 考点：影响面、变更冻结和证据保护。
   • 回答思路：先建立事实，不盲目重启。
   • 详细答案：确认是资金、库存、履约还是可重建报表，记录开始时间、积压斜率、最老消息和业务失败；冻结发布、扩缩容和自动回灌等高风险变化，指定统一指挥。并行采集生产、代理节点、消费者和依赖指标，再依据瓶颈选择限流、隔离或扩容。所有动作记录时间和预期，便于回退和复盘。
   • 进阶追问：用户已经投诉时还要先采证据吗？
   • 进阶回答：要快速采集最小证据并同时止血，不能因追求完整调查延误恢复；但无证据重启会丢失根因并可能扩大事故。

2. 问题（验收标准）：积压清零是否代表事故结束？

   • 考点：业务对账与冷却观察。
   • 回答思路：基础设施恢复后还要验证副作用。
   • 详细答案：不代表。消息可能被错误确认、进入死信或重复执行，队列清零仍可能有资金、库存和轨迹差异。应检查成功率、最老年龄、重试和死信，对事件总数、业务唯一键、金额或库存不变量做对账，并观察生产与消费在低水位稳定一个窗口。补偿完成且无反弹才关闭。
   • 进阶追问：对账发现少量差异怎么办？
   • 进阶回答：按事件号建立差异清单，区分延迟、重复、丢失和非法状态，使用查询、补发、冲正或人工审核收敛，不能用总数相等掩盖个体错误。

3. 问题（复盘话术）：如何讲一次 Consumer（消费者） Lag（延迟）事故？

   • 考点：结构化表达和工程改进。
   • 回答思路：按背景、影响、证据、决策、恢复、根因和预防讲。
   • 详细答案：先用数字说明生产 12,000、消费 8,000 条/秒及 10 分钟 240 万积压；指出根因是数据库索引退化，不是泛泛说消费者慢。说明为什么先暂停非关键任务并限流，再回退索引和受控提速；给出 300 秒恢复、事件号对账缺失 0 的结果。最后说明新增最老年龄、预计恢复时间告警和索引变更压测，让面试官看到闭环。
   • 进阶追问：复盘是否要追究个人责任？
   • 进阶回答：应区分操作责任与系统改进，重点回答为何单点错误能穿透审查、监控和降级防线，并落实可验证的责任人与期限。

综合题库使用说明

以下题目用于 3 至 5 分钟口述。回答时先给结论和数字，再说明证据、止血、根因、长期修复与回归验证；链接均回到本篇对应知识正文。

5. 容量性能与线上排障综合题库

1. 问题（容量估算）：生产 12,000 条/秒、消费 8,000 条/秒，如何计算积压并制定恢复方案？

   口述答案：我先把条数、字节和业务时效分开计算。生产比消费每秒多 4,000 条，持续 600 秒就形成 240 万条积压；若平均消息 2 KiB（千字节），正文约 4.58 GiB（吉字节），还要乘副本因子、除以实测压缩比，再加入索引、重试、死信和 40% 左右余量。峰后如果生产降到 2,000 条/秒、消费仍是 8,000 条/秒，净消化只有 6,000 条/秒，理论 400 秒恢复。若业务要求 200 秒内恢复，总有效消费至少 14,000 条/秒，但这只是数学值，必须确认分区数、热点键、数据库和外部接口是否支持。实际处置中我先看 Consumer（消费者） Lag（延迟）增长斜率、最老消息年龄、各分区速率和下游 P99（99 分位响应时间）延迟；下游无余量时先把入口限到可恢复区间，暂停可重建报表和低优先级通知，而不是盲目加消费者。扩容采用阶梯方式，每次观察成功吞吐而非拉取量，错误率上升就回退。恢复后按事件号对账，验证缺失为零、重复被唯一约束吸收，并把这次峰值持续时间、扩容预热和目标恢复时间写回容量模型。这样回答既说明队列能吸收短峰，也明确长期生产高于消费时队列不会自行恢复。为了避免模型只在纸面成立，我还会把峰前、峰中、峰后的实测速率记录成时间序列，确认消费提升后数据库连接和锁等待没有越过安全线；若实际下降斜率连续三个窗口偏离预测超过 20%，立即停止继续放量，重新检查热点、重试和消息大小。演练结论必须形成下一次活动的入口阈值、扩容提前量和回退开关。

   • 追问 1：生产保持 8,000 条/秒、消费也是 8,000 条/秒能恢复吗？ 回答：不能，净消化为零，历史积压永远不下降。
   • 追问 2：消费者翻倍能把时间减半吗？ 回答：只有分区可并行且下游有余量时才可能，否则会增加超时与重试。
   • 追问 3：清零后如何验收？ 回答：检查最老年龄、错误和死信，再按事件号及业务不变量对账并观察冷却窗口。
   • 详细知识

2. 问题（磁盘容量）：如何估算副本、保留和重试共同造成的磁盘需求？

   口述答案：我不会只用“条数乘消息大小”，而是建立写入和保留两个口径。假设稳定生产 10,000 条/秒，平均 1 KiB（千字节），原始写入约 9.77 MiB（兆字节）/秒；三副本意味着集群需承受约三倍持久化字节，保留 7 天时再乘 604,800 秒，并用真实批次测得的压缩比修正。除此之外要单独预算段索引、协议开销、临时文件、重试主题、Dead Letter Queue（队列接口）（死信队列）和副本重建空间，最后保留故障余量，不能把磁盘运行到接近 100%。监控上同时看使用率、净增长率和预计写满时间；例如剩余 329 GiB（吉字节）、净增长 18 MiB（兆字节）/秒，大约 5.2 小时写满，比“85% 使用率”更能指导值班。发现异常后按主题、分区和目录查增长来源，区分保留删除失败、热点分区、副本追赶还是死信风暴。止血优先限制非关键重放和可重建数据，支付、库存事实流只有在归档、消费位移与审计条件都确认后才能调整保留。长期通过容量趋势预测、分区重平衡、扩盘和保留变更审批治理，恢复后验证删除速度持续大于新增速度且副本健康。容量验收还要模拟一块盘离线和一个副本重新同步，因为正常运行的空间充足不代表故障恢复有工作区。我会记录每小时写入、清理、复制和死信四类字节，确认任一节点故障后其余节点仍低于保护水位；扩容完成后再回放保留窗口内数据，证明索引、位移和业务补数路径可用。

   • 追问 1：能直接删除最老段文件吗？ 回答：不能绕过代理节点管理手工删活跃文件，应调整合法保留、迁移或扩容。
   • 追问 2：副本越多越好吗？ 回答：不是，容错提高但写放大、存储和恢复成本也上升，需要按恢复目标取舍。
   • 追问 3：为什么要看预计写满时间？ 回答：它同时反映剩余空间与增长斜率，能比固定百分比更早告警。
   • 详细知识

3. 问题（网络调优）：批量和压缩如何提升吞吐，又会带来什么风险？

   口述答案：批量的本质是用等待和内存换取更少的请求次数、系统调用和协议头，压缩则用 CPU（中央处理器）换网络和磁盘。比如每秒 20,000 条、每条 1 KiB（千字节），正文约 19.5 MiB（兆字节）/秒；逐条发送若每次多 200 B（字节）协议开销，会额外增加约 3.8 MiB（兆字节）/秒，每批 100 条后这部分降到约 0.038 MiB（兆字节）/秒。若压缩比 3:1，正文网络约 6.5 MiB（兆字节）/秒，但压缩与解压会增加 CPU（中央处理器），组批等待从 2 毫秒增到 20 毫秒也会抬高低流量延迟。调优时我会把生产组批、压缩、代理节点追加复制、消费解压和业务处理分别计时，同时观察吞吐、P99（99 分位响应时间）延迟、CPU（中央处理器）、内存和失败重发字节。支付状态更看重低延迟，可采用小批次；轨迹分析允许秒级延迟，可换取更高压缩。大文件不直接塞进 MQ（消息队列），而是放对象存储，消息携带任务号、地址、校验值和版本。最终参数来自真实大小分布和故障压测，不把压缩比或最佳批次写死。我还会分别用低流量与峰值流量测试，因为低流量时批次难以填满，等待延迟会更明显；峰值时则可能由压缩线程或网络成为瓶颈。每次参数变更只调整一个变量，保存批次字节、请求次数、压缩耗时和端到端分位延迟，若失败重发字节或消费者内存明显上升，就回退到上一组稳定配置，并再次确认关键业务的最大等待时间仍然达标。

   • 追问 1：批量越大吞吐越高吗？ 回答：收益会受延迟、内存、请求上限和失败重发成本约束，不会无限增长。
   • 追问 2：大消息为什么危险？ 回答：会占用缓冲和带宽、拉长复制与重传，并阻塞同分区小消息。
   • 追问 3：对象存储引用失效怎么办？ 回答：对象保留覆盖消息与重试窗口，消费者校验失败进入可审计补偿。
   • 详细知识

4. 问题（消费者扩容）：增加消费者后吞吐不升，应该如何排查？

   口述答案：我先判断系统是否真的还有可并行工作。Kafka（分布式日志消息系统）同一 Consumer Group（消费者组）里，一个 Partition（分区）同一代只给一个成员；8 个分区启动 12 个消费者，至少 4 个空闲。RocketMQ（分布式消息队列）也要看 MessageQueue（消息队列）分配，RabbitMQ（消息队列）则要看队列、Prefetch（预取）和未确认消息。第二步按分区或队列看生产速率、Consumer（消费者） Lag（延迟）和键分布，避免总平均掩盖热点：如果一个业务键占 35% 流量并固定在单分区，单分区上限 1,000 条/秒而入口 4,200 条/秒，新增实例无法分担。第三步看消费者内部 CPU（中央处理器）、线程池、垃圾回收和批次处理，再看数据库连接、锁等待和第三方配额；下游已饱和时加并发只会制造超时与重试。止血依据根因选择：分区有余量才阶梯扩容；热点先限流、合并中间事件或按业务允许的顺序粒度重新分片；下游慢则限速和熔断。长期记录单分区基准、路由版本和下游安全水位。验证标准是有效业务成功吞吐上升、错误率不变、热点延迟下降，而不是实例数量增加。为避免扩容只改变表面数字，我会在变更前后固定观察窗口，对比每分区成功条数、实例忙闲、数据库耗时和积压预计恢复时间；若新增实例空闲，说明分区不足，若实例繁忙但成功率下降，说明下游饱和。最终把可扩展上限、热点键处理和路由变更步骤写成操作手册，并用一次节点下线验证剩余容量。

   • 追问 1：直接增加分区可以吗？ 回答：可以提升未来并行度，但会改变路由并增加元数据和恢复成本，还需处理历史顺序。
   • 追问 2：严格顺序如何扩容？ 回答：缩小到业务键内顺序并按稳定键分区；全局顺序只能接受单通道上限。
   • 追问 3：为何看业务成功吞吐？ 回答：拉取可能失败、囤积或重试，只有完成副作用才真正减少待办。
   • 详细知识

5. 问题（积压告警）：Consumer（消费者） Lag（延迟）增长时怎样判断根因和恢复时间？

   口述答案：Consumer（消费者） Lag（延迟）只表示生产位置与消费位置的数量差，不能直接等同于用户等待。我会先按 Partition（分区）或 Queue（队列接口）拆开，联合入口速率、业务成功速率、最老消息年龄、处理耗时、错误率和位移提交；Kafka（分布式日志消息系统）重点排查分区热点、再均衡和提交，RocketMQ（分布式消息队列）还要看最老消费时间与重试，RabbitMQ（消息队列）同时看 Ready（待投递）和 Unacked（未确认），避免消息只是被预取到消费者。恢复时间用当前积压除以“实际业务成功速率减当前生产速率”，净速率小于等于零时直接判定不可恢复。比如 240 万条积压，生产限到 5,000 条/秒，业务成功 10,000 条/秒，净消化 5,000 条/秒，理论 480 秒；还要为重试、热点和扩容预热留余量。证据显示下游慢时先保护下游和限制入口，显示分区与下游都有余量才扩消费者。恢复过程持续比较预测与实际斜率，偏差大就重新定位。清零后检查死信、业务完成和个体事件对账，不以总位移前进替代正确性验收。告警分级也要绑定业务时限：支付最老状态超过数十秒就可能升级，报表可容忍数分钟。每次恢复都记录理论时间和实际时间，差值拆成重试、热点、再均衡和依赖等待；只有预测模型能持续解释实测变化，下一次告警才具有可操作性。若无法计算有限恢复时间，就必须升级为容量事故而不是继续观察。

   • 追问 1：位移提交正常说明业务成功吗？ 回答：不一定，先提交后处理可能造成业务未完成却位移前进。
   • 追问 2：最老消息年龄为何重要？ 回答：它直接反映最差业务等待，能识别少量长期滞留任务。
   • 追问 3：净速率为负怎么办？ 回答：先限流或提升有效能力，否则积压会继续增长，没有有限恢复时间。
   • 详细知识

6. 问题（下游保护）：为什么积压恢复时不能把消费者并发直接拉满？

   口述答案：积压恢复追求的是稳定的有效成功吞吐，而不是最大的请求数。假设数据库安全水位 10,000 次/秒，消息入口仍有 5,000 条/秒，即使消费者配置能拉到 13,000 条/秒，超过数据库拐点后会出现锁等待、连接池耗尽和超时；若 20% 请求进入重试，又会增加约 2,600 条/秒流量，实际恢复反而变慢。我的做法是先根据压测和历史曲线找到错误率、P99（99 分位响应时间）延迟开始陡升前的安全水位，用消费限流守住它；同时限制入口、暂停可重建投影、合并同键低价值事件，让净消化保持为正。扩容按小步阶梯执行，每步观察数据库连接、锁等待、外部配额、业务成功和预计恢复时间，任何指标越界立即回退。对新消息和历史积压分配服务份额，避免旧消息吃满资源导致新业务全部过期。外部支付渠道最多 3,000 次/秒时，恢复方案必须在配额内计算，不能用更多线程绕过。长期把下游水位、限流值、回退条件和降级开关自动化，并定期用故障压测验证。这样恢复可能比理论最快值慢，但不会把局部积压升级成数据库或第三方全面故障。恢复过程中我会设置高水位、低水位和最小观察时长，防止一看到积压下降就恢复全部入口。每个降级动作登记被延后或拒绝的业务量，事后按账本补齐；如果低优先级任务不可重建，就不能把暂停伪装成降级。这样既保护下游，也能向业务方准确说明影响数量、预计完成时间和恢复顺序。

   • 追问 1：降低消费会不会让积压恶化？ 回答：可能短时增长，但配合入口限流后可进入稳定恢复，比压垮下游更可控。
   • 追问 2：如何确定安全水位？ 回答：用真实负载压测和历史曲线找到延迟错误陡升前的拐点并保留余量。
   • 追问 3：如何分配新旧消息？ 回答：按业务时效拆通道或设份额，关键状态优先且低优先级保留最低服务量。
   • 详细知识

7. 问题（生产超时）：生产消息超时后，怎样避免丢失与重复副作用？

   口述答案：生产超时代表结果未知，不能简单解释为失败。消息可能没有到 Broker（代理节点），也可能已经持久化但确认响应在网络中丢失。为了避免静默丢失，发送端通常需要重试，但必须复用稳定的事件号，而不是重新生成业务事实。支付和库存场景中，我会在同一数据库事务写业务记录与 Outbox（发件箱），发送器按事件号发布并记录目标主题、尝试次数和结果；超时后重试同一事件。客户端幂等能力只能减少部分重复，消费端仍以 event_id 或业务键加版本建立唯一约束，因为消费确认丢失、宕机和再均衡仍会重投。排障时把 Outbox（发件箱）提交时间、客户端请求、代理节点落盘或位移、消费幂等记录和业务结果连成时间线，区分未发送、已发送未确认、已消费和业务失败。止血时降低无界重试、保护关键事件发送，并暂停非关键重放，不能重新执行订单或扣款来“补消息”。恢复后从待发送和未知状态记录补发，按事件号核对生产数、消费数与业务副作用。长期设置指数退避、重试预算、发送延迟告警和故障注入，验证确认丢失时结果是可观察重复而非静默丢失。为了证明链路真的可恢复，我会专门演练“代理节点已落盘但响应丢失”和“业务已提交但消费确认丢失”两种窗口，预期结果都是出现可审计重复并被幂等吸收。演练报告要列出事件号、首次与重试时间、唯一约束命中和最终业务状态；任何无法定位去向的事件都说明证据链还不完整，不能上线资金或库存链路。

   • 追问 1：查询到消息存在后还需幂等吗？ 回答：需要，消费确认和业务提交之间仍有重复窗口。
   • 追问 2：发送成功但事务回滚怎么办？ 回答：说明双写边界错误，应使用事务内 Outbox（发件箱）或等价事务消息机制。
   • 追问 3：Outbox（发件箱）发送器宕机怎么办？ 回答：记录仍在权威库，由多实例租约或扫描恢复，并监控最老待发送时间。
   • 详细知识

8. 问题（消费者掉线）：消费者频繁掉线并触发 Rebalance（再均衡），如何处理？

   口述答案：我先区分真实进程宕机和“活着但无法心跳”。把消费组代次、成员加入退出、最后心跳和分区撤销时间，与 JVM（Java 虚拟机）Full GC（完全垃圾回收）、CPU（中央处理器）、线程栈、网络丢包和单批处理耗时对齐。比如 24 个分区、12 个消费者中有 4 个因 90 秒暂停失联，重分配和缓存预热停顿 40 秒，生产 10,000 条/秒就会新增 40 万条积压；若实例反复恢复和退出，再均衡不断重启，积压无法稳定下降。止血时冻结滚动发布和自动扩缩容，摘除异常实例，确认剩余容量后逐步恢复；不要同时重启所有成员。消费语义上坚持业务成功后提交连续 Offset（位移），并用事件号幂等，因为处理完成但提交前被撤销会重复。对于并发批次，撤销时停止拉取、等待有界任务，只提交无空洞的连续位置，超时则让新成员安全重放。长期修复内存泄漏、长垃圾回收、阻塞调用和过大批次，并结合产品版本使用静态成员或协作分配降低全量暂停。发布改成小批次，每批等分配与 Consumer（消费者） Lag（延迟）稳定后继续。回归时注入暂停和网络隔离，验证接管时间、重复命中和业务不变量。恢复后我还会核对成员接管是否均匀、缓存预热是否导致长尾，以及重复命中是否集中在某个实例；若会话参数只能靠不断调大才能稳定，说明处理模型仍有阻塞。下一次发布前用同样规模的消息回放，模拟一个实例长暂停，验收接管时间、最大积压和恢复时长都在预算内，再允许扩大发布批次。

   • 追问 1：把会话超时调大行吗？ 回答：只能减少误判，也会延长真实故障接管，不能替代根因修复。
   • 追问 2：先提交位移能避免重复吗？ 回答：会把风险变成静默丢业务，不应这样取舍。
   • 追问 3：发布时何时回滚？ 回答：积压或错误超过预算、预计恢复不达标时停止发布并回到稳定版本。
   • 详细知识

9. 问题（热点分区）：集群总体利用率不高，但单个分区积压严重，如何治理？

   口述答案：这是典型的局部热点，不能被集群平均值掩盖。我会按 Partition（分区）或 Queue（队列接口）比较生产条数、字节、Consumer（消费者） Lag（延迟）、最老消息和 Leader（领导者）所在节点，再采样业务键频率。假设 32 个分区总生产 16,000 条/秒，看似平均 500 条/秒，但 warehouse-01 占 6,000 条/秒并落在单分区，而单分区稳定能力 2,000 条/秒，就会每秒积压 4,000 条，10 分钟达到 240 万。短期先限制热点来源、合并同一库存单位的中间变更、暂停低价值投影并保护关键最终状态；如果业务允许，可为热点客户或仓库建立隔离主题。不能随机打散同一业务键，否则库存或轨迹状态会乱序。长期先明确真正的顺序粒度：若只要求同一库存单位内有序，可以用 warehouseId + skuId 分片；用版本化路由处理扩分区前后的键映射，消费者根据业务版本拒绝状态倒退。已有积压通常仍在旧分区，增加分区不会自动迁走，需要原通道恢复或受控导流。验收时不仅看总积压下降，还看热点分区净速率、状态序号连续和下游负载均衡。治理完成后要建立热点键排行榜和分区偏斜指标，按小时记录最大分区与中位分区的速率比；比值持续超过阈值时提前处理，而不是等到积压。路由升级采用新旧版本并存和可回退映射，抽样核对同一业务键的状态序列；只有新分片的并行收益与顺序正确性同时通过，才逐步迁移全部流量。

   • 追问 1：增加消费者为什么没用？ 回答：同一分区在一个消费组内只有一个活动消费通道，新增成员没有可分配工作。
   • 追问 2：增加分区能立即清旧积压吗？ 回答：不能自动拆旧日志，主要提升未来路由并行度。
   • 追问 3：如何保持顺序？ 回答：按稳定业务键和路由版本分片，消费端以事件序号或状态版本拒绝倒退。
   • 详细知识

10. 问题（代理节点故障）：Broker（代理节点）宕机时如何从基础设施恢复到业务对账？

口述答案：我会按“发现、选主、客户端恢复、副本追赶、业务验收”五段处理。首先确认故障节点、受影响主题和分区，查看是否存在无 Leader（领导者）分区、ISR（同步副本集合）缩小、生产错误和消费停顿；冻结大规模迁移与非关键重放，避免剩余节点被重试压垮。控制面从合格副本选出新 Leader（领导者）后，客户端需要刷新元数据并使用同一事件号重试，超时窗口可能形成重复，因此消费幂等仍是必需。若为追求可用性考虑不干净选主，要明确它可能选择落后副本并丢失已确认数据，资金和库存通常不接受这种 RPO（恢复点目标）代价。故障节点恢复后，副本会读取缺失日志并写盘，形成额外网络和磁盘压力；我会限制追赶与分区迁移并发，优先关键主题，观察前台 P99（99 分位响应时间）延迟、ISR（同步副本集合）和复制差距。基础设施恢复后仍要按业务事件号、生产结果、分区位移、幂等记录和业务流水对账，区分重复、延迟和缺失。长期通过跨故障域副本、磁盘预测、Leader（领导者）负载均衡和定期故障演练验证接管与恢复时间，而不是把“节点重新上线”当作事故结束。事故演练还包括旧节点恢复后限制副本追赶，观察前台写入分位延迟与复制差距是否同时收敛；若恢复流量影响关键主题，就降低追赶并优先业务。对账不能只比较总数，要按事件标识逐条核对已确认生产、实际消费和业务落库，并把无法自动收敛的记录转入人工清单，明确负责人和完成时限。

• 追问 1：为什么不能立即重启所有节点？ 回答：会扩大选主、连接重建和复制冲击，同时丢失现场证据。
• 追问 2：副本恢复为何影响前台？ 回答：追赶会与生产消费争用网络、磁盘和请求处理资源。
• 追问 3：什么时候事故结束？ 回答：副本健康、流量稳定、积压恢复且事件级业务对账完成后。
• 详细知识

11. 问题（重试风暴）：外部接口故障后重试量激增，如何止血并恢复？

口述答案：我先把原始消息、首次失败和各次重试分开统计，按事件号、错误码和依赖画出流量放大。正常 5,000 条/秒、失败率 40%、立即重试 5 次时，调用会接近 8,300 次/秒；如果依赖全失败，最坏会放大到 30,000 次/秒。此时增加消费者等于给故障依赖继续加压。止血第一步是停止即时无界重试，打开 Circuit Breaker（熔断器），把可恢复失败改成 10 秒、30 秒、120 秒等有抖动的延迟重试；第二步保护新消息和资金、库存等高优先级通道，暂停可重建统计；第三步把参数错误、状态机非法等永久失败直接隔离到 Dead Letter Queue（队列接口）（死信队列），避免占用重试预算。依赖恢复后不能一次性回灌，我会用半开探测确认延迟和成功率，再按配额阶梯放量，并为新流量与历史重试分配份额。每次重试复用事件号和外部幂等号，未知结果先查询而不是再次执行。根因修复包括错误分类、最大次数、总时间预算、指数退避和死信处置时限。回归通过模拟全失败和慢响应，验证请求量不会随失败次数爆炸、关键新消息仍有服务份额、恢复后事件级对账无重复副作用。长期治理时我会为每类错误维护是否可重试的白名单和总预算，未知错误默认隔离而不是无限重试；重试通道单独限额，防止抢占新消息。每季度模拟依赖全失败，验证调用放大不超过预设上限、熔断在规定窗口内打开、死信有告警且恢复时阶梯回放，最终以业务事件对账而不是请求成功率收口。

• 追问 1：暂停重试会丢消息吗？ 回答：不会，只要失败状态持久化、有恢复账本和明确最终去向。
• 追问 2：哪些错误不应重试？ 回答：参数非法、权限永久拒绝和状态机非法迁移应直接隔离。
• 追问 3：为何加入随机抖动？ 回答：避免大量消息在同一退避时刻同时醒来形成同步洪峰。
• 详细知识

12. 问题（死信治理）：Dead Letter Queue（队列接口）（死信队列）突然增长，怎样调查和安全回灌？

口述答案：死信增长首先是待调查事故，不是自动重放任务。我会立即冻结自动回灌，记录开始时间、增长速率和受影响业务，按生产者版本、消息类型、错误码、业务键和首次失败时间聚类，并保存原消息、事件号、重试次数、异常堆栈与校验值。若错误集中在新版本字段映射，就冻结发布；若集中在外部依赖，则先熔断；若是单个毒消息，则隔离业务键避免堵塞整个有序通道。随后确认每类错误是可重试、需修数据、需兼容旧格式还是状态机不允许，永久无效数据应进入有审计的终态，不能循环进出死信。修复后先选 100 至 500 条代表样本在隔离环境或影子表验证，检查消费幂等、状态迁移和外部副作用；再按 1,000、2,000、3,000 条/秒等阶梯回灌，速率不得超过下游安全水位，同时监控失败回流比例。回灌复用原事件号，保留批次号和操作人，能够暂停与回滚。最后按事件总数和业务个体对账，确认成功、仍失败和人工处理三类数量闭合。长期为死信数量、最老年龄和未处置时长设目标，保留期结束前归档审计证据。回灌完成后还要保存三方数字：进入死信总数、成功修复数、永久终止或人工处理数，三者必须闭合。抽样不仅看消费返回成功，还核对资金、库存或轨迹状态；如果新版本仍产生同类错误，自动停止下一档放量。复盘要追到为什么不兼容数据能进入生产、为什么预检和契约测试未阻止，而不是把责任留给值班人员手工回灌。

• 追问 1：为什么不能直接全量回灌？ 回答：根因可能未修复，且全量会压垮下游并形成死信循环。
• 追问 2：死信可以无限保留吗？ 回答：不可以，应有业务审计保留期、归档和处置时限。
• 追问 3：回灌如何避免重复？ 回答：复用原事件号，消费端唯一约束，并记录回灌批次进行对账。
• 详细知识

13. 问题（外部依赖慢）：消费者调用第三方从 100 毫秒变为 2 秒，为什么不能只扩线程？

口述答案：消费者能力由服务时间和允许并发共同决定。40 个线程、平均 100 毫秒时理论约 400 次/秒；响应变为 2 秒后只有约 20 次/秒。入口仍为 300 条/秒，就每秒积压约 280 条，10 分钟达到 168,000 条。若把线程扩到 400，理论在途变成 200 个请求，但第三方配额只有 50 次/秒，结果是连接堆积、超时和重试，实际成功吞吐可能更低。排障时我会联合看消息可见积压、Unacked（未确认）、本地线程池队列、连接池占用、外部 P99（99 分位响应时间）延迟和错误码，识别消息是否只是从代理节点搬到客户端形成隐性积压。止血采用独立并发隔离、总超时、每依赖限流和 Circuit Breaker（熔断器），把调用压到对方可承受的 40 次/秒；非关键请求降级或延迟，入口通过 Backpressure（背压）进入限流。对支付这类未知结果，超时后先查单并复用渠道幂等号，不盲目重扣。依赖恢复时先半开少量探测，再阶梯放量，给新旧消息分配资源。长期把配额、超时和服务率纳入容量模型，故障演练验证一个依赖变慢不会耗尽整个消费者进程。我会把外部依赖的配额和延迟分位写入消费限流配置，并设置在途请求上限，确保本地内存与连接池有确定边界。依赖恢复后的每档放量都比较成功吞吐、超时和对方限流响应；如果请求增加但成功数不增，就立即退档。最终通过断网、慢响应和未知结果三种演练，验证查询、补偿与幂等路径都能收敛。

• 追问 1：队列可见积压下降代表变好了吗？ 回答：不一定，消息可能囤在未确认、本地队列或执行线程中。
• 追问 2：为什么要隔离线程池？ 回答：避免一个慢依赖占满共享线程，拖垮其他消费业务。
• 追问 3：恢复时为何半开？ 回答：用小流量验证真实恢复，防历史积压再次压垮依赖。
• 详细知识

14. 问题（Kafka 排障）：Kafka（分布式日志消息系统）出现积压时，如何建立完整指标证据链？

口述答案：我按生产、Broker（代理节点）、消费组和业务四层建立同一时间线。生产层看每 Topic（主题）和 Partition（分区）的条数、字节、请求延迟、错误与重试，判断入口突增还是特定键热点；代理节点层看磁盘、网络、请求队列、ISR（同步副本集合）、未充分复制分区和 Leader（领导者）分布，判断复制或节点资源是否异常；消费组层看每分区 Consumer（消费者） Lag（延迟）、最老消息年龄、成员变化、Rebalance（再均衡）、拉取速率和 Offset（位移）提交；业务层看真实成功、处理耗时、幂等命中、数据库和外部依赖。比如总延迟 100 万但单分区占 90 万，应先按键查热点，而不是把所有消费者翻倍；ISR（同步副本集合）缩小且生产延迟升高，则先保护副本和磁盘。止血可能是入口限流、暂停非关键重放、受控扩消费者或隔离热点，动作必须对应证据。恢复时间用业务成功减生产的净速率计算，不能用 Fetch（拉取）条数。恢复后对事件号、分区位移与业务流水核对，确认没有先提交造成的静默丢失。长期把分区级延迟、最老年龄、预计恢复时间、复制健康和路由偏斜纳入告警，容量压测覆盖节点故障和再均衡。为了让指标可执行，我会给每类告警附上分区、实例、最近变更和第一条诊断命令，并设高低水位避免反复告警。故障演练中主动停止一个代理节点和一个消费者，确认复制、选主、成员接管与业务对账均能在目标时间完成；如果基础设施恢复而业务事件仍缺失，说明确认边界或观测链路存在漏洞，必须继续整改。

• 追问 1：总延迟下降就能结束吗？ 回答：不能，还要看关键分区、最老年龄、业务成功、死信与冷却期。
• 追问 2：ISR（同步副本集合）缩小意味着什么？ 回答：有副本跟不上，容错余量下降并可能影响满足确认条件的写入。
• 追问 3：为何按分区看？ 回答：顺序、复制和消费分配的最小单位是分区，总平均会掩盖热点。
• 详细知识

15. 问题（RocketMQ 排障）：RocketMQ（分布式消息队列）消费差值正常，业务仍延迟，如何查？

口述答案：消费差值只代表代理节点上的逻辑位置，不一定代表业务完成。我会用 Message Key（消息键）串起发送时间、目标 Topic（主题）与 MessageQueue（消息队列）、首次投递、消费返回状态、重试次数和业务落库时间；同时检查最老消费时间、重试主题、消费线程池队列和 Broker（代理节点）存储水位。常见问题是消费者收到消息后把任务丢进本地异步线程池，立即返回成功，代理节点位移前进但本地任务仍排队，进程宕机还会静默丢失；另一种是失败进入重试或 Dead Letter Queue（队列接口）（死信队列），主队列差值下降但用户结果没有完成。止血时限制本地队列和消费并发，业务完成后再返回成功；若必须异步，则先把任务可靠写入本地任务表并由独立补偿驱动。按错误类型暂停无界重试，保护关键顺序消息和事务状态。恢复后以业务键核对消息、重试和状态机，不用主队列差值清零作为结束。长期监控最老业务完成时间、消费线程池活跃度、重试年龄和死信处置时长，并通过进程宕机演练验证确认边界。这样能清楚区分“消息被拿走”和“副作用已可靠完成”。我还会用进程突然退出验证消费返回与业务落库的先后关系：若本地线程未完成但消息已经确认，测试应能稳定复现缺失。修复后把待处理任务先写入可靠任务表，重启时从状态扫描恢复，并核对消息键、任务记录和最终业务结果三者数量闭合。只有故障注入下仍表现为可重试或可补偿，才算真正完成。

• 追问 1：消费返回成功后异步失败怎么办？ 回答：消息不会自动重投，应在确认前完成或把异步任务先可靠落库。
• 追问 2：差值小为何看最老时间？ 回答：少量毒消息或顺序阻塞可能严重超时，却不显著增加总量。
• 追问 3：如何对账？ 回答：按消息键、重试记录和业务状态机逐个核对最终状态。
• 详细知识

16. 问题（RabbitMQ 排障）：Ready（待投递）下降、Unacked（未确认）上升说明什么？

口述答案：这通常说明消息从 RabbitMQ（消息队列）队列转移到了消费者在途状态，并不代表业务变快。比如 Ready（待投递）从 200,000 降到 20,000，Unacked（未确认）从 5,000 升到 190,000，而业务完成仍为 1,000 条/秒，大量消息可能被过高 Prefetch（预取）囤在少数慢消费者内存或本地线程池。排障时按连接和 Channel（通道）查看未确认数量、投递与 Ack（确认）速率、处理耗时、内存、连接关闭和 Redelivery（重投递），再对齐数据库或外部依赖。止血可以降低 Prefetch（预取）、暂停继续拉取、摘除明显慢实例，让未确认消息重新投递；但关闭连接前必须确认消费幂等，因为重投会造成重复副作用。不能把 Prefetch（预取）直接设成 1 当万能答案，过小会增加往返并降低吞吐，应依据单条耗时、内存和消费者数量压测。长期让本地处理队列有界，业务完成后才确认，监控 Ready（待投递）加 Unacked（未确认）的总在途、最老消息和业务成功。Quorum Queue（队列接口）（仲裁队列）还要检查副本健康和磁盘告警，避免把代理节点复制问题误判为消费者慢。调整预取后要观察单消费者未确认分布的离散程度，防止总量正常但某实例囤积；同时比较网络往返与吞吐，避免过度降低造成新瓶颈。关闭慢连接只作为有回退的止血动作，执行前确认幂等，执行后限制重投速率。最终用消息年龄和业务完成时间证明公平性改善，而不是只展示待投递数下降。

• 追问 1：Ready（待投递）为零说明无积压吗？ 回答：不说明，消息可能全部处于未确认或客户端本地排队。
• 追问 2：关闭消费者有什么风险？ 回答：未确认消息重投，若业务不幂等会重复执行。
• 追问 3：Prefetch（预取）如何选？ 回答：以处理耗时、内存、公平性和吞吐压测取平衡值。
• 详细知识

17. 问题（WMS 峰值）：WMS（仓储管理系统）库存事件高峰如何削峰而不破坏防超卖？

口述答案：我先划清同步裁决和异步传播边界。库存是否可售必须由数据库条件更新、预占状态机或等价原子约束同步决定，不能先把订单放进队列就向用户承诺成功；MQ（消息队列）承接的是“库存已裁决”后的通知、搜索投影、履约任务和运营统计。容量上假设活动生产 18,000 条/秒、消费 10,000 条/秒、持续 300 秒，会积压 240 万条；若单条 1 KiB（千字节），还要计算副本、保留和恢复磁盘。峰后入口 2,000 条/秒，受控提升消费到 14,000 条/秒，净消化 12,000 条/秒，理论约 200 秒清空，但数据库和外部仓配系统必须先通过压测。路由按 warehouseId + skuId 保持同库存单位顺序，热点库存单位可合并中间变化或隔离，不随机打散。消息事件号与库存流水唯一关联，消费者重复时唯一约束吸收，失败进入有预算重试和补偿。事故期优先保证库存事实与 Outbox（发件箱），暂停报表等可重建消费者。恢复后按库存流水、事件号和投影版本对账，验证可售加预占加已售的不变量，并用最老消息年龄和目标恢复时间验收。活动结束后我会保存峰值输入、库存条件更新成功数、事件发布数、幂等命中和各投影完成数，任何差异都有明确去向。下一次压测还会注入热点库存单位与一个消费者组掉线，确认数据库裁决不受异步链路影响、关键事件在恢复目标内完成、低优先级投影能够从权威流水重建。

• 追问 1：为什么不能异步扣库存？ 回答：用户承诺先于库存裁决会造成超卖或大规模撤单。
• 追问 2：热点库存怎么处理？ 回答：保持键内顺序，合并中间事件或独立通道，不能随机分区。
• 追问 3：队列故障怎么办？ 回答：权威事务留下 Outbox（发件箱），恢复后补发且消费者幂等。
• 详细知识

18. 问题（支付恢复）：支付通知积压时如何计算恢复速度并保证资金一致性？

口述答案：支付链路首先以渠道事实、内部账务流水和订单状态机为权威，MQ（消息队列）负责驱动通知、查询和状态收敛，不凭一个 Ack（确认）宣称资金一致。假设积压 900,000 条，渠道配额 3,000 次/秒，正常新增 1,000 条/秒，若目标 10 分钟恢复，需要净消化 1,500 条/秒，总调用 2,500 条/秒，低于配额；若要求 5 分钟，总调用需 4,000 条/秒，超过配额，不能靠更多消费者绕过，只能调整目标、申请临时配额或减少可合并查询。消费者以支付单号、渠道请求号和动作类型构造幂等键，超时进入处理中，先查单或等待回调，不能用新请求号重复扣款。恢复时为新支付结果保留服务份额，历史通知按账龄和状态优先级回放；Dead Letter Queue（队列接口）（死信队列）先分类再回灌。监控除 Consumer（消费者） Lag（延迟）外还看最老支付状态、渠道 P99（99 分位响应时间）、未知状态数量、重复回调和对账差异。恢复后以渠道账单、内部流水、订单状态逐笔对账，差异进入查询、补记或冲正流程，直到金额守恒。长期把渠道配额、查单能力和对账周期纳入容量与演练。支付恢复还要设置未知状态的最长停留时间，超过阈值自动查单并进入人工队列，而不是反复扣款。对账差异的每次补记或冲正都关联原支付单、渠道流水和操作批次，确保审计可追溯。演练会模拟回调重复、回调早于同步响应和渠道账单晚到，验证状态机只前进到合法终态。

• 追问 1：渠道超时算失败吗？ 回答：不一定，属于未知结果，应查单或等回调后收敛。
• 追问 2：为何不能追求 5 分钟？ 回答：所需 4,000 次/秒超过渠道配额，会制造更多失败。
• 追问 3：资金一致如何验收？ 回答：渠道账单、内部流水和订单状态逐笔对账，差异有补记或冲正终态。
• 详细知识

19. 问题（IoT 风暴）：IoT（物联网）报警风暴如何做容量、优先级和降级？

口述答案：IoT（物联网）报警要先区分不可丢的安全告警、可合并的重复状态和可采样的遥测。假设 100,000 台设备在故障时每 5 秒上报一次，即 20,000 条/秒；若消费者只能处理 8,000 条/秒，10 分钟会新增 720 万条。直接扩容可能把通知渠道和工单系统压垮，所以入口先按设备与告警类型做去抖和窗口聚合，例如同设备同故障 60 秒只保留首次、最高级别和恢复事件；高等级进入独立主题与消费者配额，低等级遥测可采样或延迟。每条保留设备号、告警类型、发生时间、序号和聚合窗口，消费者按设备状态版本幂等，不能让迟到“故障”覆盖较新的“恢复”。容量计算包含峰值字节、副本、保留、分区键和峰后恢复，热点网关需单独隔离。故障期间通过 Backpressure（背压）限制非关键生产，保护告警通知和人工处置；重试要有预算，通知渠道失败时合并而非逐条猛攻。恢复后核对设备最终状态、关键告警送达、聚合丢弃数量和人工工单，明确被采样的是可重建遥测而非安全事实。长期用风暴回放验证高优先级时效和低优先级降级规则。降级规则必须在活动前由业务确认并可审计，例如被聚合的重复报警仍记录计数、窗口与最高等级；关键恢复事件绝不采样。恢复后按设备最终状态与告警序号做抽样和全量统计，确认没有故障状态长期悬挂。还要验证单一网关热点不会拖垮其他区域，并将隔离阈值与人工升级流程固化。

• 追问 1：所有报警都不能丢吗？ 回答：不是，关键状态跃迁不可丢，重复遥测可按明确规则聚合或采样。
• 追问 2：如何防迟到覆盖？ 回答：按设备序号或状态版本条件更新，拒绝旧版本倒退。
• 追问 3：为何拆主题？ 回答：实现资源和故障隔离，让低价值风暴不能饿死安全告警。
• 详细知识

20. 问题（异步导出）：异步导出积压和 OOM（内存溢出）怎样联合治理？

口述答案：异步导出不是把同步查询搬到消费者就结束，而是要把任务容量、数据库压力和文件内存一起约束。入口创建任务并返回任务号，任务表是权威状态，MQ（消息队列）只驱动执行；同一用户、同一参数和数据版本可以合并重复任务。容量上若每秒新增 40 个任务、平均完成 90 秒，按 Little’s Law（利特尔定律）平均在途约 3,600 个；数据库变慢使完成时间到 300 秒，在途升到 12,000 个，即使入口没变也会积压。消费者不能一次把百万行加载内存，应分页或游标读取、流式写临时文件并上传对象存储，只在消息中传任务号和对象引用；每实例限制并发、内存和数据库连接。出现 OOM（内存溢出）时暂停新拉取，保留任务状态，分析堆转储、单任务峰值和并发，降低并发并恢复未完成任务，而不是重复创建。恢复积压前先确认数据库安全水位，按用户公平和任务年龄调度，大任务可拆分但最终合并要幂等。监控任务最老年龄、执行中数量、单任务内存、文件大小、数据库耗时和失败原因。恢复后校验文件行数、校验值、对象存在和任务状态，过期文件按生命周期清理。任务平台还需要为单用户和大任务设置配额，避免一个超大导出占满所有槽位；执行中定期写检查点，使重启从已完成分页继续。压测用真实字段宽度和最大行数，记录单任务峰值内存、临时磁盘、数据库扫描和上传带宽。验收时任务成功数、对象文件数和校验记录必须一致，失败任务有可解释终态。

• 追问 1：为何消息不放文件？ 回答：大消息会占用代理节点资源并放大复制、重传和头阻塞。
• 追问 2：任务如何幂等？ 回答：用用户、参数、数据版本生成业务键，并由任务表唯一约束。
• 追问 3：OOM（内存溢出）后怎样恢复？ 回答：依据任务状态与检查点重新执行，流式处理并控制并发，不重建业务任务。
• 详细知识

21. 问题（Runner 调度）：Runner（执行器）任务消息积压时，如何避免重复执行和租约失效？

口述答案：Runner（执行器）的关键不是“消息只投一次”，而是任务实例有唯一状态机和执行租约。调度中心以 jobInstanceId 创建待执行记录并发布事件，执行器抢占时使用版本号或租约到期时间做条件更新，只有抢占成功者进入运行；消息因超时、消费者掉线或 Rebalance（再均衡）重复时，其他执行器看到实例已运行或完成就返回幂等成功。容量上把任务到达率、平均执行时长和并发槽位统一计算，例如每分钟 1,200 个任务、平均 30 秒，稳定在途约 600 个；若只有 300 个槽位，每槽每分钟完成 2 个，能力也是每分钟 600 个，入口长期高于能力就必然积压。止血不是无限加线程，而是按任务优先级、资源标签和下游配额限流，暂停可延后批处理，保护结算与库存任务。执行超过租约时必须续租，续租失败不能直接让旧执行器继续提交结果；结果写入带租约版本或 Fencing Token（栅栏令牌），拒绝过期执行器覆盖新结果。执行器宕机后由扫描器把超时实例转为可重试，重试次数和最终失败均持久化。排障看任务年龄、抢占冲突、租约续期、执行耗时和外部依赖。恢复后核对实例总数、唯一结果和副作用，演练消息重复、网络分区与执行器停机。调度恢复时我会按优先级逐步开放槽位，观察租约冲突、续期失败和过期结果拒绝数，避免积压回放制造重复执行。对产生外部副作用的任务，结果表和业务流水都用实例号建立唯一关系；人工重跑必须创建明确的新尝试并保留原失败记录。最终用同一实例被两个执行器同时拿到的演练证明栅栏版本能够拒绝旧执行者。

• 追问 1：分布式锁够吗？ 回答：不够，锁过期后旧执行器仍可能提交，需要状态机与栅栏版本拒绝陈旧写。
• 追问 2：任务消息何时确认？ 回答：至少在任务已被可靠状态机接管后，不能仅放入内存线程池就确认。
• 追问 3：长期过载怎么办？ 回答：限流、预约、扩真实资源或降低任务频率，队列只能缓冲短峰。
• 详细知识

22. 问题（物流轨迹）：跨境物流轨迹积压时，怎样兼顾顺序、吞吐和最终状态？

口述答案：轨迹真正需要的是同一运单内有序，不是所有运单全局有序。我会用 waybillNo 作为稳定业务键路由，同一运单事件进入同一 Partition（分区）或 MessageQueue（消息队列），不同运单并行；消息携带渠道事件号、发生时间、采集时间和业务序号，消费者通过运单加事件号唯一约束去重，并用状态机和版本条件更新拒绝迟到事件让状态倒退。容量上按大客户和渠道分别观察键分布，避免某个渠道把单分区打热；高峰时先保留揽收、清关、签收等状态跃迁，重复扫描可窗口合并，不能随机打散同一运单。若某条毒消息解析失败，短期有界重试后隔离该运单键，其他运单继续处理，修复映射后按原序号回放。外部轨迹接口慢时按渠道独立限流、熔断和配额，不让一个渠道耗尽所有线程。恢复计算用业务成功减新增事件的净速率，并同时看最老运单事件年龄。恢复后按运单逐条核对事件序列、最终状态和缺失渠道回执，迟到但合法的历史节点可补入时间线，却不能覆盖更高版本的最终状态。长期通过历史风暴回放和渠道故障演练验证顺序及隔离。轨迹恢复还会抽取跨时区、渠道重复和乱序样本，验证发生时间与采集时间没有混用；对最终签收后的迟到中间节点，只补历史展示而不回退主状态。每个渠道保留独立成功率、最老事件和配额视图，故障渠道恢复时小批量回放。最终以运单级完整率和状态正确率验收，不以消息总数相等代替。

• 追问 1：为什么不用全局顺序？ 回答：成本高且没有业务必要，不同运单彼此独立可以并行。
• 追问 2：迟到事件如何处理？ 回答：保留历史轨迹，但状态更新按业务序号或状态机拒绝倒退。
• 追问 3：热点渠道怎么办？ 回答：渠道隔离、键分布治理和重复事件聚合，不破坏运单内顺序。
• 详细知识

23. 问题（顺序阻塞）：一条毒消息阻塞顺序消费，应该跳过还是等待？

口述答案：选择取决于后续事件是否依赖前序状态，不能用统一规则。订单“已支付”之后才能“已发货”，若支付事件处理失败却跳过，后续状态可能非法；但让一条毒消息永久阻塞整个分区，又会拖住大量无关订单。我的处理是先限定顺序粒度到业务键，在同一键内短期有界重试，超过次数或时间预算后暂停这个键，把原消息、后续消息和当前状态转入专用补偿通道，主分区继续处理其他键。补偿端修复数据或兼容版本后，按序号从失败位置回放，状态机和幂等约束保证不重复副作用、不发生倒退。如果产品只提供分区级串行而应用无法键级隔离，就需评估把不同键分到更细分区或在消费端建立有界的键队列，但要严格管理 Offset（位移）提交，不能跨越尚未可靠落地的空洞。对彼此独立的通知事件，可以记录失败并继续，但必须进入 Dead Letter Queue（队列接口）（死信队列）和处置账本。监控要看阻塞键、最老年龄、重试次数和影响消息数。回归用“失败、后续到达、修复回放”的完整序列验证最终状态，而不是只看队列清零。键级隔离还要防止补偿通道永久无人处理，因此设置最老隔离年龄、责任团队和自动升级。修复前在影子状态机重放失败键的完整序列，确认每一步合法，再用原事件号执行；回放后对该键解除暂停并观察后续事件。若应用无法安全管理位移空洞，就宁可拆队列或降低并发，也不提前确认未持久化任务，并为人工处置保留完整审计记录。

• 追问 1：为何不无限重试？ 回答：永久错误会形成头阻塞并放大资源消耗，必须有预算和最终去向。
• 追问 2：如何只暂停一个键？ 回答：应用维护键级状态或转入专用补偿通道，主通道继续其他键。
• 追问 3：能提交后续位移吗？ 回答：只有后续任务已可靠持久化且可独立恢复，否则会造成静默丢失。
• 详细知识

24. 问题（磁盘满事故）：Broker（代理节点）磁盘 92% 且预计 2 小时写满，如何处理？

口述答案：我先把静态使用率转换为预计写满时间，并按目录、主题和分区定位增长来源。检查最近窗口净写入、保留删除滞后、最大段文件、死信与重试主题、副本追赶以及热点 Leader（领导者），同时确认关键主题的生产错误、ISR（同步副本集合）和消费位移。止血顺序是冻结大规模重放和分区迁移，限制非关键生产，保护支付、库存权威事务及 Outbox（发件箱）；有条件时扩盘或迁移冷分区。调整保留只针对已确认可重建、已归档且消费组位移安全的数据，不能手工删除活跃文件，也不能为腾空间牺牲资金审计。若副本恢复形成写放大，降低追赶并发，避免前台延迟恶化。每个动作记录可释放字节、耗时和回退条件，持续更新预计写满时间；空间降到低水位后仍观察净增长和删除速度至少 30 分钟，再逐步恢复流量。根因可能是流量超预算、保留配置错误、清理任务异常或容量预测缺失，分别修复并补告警。最后核对故障窗口的生产事件、重复重试和业务结果，验证没有因磁盘保护产生静默缺失。复盘将 12 小时预警、6 小时事故、高低水位和扩容提前量写成自动规则。处置期间每十五分钟更新一次剩余空间、净增长和预计写满时间，让业务和运维知道是否需要进一步限流。扩盘或迁移后检查目录挂载、文件系统和副本分布，防止只是释放一台节点而把热点移到另一台。事故关闭前重放故障窗口并核对确认事件，证明磁盘保护未造成关键消息永久缺失。

• 追问 1：能马上缩短所有主题保留吗？ 回答：不能，先判断可重建、审计和消费位移，关键事实流不能盲删。
• 追问 2：为何暂停副本迁移？ 回答：迁移会增加磁盘读写和网络，可能加速剩余节点过载。
• 追问 3：何时恢复全流量？ 回答：低水位稳定、净增长受控、复制与业务对账都通过后阶梯恢复。
• 详细知识

25. 问题（发布抖动）：滚动发布导致消费组持续 Rebalance（再均衡），怎样设计安全发布？

口述答案：发布前先做剩余容量预算：下线一批实例后，存活消费者是否仍能承担当前生产并在目标时间恢复。假设 12 个实例能力 12,000 条/秒，生产 10,000 条/秒，同时下线 4 个后剩余能力约 8,000 条/秒，发布每分钟都会新增约 120,000 条积压；如果下一批在上一轮 Rebalance（再均衡）未稳定前继续下线，消费暂停和缓存预热会叠加。安全策略是小批次发布，通常一次只移除容量预算允许的成员；每批等待成员代次、分区分配、Consumer（消费者） Lag（延迟）、最老消息年龄和业务错误率稳定，再继续。发布期间冻结自动扩缩容，避免两个控制器同时改变成员；结合版本支持的静态成员或协作式分配减少全量撤销，但仍不能替代容量。消费者收到撤销通知后停止拉取，等待有界任务并只提交连续成功 Offset（位移）；超时未完成的让新成员幂等重放。回滚条件预先写明，例如最老年龄超过 120 秒、净积压持续 3 个窗口或业务错误翻倍，就停止发布并恢复旧版本。发布后观察冷却期和重复命中，再做事件级抽样对账。长期在预发布环境注入慢实例和网络隔离，验证成员接管及提交边界。发布流程还会把分区撤销耗时和未完成任务数作为门禁，超过预算就阻止下一批；消费者退出前先停止拉取并等待有界处理，而不是依赖进程终止信号立即杀死。回滚也按小批恢复，避免旧版本一次性加入再次触发抖动。完整演练应覆盖升级、回滚和一个实例失联，证明三种情况下都能有限恢复。

• 追问 1：为什么冻结自动扩缩容？ 回答：避免发布和扩缩容同时改变成员，造成持续再均衡和原因不可辨。
• 追问 2：静态成员能消除所有再均衡吗？ 回答：不能，只能减少短暂重启引起的变动，真实故障和成员变化仍需重分配。
• 追问 3：发布积压可接受吗？ 回答：只要在预算内、有有限恢复时间且业务时效未超标，可以暂时接受。
• 详细知识

26. 问题（容量设计题）：日均十亿条消息的系统，面试中应怎样完成容量规划？

口述答案：我不会用日均直接选机器，而是先把业务拆成峰值、消息大小、键分布、可靠性和恢复目标。十亿条/日平均约 11,574 条/秒，但若峰均比 8，峰值约 92,600 条/秒；再取平均与 P99（99 分位响应时间）大小，例如 1 KiB（千字节）与 8 KiB（千字节），分别计算入口和极端字节流量。存储按峰谷真实曲线、保留天数、复制因子、压缩实测和 40% 故障余量估算，重试与 Dead Letter Queue（队列接口）（死信队列）独立预算。并行度用单 Partition（分区）或 Queue（队列接口）在目标确认、副本和消息分布下的压测吞吐反推，再考虑热点键、顺序粒度、故障时损失一个节点仍可承载。消费侧按每类业务服务时间和下游配额分别建 Consumer Group（消费者组），不能把所有处理能力合成一个数字；定义可接受积压、最老消息年龄和 RTO（恢复时间目标），由此算净恢复能力。可用性说明副本、跨故障域、确认策略和 RPO（恢复点目标），端到端可靠仍靠 Outbox（发件箱）、消费幂等和对账。最后给出压测矩阵：正常峰值、一个节点故障、热点 30%、下游减半、再均衡和恢复回放，并用指标验证，而不是声称公式结果就是生产能力。我还会给出节点数的故障余量推导：正常只用部分能力，失去一个故障域后仍能承受峰值并有净恢复能力。消息大小采用分布而非单值，热点键单独做倾斜压测。所有估算最终落到一张容量表，列明假设、数据来源、验证日期和风险；实际指标连续偏离假设时触发重新评审，避免旧模型长期沿用。

• 追问 1：为何不能按平均 11,574 条/秒设计？ 回答：峰值、故障和恢复都远高于平均，会在短时间形成不可恢复积压。
• 追问 2：分区数如何定？ 回答：峰值吞吐除以单分区实测能力，再考虑消费者并发、热点和未来扩容余量。
• 追问 3：机器数如何验收？ 回答：以目标副本和故障场景压测，在丢一节点后仍满足时效与可靠性。
• 详细知识

27. 问题（监控设计）：怎样设计 MQ（消息队列）监控，避免只看积压条数？

口述答案：监控要覆盖“进入、持久化、投递、业务完成、补偿”五段，并用事件号连接。入口看条数、字节、错误、重试和生产延迟；Broker（代理节点）看磁盘使用与预计写满、网络、请求延迟、副本健康和热点分布；消费看每分区或队列 Consumer（消费者） Lag（延迟）、最老消息年龄、增长斜率、成员变化、Rebalance（再均衡）、Ready（待投递）、Unacked（未确认）和提交/确认；业务看成功率、处理 P99（99 分位响应时间）、幂等命中、状态机拒绝、数据库和外部依赖；补偿看重试、Dead Letter Queue（队列接口）（死信队列）数量、最老年龄和未处置时长。告警不只设固定条数，而是按业务等级看最老年龄和预计恢复时间：同样 100 万条，日志消费者可能几秒恢复，支付补偿可能已是严重事故。每个告警带主题、分区、业务键样本、最近变更和推荐操作手册，避免值班再拼信息。高低水位和连续窗口减少抖动，预测写满与净恢复小于等于零要提前升级。仪表盘同时展示基础设施和业务不变量，清零但业务失败仍保持事故。通过定期注入消费者停机、磁盘增长和外部慢响应验证告警真的触发且指向正确根因。监控还要有业务抽样追踪：从生产事件中抽取固定比例，验证在目标时间内出现业务完成记录，否则即使中间件指标正常也告警。仪表盘按业务等级分层，资金与库存优先展示未知状态和对账差异，通知与报表展示可延后量。每个告警季度演练一次，确保联系人、权限和操作手册没有失效。

• 追问 1：最关键的三个指标是什么？ 回答：最老消息年龄、积压增长斜率和基于业务成功吞吐的预计恢复时间。
• 追问 2：为何看幂等命中？ 回答：它能暴露确认丢失、重投和再均衡带来的重复窗口。
• 追问 3：告警何时解除？ 回答：低水位稳定、错误和死信正常、业务对账通过并经过冷却窗口。
• 详细知识

28. 问题（产品选型）：容量与排障视角下，Kafka（分布式日志消息系统）、RocketMQ（分布式消息队列）、RabbitMQ（消息队列）如何取舍？

口述答案：我不会只用“吞吐高低”做选择，而是从数据模型、路由、重放、延迟、运维和团队经验判断。Kafka（分布式日志消息系统）以分区追加日志、消费组位移和保留重放见长，适合高吞吐事件流、轨迹和分析，但顺序与并行度受 Partition（分区）约束，排障重点是 Consumer（消费者） Lag（延迟）、ISR（同步副本集合）、Leader（领导者）分布和磁盘。RocketMQ（分布式消息队列）提供面向业务消息的普通、顺序、延迟和事务消息能力，适合订单与状态驱动，排障要看 MessageQueue（消息队列）差值、最老消费时间、重试与 Broker（代理节点）存储，并严格区分版本能力。RabbitMQ（消息队列）的 Exchange（交换机）路由、队列和确认模型灵活，适合复杂路由和中等吞吐任务，需重点治理 Ready（待投递）、Unacked（未确认）、Prefetch（预取）、连接和 Quorum Queue（队列接口）（仲裁队列）副本。无论选哪一种，容量都要按峰值字节、副本、保留、分区/队列和恢复目标实测；可靠性都不能替代业务幂等、状态机和对账。最终以现有基础设施、团队运维能力、故障演练和迁移成本做决策，不为简历堆叠三套中间件。选型验证会用同一份真实消息和故障矩阵测试三种方案，而不是引用厂商峰值：比较生产确认延迟、单键顺序、节点故障恢复、积压回放、运维复杂度和业务幂等接入成本。若团队已有稳定平台，新增产品带来的培训、监控和升级风险也要计入。最后形成决策记录，明确被放弃方案及条件变化后何时重评。

• 追问 1：支付一定选 RocketMQ（分布式消息队列）吗？ 回答：不一定，关键是事务边界、幂等、对账和团队能力，产品只是实现手段。
• 追问 2：轨迹为何偏 Kafka（分布式日志消息系统）？ 回答：高吞吐、按运单分区和历史重放通常匹配分区日志模型。
• 追问 3：复杂路由为何考虑 RabbitMQ（消息队列）？ 回答：Exchange（交换机）与绑定提供清晰路由，但仍需评估吞吐和仲裁队列成本。
• 详细知识

29. 问题（完整事故）：请讲一次“数据库索引退化导致消息积压”的生产事故。

口述答案：我会按数字和决策讲。14:00 轨迹事件入口升到 12,000 条/秒，消费者原本也能稳定处理 12,000 条/秒；一次索引变更使单批写入耗时上升，业务成功吞吐降到 8,000 条/秒。14:10 Consumer（消费者） Lag（延迟）达到 240 万，最老消息 200 秒，数据库 P99（99 分位响应时间）和锁等待同步上升。我们先冻结发布和自动扩容，确认不是 Broker（代理节点）或 Rebalance（再均衡），而是消费 SQL（结构化查询语言）的执行计划变化。14:12 暂停非关键轨迹重算，将入口限到 6,000 条/秒，防止积压和数据库继续恶化；没有盲目加消费者，因为数据库已是瓶颈。14:18 回退索引后，阶梯把消费恢复到 14,000 条/秒，净消化 8,000 条/秒，约 300 秒清空。恢复期间持续看错误率、数据库水位和预计恢复时间，未出现重试风暴。15:00 以 240 万事件号与轨迹表逐条核对，1,842 条重复均被唯一约束吸收，缺失 0 条，最终状态无倒退。根因是索引变更缺少峰值写压测和执行计划基线。改进包括 SQL（结构化查询语言）计划漂移告警、最老消息与预计恢复告警、索引灰度、自动回退阈值和季度积压演练。复盘后的每项改进必须能验证，例如索引灰度要求自动比较执行计划和写入分位延迟，积压告警要求计算有限恢复时间，回退开关要求演练可用。责任人和完成日期进入跟踪表，下一次相似变更前检查关闭状态。这样故事不是“我处理过一次告警”，而是展示从系统证据到工程防线的持续改进。

• 追问 1：为什么先限流而不是扩容？ 回答：数据库已饱和，扩容会增加锁等待、超时和重试。
• 追问 2：如何证明没有丢轨迹？ 回答：事件号与业务表逐条对账，并验证运单状态序号不倒退。
• 追问 3：真正根因是什么？ 回答：不只是索引错误，还包括变更前缺少峰值压测、计划基线和自动回退防线。
• 详细知识

30. 问题（事故闭环）：为什么消息积压清零后还必须做业务对账和复盘？

口述答案：积压清零只说明代理节点视角下没有可见待消费消息，不证明业务副作用正确。消费者可能先确认后处理导致静默缺失，失败消息可能进入 Dead Letter Queue（队列接口）（死信队列），超时和 Rebalance（再均衡）可能重复执行，迟到事件还可能让状态倒退。因此关闭事故前我会先验证基础设施稳定：生产和业务成功速率匹配，最老消息年龄回到目标，错误、重试、未确认和副本健康正常，并经过高低水位冷却窗口。随后按业务选择不变量：支付对渠道账单、内部流水和订单状态逐笔核对金额；WMS（仓储管理系统）对库存流水、事件号和可售/预占/已售关系；物流对运单事件序号和最终状态；异步导出对任务状态、文件行数与校验值。差异分为延迟、重复、缺失、非法状态四类，分别使用查询、幂等吸收、补发、冲正或人工审核收敛，所有操作有批次和审计。复盘再回答为什么监控没有提前发现、容量为何无恢复余量、降级为何未触发、变更为何穿透审查，并把改进变成有责任人、期限和验证方式的任务。最后通过相同故障注入验证告警、止血和恢复自动化有效，才算真正闭环。对账与复盘还要保留事故窗口快照、操作时间线和补偿批次，便于以后审计同一业务键为何变化。若发现总数闭合但个体不一致，优先保护资金和库存不变量，再修复投影。最终把人工步骤能自动化的部分转成巡检和演练，剩余高风险动作保留双人审批与明确回退方案。

• 追问 1：总数相等能证明一致吗？ 回答：不能，个体可能一条重复一条缺失，必须按业务键逐笔核对。
• 追问 2：复盘重点是追责吗？ 回答：重点是找出系统防线为何失效，同时明确必要的操作责任和改进责任。
• 追问 3：改进如何验收？ 回答：用故障注入重新触发场景，验证告警、自动降级、恢复时间和业务不变量。
• 详细知识

6. 复习清单

• 能在 1 分钟内写出积压、恢复时间、字节带宽和保留容量公式。
• 能说明为什么消费者扩容受分区、热点、顺序与下游四重约束。
• 能区分 Kafka（分布式日志消息系统）、RocketMQ（分布式消息队列）、RabbitMQ（消息队列）的积压与副本指标。
• 能对生产超时、消费者掉线、磁盘满、热点、重试风暴和外部依赖慢分别给出证据、止血、根因与验证。
• 能用生产 12,000 条/秒、消费 8,000 条/秒的案例算出 240 万积压及恢复方案。
• 能把 WMS（仓储管理系统）、支付、物流、Runner（执行器）、IoT（物联网）和异步导出的业务不变量讲清。
• 能明确积压清零不等于事故结束，最终必须以业务事件和权威状态对账。