1. 故障背景与业务影响
凌晨 02:37，某核心交易系统监控平台触发 RabbitMQ 节点内存水位告警（memory_alarm），集群中两个主节点先后进入“内存满”状态，导致所有生产者连接被强制阻塞（blocked）。故障持续约 18 分钟，期间订单支付接口超时率从 0.2% 飙升至 67%，最终影响约 1.2 万笔订单的支付成功率。
1.1 故障时间线
| 时间点 | 事件 | 关键指标 |
|---|---|---|
| 02:37:12 | 节点 rabbit@node1 触发内存告警 | 内存使用率 92% → 100% |
| 02:37:45 | 生产者连接被阻塞，消息入队失败 | 连接阻塞数 0 → 340 |
| 02:38:30 | 节点 rabbit@node2 同步触发告警 | 集群双节点均进入 alarm 状态 |
| 02:42:00 | 订单支付超时率开始陡增 | 超时率 0.2% → 67% |
| 02:55:10 | 运维手动执行清队列 + 重启节点 | 内存回落至 45% |
| 02:55:40 | 生产者恢复，消息开始正常投递 | 支付超时率逐步恢复 |
1.2 业务影响量化
- 订单支付失败：故障窗口内共产生 12,347 笔支付请求，其中 8,276 笔超时或失败，支付成功率仅 33%。
- 消息堆积：故障解除时，核心队列“order.pay.queue”堆积消息量达 186 万条，峰值入队速率 4,200 msg/s。
- 下游补偿压力：支付网关重试队列瞬时积压 23 万条，导致后续 30 分钟内数据库连接池被打满。
- 资金对账延迟：因部分支付成功但回调丢失，次日对账差异单增加 340 笔，需人工介入处理。
关键结论：本次故障并非突发流量洪峰，而是内存索引膨胀 + 惰性队列配置不当引发的渐进式内存泄漏，最终在凌晨低峰期触发阈值。
1.3 系统架构与故障链路
下图展示了故障发生时核心交易系统的消息链路及各组件状态：
1.4 故障等级与响应
- 故障等级：P0（核心交易链路中断，影响资金流水）
- 发现方式：Prometheus + AlertManager 凌晨 02:37:12 推送告警，值班人员 02:38:00 确认。
- 应急动作：
- 02:40 暂停非核心消费者，释放队列读取能力。
- 02:45 手动将堆积消息迁移至备用队列（lazy 模式）。
- 02:55 重启故障节点，内存水位恢复正常。
- 恢复时间：18 分钟（02:37 → 02:55）