消息积压治理与 MQ 架构设计：从生产事故到简化消息队列

凌晨告警显示订单事件已积压 300 万条，最老消息延迟 45 分钟。生产者速率没有下降，消费者错误率持续上升。此时最危险的动作，是不看瓶颈就反复重启消费者或无限扩容。

积压本质上是速率与容量问题：

积压变化速率 = 生产速率 - 消费速率

追平时间 = 当前积压量 /（消费速率 - 生产速率）

第二个公式只有在消费速率大于生产速率时才成立。例如积压 300 万条，生产每秒 5000 条，恢复后的消费能力为每秒 8000 条，净消化速度是每秒 3000 条，理论追平时间约 1000 秒。真实环境还要为重试、下游波动和流量增长留余量。

消息为什么会延迟和积压

消息延迟由排队时间、网络时间和处理时间共同组成。常见根因包括：

• 促销或批任务使生产速率突然上升。
• 消费者发布了慢查询、锁竞争、内存泄漏或线程池配置问题。
• 数据库、搜索引擎、第三方接口等下游不可用。
• 某条毒消息持续失败并阻塞有序队列。
• 分区或队列数不足，限制有效并行度。
• 消息键分布不均，单个热分区积压。
• Broker 磁盘空间、IO、网络或副本同步异常。
• 大量立即重试形成重试风暴。

先判断是哪一种故障

现象	判断线索	第一动作
生产突增	ingress 上升，消费者单条耗时稳定	限流/降级非核心生产，评估临时扩容
消费变慢	egress 下降，处理延迟或 GC 上升	回滚变更，定位慢调用和资源瓶颈
毒消息	同一消息重复失败，错误高度集中	隔离到死信，解除队头阻塞
下游故障	消费实例同时超时，下游告警	熔断并降低消费，避免重试风暴
并行度不足	消费者已满载，空闲实例无分配	增加分区/队列并规划数据迁移
Broker 磁盘压力	磁盘水位、刷盘延迟、保留数据异常	保护磁盘，扩容或清理可安全过期数据
网络异常	超时、重连、副本不同步同时出现	检查链路与可用区，避免盲目重放

先看“最老消息年龄”比只看消息条数更有意义：100 万条每秒可处理 50 万的消息可能很健康；1 万条已经延迟两小时的支付消息却很严重。

百万级积压的应急处理

推荐按以下顺序执行：

1. 保护业务：确定受影响的业务、数据时效和可接受丢失范围，建立统一事故指挥。
2. 止住增长：对非核心生产限流、降级或暂停；必要时关闭造成洪峰的批任务。
3. 隔离坏消息：将确定无法处理的消息转入死信或隔离 topic，避免卡住同一顺序键。
4. 恢复消费能力：回滚异常版本、修复下游、调优批量和并发，再在并行度上限内增加消费者。
5. 临时分流：原拓扑无法及时追平时，将积压转存到临时分片，由扩展消费者并行处理。
6. 校验结果：对订单、库存等关键数据做对账，确认幂等和重放没有制造重复副作用。
7. 恢复拓扑：逐步取消限流和临时通道，观察速率、延迟、失败率和下游水位。
8. 消除根因：补容量、告警、压测和演练，而不是只清空积压数字。

消费者数量并非越多越好。Kafka 同一消费组的有效并行度通常受 partition 数限制；其他 MQ 也会受队列数、有序键、prefetch 和下游容量限制。超过上限继续加实例，只会产生空闲、重平衡或更大的下游压力。

消息过期、死信与数据恢复

积压超过消息 TTL 或保留周期后，恢复消费能力也拿不回已删除的数据。上线前要定义：

• 消息业务有效期和 Broker 保留期是否一致。
• 过期消息是丢弃、进入死信、从业务库重建，还是人工补偿。
• 重放从哪个时间点开始，如何避免重复和覆盖新状态。
• 谁批准重放，怎样记录批次、操作者和影响范围。

如果消息已丢失，但数据库保留事实来源，可以按时间范围扫描业务表，重建事件写入专用恢复 topic。不要直接混入正常流量：恢复事件应带原业务键、恢复批次和幂等标识，并限制速率。

死信处理也必须闭环：告警、分类、修复、重放、验证、归档。长期无人处理的死信队列，只是把业务错误藏得更久。

容量规划与可观测性

容量规划至少包含：

每日存储量 ≈ 平均消息大小 × 每日消息数 × 副本数
峰值带宽 ≈ 峰值速率 × 平均消息大小 × 复制与协议开销
故障缓冲量 ≈ 峰值生产速率 × 计划容忍时长

平均值会掩盖大消息和热点键，应同时观察 P95/P99 消息大小与分区分布。磁盘还要预留索引、日志段、复制赶超、重平衡和安全水位空间。

最低监控集合包括：

• ingress/egress 生产和消费速率。
• lag 或 backlog，以及最老消息年龄。
• 单条与批次处理延迟。
• 重试率、死信率和连续失败次数。
• Broker 磁盘使用率、IO 延迟与网络流量。
• 副本同步、leader 变化和不可用分区/队列。
• producer confirm、consumer ack 和 offset 提交失败。
• 消费键倾斜、分区热点与重平衡次数。

告警应基于业务 SLO，例如“订单事件最老年龄超过 2 分钟且持续 5 分钟”，而不是只有“积压超过固定条数”。

如何设计一个简化版消息队列

系统设计题不要求现场复制 Kafka 或 RocketMQ。关键是从最小功能出发，逐步补齐可靠性、扩展性和运维能力，并明确取舍。

功能边界与消息语义

第一版支持：创建 topic、按 key 发送消息、分区内有序存储、消费组拉取、持久化消费进度、至少一次投递、保留周期和死信。消息包含：

messageId, topic, partitionKey, timestamp,
headers, payload, schemaVersion

先选择至少一次语义，要求消费者幂等。全局顺序、任意路由表达式和跨系统严格一次不进入第一版。

协议与元数据

客户端通过二进制或 HTTP/gRPC 协议执行 produce、fetch、commitOffset。元数据服务维护 topic、分区、副本、leader、消费组和权限信息。客户端缓存路由，失效后重新拉取，避免每条消息都查询元数据中心。

协议需要版本号、长度、校验和、请求 ID、超时和错误码。请求 ID 便于追踪结果未知的重试，消息 ID 用于业务去重。

顺序写日志与索引

每个分区使用追加日志：消息先进入内存批次，再顺序写入日志段。顺序 IO、批量、页缓存和减少数据拷贝有利于吞吐。

partition-0/
  000000000000.log
  000000000000.index
  000010000000.log
  000010000000.index

稀疏索引保存部分 offset 到文件位置的映射：先二分定位最近索引项，再顺序扫描少量记录。日志按大小或时间滚动，后台按保留策略删除旧段。消息体不为每个消费者复制，多个消费组只保存各自进度。

分区、副本与故障转移

topic 拆成多个 partition，路由函数将相同业务键映射到同一分区，得到局部顺序。每个分区有一个 leader 和多个 follower：生产与读取由 leader 处理，follower 复制日志。

leader 只有在满足确认策略后才向生产者返回成功。元数据层检测故障，并从足够新的副本中选举新 leader。副本提升规则必须避免为了短暂可用性选出数据落后的节点，否则会破坏已确认消息的安全边界。

分区数决定并行度，也影响文件、连接、选举和重平衡成本。扩分区后同一 key 的映射可能变化，需要一致性路由或业务版本方案，不能把扩容看成零成本操作。

消费进度、重试与死信

消费者按 partition 拉取批次，处理成功后提交下一条 offset。消费组协调器为实例分配分区；实例加入或离开时触发重平衡。

处理失败不能无限立即重试。系统记录尝试次数和下次可见时间，采用延迟重试；超过上限进入死信。对于有序消息，失败策略要在“阻塞后续保证顺序”和“隔离失败保证可用”之间明确选择。

扩容、限流与背压

Broker 增加节点后，通过迁移分区副本重新均衡存储和流量；消费者通过增加实例扩展到分区上限。系统还需要：

• producer 配额和单消息大小限制。
• consumer fetch 大小、并发和在途消息限制。
• Broker 磁盘水位保护和拒绝策略。
• 下游变慢时的消费降速、暂停与恢复。
• 批量、压缩和 linger 等吞吐/延迟调节能力。

背压必须沿链路传播。Broker 不能接收时，生产者应限速、降级或写入受控本地缓冲，而不是无界堆积在应用内存。

设计取舍

这个简化设计刻意不包含跨地域共识、复杂分布式事务、Schema Registry、分层存储和完整运维平台。若继续演进，还需要认证授权、配额、多租户、数据校验、控制器高可用、在线扩缩容、管理 API、审计与灾备。

系统设计的重点不是功能越多越好，而是能解释：追加日志为何适合消息存储，分区怎样换取并行度，副本如何定义确认边界，offset 为什么能支持回放，以及每项可靠性增强付出了什么成本。

面试回答要点

遇到消息积压，先用生产/消费速率和最老消息年龄判断增长趋势，再定位生产突增、消费者变慢、毒消息、下游故障或 Broker 资源问题。应急顺序是保护业务、止住增长、隔离坏消息、恢复并扩展有效消费能力、对账重放，最后补容量和演练。

设计 MQ 时，从协议、topic/partition、追加日志与索引、leader/follower 副本、消费组与 offset、重试死信、扩容背压和监控依次展开，并主动说明至少一次语义与局部顺序边界。

总结

积压不是简单的“消费者不够”，而是生产速率、有效并行度、单条耗时和下游容量共同作用的结果。成熟治理既要能快速止血，也要能从业务事实重建并安全重放数据。反过来看 MQ 的内部设计，追加日志、分区、副本和消费进度正是为了让吞吐、可靠性、回放和扩展之间形成可选择的平衡。

参考资料

• Advanced Java：消息队列专题
• Apache Kafka Documentation
• RabbitMQ Queues
• RabbitMQ Quorum Queues
• Apache RocketMQ：Consumption Retry