如果出现消息积压场景你怎么处理？

比如1w/s写入mq，消费过程涉及到mysql调用，此时如果mysql宕机，网线断了反正短时间恢复不了，一直过去去了是四个小时了，那就是1w43600=一亿多条消息，mq服务器马上满了，此时你是系统负责人要怎么做？

考虑过程

  1. 发送端尽量减低消息进入，比如有活动页面暂时先把入口拿掉等等。
    1. 如果已经存在部分消息丢失（不管是因为长时间没消费），可以考虑通过日志之类人工恢复数据。
  2. 存储端考虑扩容，但是直接扩容有个问题就是存量消息依然在存量broker中，会继续增加：
    1. 相同topic建立新的更大的broker集群，比如分区是原来10倍。
    2. 开发一个新的临时consumer，功能是拉取积压topic并发送到节点。
  3. 继续推动consumer的恢复，也就是如果是rpc就推动二方解决，如果是mysql就推送dba恢复等等。
  4. 如果消费端已经恢复，由于积压已久要消费完存量消息依然会影响后续的用户请求，要考虑在原有基础上加快消费速度：
    1. 增加consumer，当然最多也就扩到分区的数量一致。
    2. 跳过消息，紧急情况下考虑丢弃部分消息，或参考上述方式把部分非核心消息打到另外一个队列等到低峰消费。
    3. 消费业务优化，取决于业务功能和原有代码。