zoukankan      html  css  js  c++  java
  • 消息积压过多了怎么办

      消息积压在MQ中是一件很正常的事,但是积压过多了,就可以会导致消息的丢失,甚至系统的崩溃。那我们从事前的预防和事后的处理两个方面去解决。

    一、事前预防

      我们如何预防消息积压呢,一般就是批量和增加并发这两个方法,发送端和消费端都可以从这两个方面去处理。

      1.1 发送端

      1.批量。比如一次从数据库中批量查出数据发送mq。

      2.增加并发。多线程并发处理

      1.2 消费端

      我们常用的一个做法是收到一个mq消息后,直接放入一个内存队列中,返回mq确认,后台再多线程并发处理。虽然消费的速度加快了,但是这里有一个问题,此时消费端宕机了,内存队列的数据就会丢失,这条消息就会丢失了。所以我们必须处理完消息才能给mq发送消息确认。

      增加消费端consumer的实例数量的同事,必须扩容主题中队列的数量,确保consumer的是实例数和队列数是相等的。至于为什么必须扩容队列数量,因为在同一个队列中是单线程处理的,如果队列数量没有增加,那么即使增加了consumer的数量,消费的速度也没有增加。  

    二、事后处理

      如果生产上出现了消息积压过多,我们又该如何处理呢?必须先将积压的消息快速消费掉后,再慢慢找原因。

      一般消息积压无非两个原因,发送过快或者消费过慢,我们可以通过mq的监控确定是那个端出现了问题。

      1.发送过快。消费端的速度赶不上发送的速度。

        1.1 紧急扩容消费端实例,快速消费消息。

        1.2 如果没有足够的服务器扩容,系统降级,将一些不重要的任务关闭,减少发送端的数据量,优先处理积压的消息。

      2.消费过慢。检查日志查看错误原因,打印堆栈信息等查看是否发生思索或者等待某些资源导致消费很慢。

      3.如果发现发送和消费的速度和往常差不多,需要检查日志是否有消息是否消费失败了,导致一直反复消费。

  • 相关阅读:
    正则表达式匹配可以更快更简单 (but is slow in Java, Perl, PHP, Python, Ruby, ...)
    ++i? i++? i+=1? i=i+1? 何必纠结?
    数独题的生成与解决方法
    VIM常用设置
    我的“MIT Challenge”
    NDK开发之javaVM
    十二月寒冬
    Linux epoll 笔记(高并发事件处理机制)
    Linux之我见
    半夜惊醒
  • 原文地址:https://www.cnblogs.com/ITyannic/p/12244360.html
Copyright © 2011-2022 走看看