RocketMQ常见问题-RocketMQ消息堆积问题

RocketMQ消息堆积主要分为三个层次的问题：
       其一是producer生产速率过快，什么场景呢，比如producer故障，比如DOS攻击，比如业务高峰（超过企业预估的，例如                        12306订票，双十一下单，这些一开始的时候都有超过预期的情况）。
       其二是Broker消息堆积，比如Broker的性能瓶颈，Broker同步策略导致消息堆积等
       其三是Consumer本身已经拉取消息的堆积。consumer消息拉取超过一定量之后会暂停消息拉取，一方面是消费者本身消费                    能力的现在，另一方面是由于消费端过多的消息容易造成GC频繁。
一般情况下我们都可以通过限流和扩容来达到快速处理堆积的消息的目标。

          熟悉了消息堆积场景，我们还需要明确消息堆积的诊断，常用的工具包括producer发送速率监控，producer服务器性能监控（网络、CPU、内存等），broker性能监控（网络、CPU、内存，磁盘使用率，GC等），消费端消费速率，消费端consumer服务器性能监控（网络、CPU、内存、数据库、GC等）

1.判断是否存在消息堆积场景
       1.1producer发送消息的速率监控
       1.2producer发送消息的maxOffset与consumer消费消息的currOffset的差异值与给定的消息堆积数值告警值对比，如果差异   值大于数据告警值，则存在消息堆积，否则不存在消息堆积。
       1.3consumer消费消息的速率监控
2.消息堆积场景
        消息堆积的处理策略整体上说就是生产者producer限流，RocketMQ扩容，消费者consumer扩容，具体要根据监控指标来判断。通过监控差异值的变化我们可以获取消息堆积的具体场景，主要有这么几种情况。

2.1差异值呈现增大趋势--producer消息的发送速度大于consumer的消息消费速度
        prducer 发送速率增大，RocketMQ性能平稳，consumer消费速率增大。这种情况确实是业务量上涨，消费端消费能力不足照成的。此时需要可以采取的方式包括生产者限流紧急情况可以采用生产者熔断，消费者扩容的方式解决，具体要看业务的容忍度。比如说12306的抢票，我们紧急限流一段时间其实对整体业务影响不大；如果是双十一的下单期间，紧急限流下单业务，那么后果就不敢设想了，业务影响可能是以亿来计算的，这个时候就需要消费者扩容，提高消费者的消费能力。
备注：如果消费者扩容一段时间后消息阻塞没有明显的下降趋势，那么就必须采取生产者限流，因为此时的问题极大的可能性是消费者应用故障，比如程序故障，代码缺陷等情况导致的本身消费能力不够。具体表现就是物理你怎么扩容，服务端的服务器的性能消耗都很大。

2.2 如果差异值呈现平稳趋势或者下降趋势---producer消息发送速率等于consumer消息的消费速度
这种情况其实就是RocketMQ发挥优势的最佳场景之一-------消息削峰。可以谨慎观察，RocketMQ本身的服务性能，必要的时候可以对RocketMQ 进行扩容，提高消息堆积能力。

2.3差异值呈现增大趋势----producer的生产速率无明显增加，consumer的消费速率无明显增加。
这种情况基本上是可以确定是RocketMQ本身的故障照成的，比如Broker故障，比如Broker的GC频率过高导致消息推送，copy性能降低，集群内部网络故障，等等。此时主要是监控RocketMQ服务器性能。

2.4差异值呈现增大趋势----producer生产速率正常，RocketMQ服务器性能正常，consumer消费速率降低。

备注：个人经验总结，不一定场景和处理方法都不一定完成，欢迎大家提供更多的场景和解决方法。