消息堆积（高可用）

一、产生原因

1. 生产消费速率不匹配

• 生产者速率过快：生产者持续以高吞吐量发送消息，超过消费者处理能力（生产者产生太快）
• 消费者处理能力不足：消费者处理逻辑复杂、效率低下或资源不足（生产者产生消息太快）
• 突发流量冲击：业务高峰期或促销活动导致消息量骤增（生产者产生消息太快）

2. 消费者端问题

• 消费者宕机或下线：消费者实例崩溃或未正常运行（有消费者宕机）
• 消费逻辑阻塞：消费代码中存在同步阻塞操作（消费消息时间太长）
• 消费线程不足：消费者线程池配置不合理，无法并行处理足够消息（默认的线程数不够）
• 网络问题：消费者与 Broker 间网络延迟或中断（消费者不能消费消息）

3. 系统配置问题

• 队列数量不足：Topic 配置的队列数太少，无法充分利用消费者并行能力（一个队列对应一个消费者，队列少，使用的消费者就少）
• 消费位点管理不当：消费位点未正确提交或回滚（消费了消息，但未更新点位）
• 消息过滤效率低：Tag 或 SQL 过滤条件复杂，增加处理负担（官方说复杂的 sql 方式 tag 过滤比较耗性能）

4. 业务逻辑问题

• 死循环消费：消费逻辑中对某些消息反复处理无法跳出（业务中自循环或顺序消息消费失败）
• 异常处理不当：消费失败消息未正确处理导致重复消费（同上）
• 依赖服务不可用：消费逻辑依赖的第三方服务不可用

二、带来的问题

1. 系统性能问题

• Broker压力增大：堆积消息占用大量内存和磁盘空间
• 磁盘IO升高：频繁读写堆积消息导致磁盘性能瓶颈
• GC频率增加：大量消息对象导致JVM频繁垃圾回收

2. 业务影响

• 消息处理延迟：新消息需要等待堆积消息处理完毕
• 数据不一致：业务状态因消息延迟而不同步（比如超过半小时未支付的订单自动失效的业务）
• 用户体验下降：用户请求响应变慢或超时

3. 运维问题

• 监控告警频繁：堆积阈值不断被触发
• 扩容成本增加：需要临时增加资源应对堆积
• 恢复时间变长：堆积越严重，恢复正常所需时间越长

4. 极端情况风险

• 磁盘写满：消息持续堆积可能占满磁盘空间
• 服务不可用：严重堆积可能导致Broker宕机
• 消息丢失：磁盘写满可能导致新消息无法存储

三、解决方案

1. 容量规划与设计

• 事先合理评估吞吐量：根据业务特点评估峰值和平均消息量（从而决定消费者数量、Topic 消费者数量、消费者线程数等）
• 设计弹性架构：支持消费者水平扩展（分布式集群部署Broker）
• 队列数量规划：队列数=消费者实例数×每个实例线程数

2. 消费者优化

• 增加并行度：

  // 示例：设置消费者线程数
  DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumer_group");
  consumer.setConsumeThreadMin(20);
  consumer.setConsumeThreadMax(64);
  

• 优化消费逻辑：

  • 避免同步阻塞操作
  • 使用异步处理和非阻塞IO
  • 批处理优化

• 实现快速失败：对非关键路径逻辑设置超时（业务上自行实现）

3. 监控与告警

• 设置堆积阈值告警：

  # RocketMQ控制台监控指标
  msgDiff = maxOffset - consumerOffset
  

• 实时监控面板：监控消费TPS、延迟等关键指标

4. 应急处理机制

• 调整消费者（原因已知或不想分析原因，就想出现问题及时解决）：

  • 增加消费者组订阅已经阻塞的 Topic（多个消费者会消费同一个队列的消息，要处理好幂等）

  • 订阅已经阻塞的 Topic 的消费者组下的消费者增加线程数量（需衡量服务器性能是否允许）

• 动态扩容：

  • 快速增加消费者实例
  • 临时提升消费者规格（CPU/内存）

• 降级策略：

  • 跳过非关键消息
  • 批量丢弃可补偿消息

• 死信队列：将处理失败消息转入死信队列后续处理

5. 配置优化

• 调整拉取批量大小：

  consumer.setPullBatchSize(32);  // 每次从Broker拉取的消息数
  

• 优化重试策略：

  // 设置重试次数
  consumer.setMaxReconsumeTimes(3);