mq里每天有几百万数据堆积，在高可用场景里怎么有限解决这问题？

近期，好多网友提起mq积累的问题，也不知道他们是工作场景中遇到实际问题，还是说在面试过程中遇到这样的问题，因此想知道这个问题答案。不管是哪种情况吧，那么接下来我就以自然语言的方式与大家轻松的来讨论一下mq相关的东西吧。

什么是mq?

什么是mq呢？其实相比mq这个叫法，国内好多朋友更喜欢叫消息队列，既然是这样的话，那么想必mq一定是 message queue的缩写了，通常mq的工作方式都是委托模式，是一个生产者消费者的模式，一般顺序执行的程序都是需要耗时的，如果改用使用消息队列的的话，就可以将一些具体处理业务的程序省略掉，直接委托给消息队列，然后继续往下执行其他部分， 然后再委派另一个进程去处理消息队列上的内容， 因此这个过程就可以理解为生产者与消费者，生产者只负责往消息队列中添加内容，而消费者则负责处理消息队列中的内容，一个负责让队列壮大，一个负责让队列减小。

mq用于解决什么问题？

那么mq用于解决什么样的问题呢？在什么样的场景下比较适合使用mq呢？以我个人的语言来说，mq适合于解决那些高并发非实时的问题，举个实际例子，比如发邮件，在程序中大量用到发邮件的话，大家都知道发邮件程序也是需要耗时的，你在运行业务程序时，运行到一半的时候，因为发邮件程序导致程序在那转了一小会才继续往后执行这显然是体验很不好的，如果再有一定并发的情况，那简直是没法看了，因此这种情况下就把mq用上，到发邮件的时候，不做实际发邮件动作，只是委托给消息队列，在队列上加入一条消息，然后就继续执行，这样的话就大大的增加了体验的流畅度。

为了更进一步说明，再举一个例子，就以电商的下单系统为例，做过电商的同学都知道，下单过程是相对复杂的过程，同时还用到了事务，要求数据无误差，要同时修改好多张表，比如有订单表，订单商品表，库存表，库存日志表，订单日志表等等，显然这些复杂的计算是非常耗时的，如果多个用户并发下单的话，显然对系统造成巨大的压力，如果实时计算的话也不太现实，再说了用户下单后，还要等待漫长的物流，用户是不会在乎延迟这几分钟或者说几秒钟不是么？用户下完订单后，程序只需要告诉用户下单成功就行，剩下的就把这部分计算业务委托给消息队列就OK了，然后让消费者慢慢去消费吧。

mq为什么会产生数据堆积？

那么接下来咱们就探讨一下，消息队列为什么会产生积累？在回答这个问题之前，我做一个我自己认为比较形象的比喻吧，我认为消息队列就是这样一个水池子，这个水池子有一个进水管，同时也有一个出水管，进水管负责往水池进水，出水管负责从水池往外排水，如果说进水管比较细，进水能力小，出水管比较粗，出水能力强的话，那么是不是水池永远都是空的，相反如果进水管很粗，进水能力很强，出水管很细，排水能力会差，那么是不是水池的存水量越来越多，一直到最后溢出，消息队列也是同样的道理，当生产者能力大于消费者的能力时（系统的并发访问过高），势必会造成数据积累，造成消息队列大量数据的堆积。

如何解决mq堆积问题？

上面已经对消息队列的应用场景有了说明，产生mq堆积的原因也十分明确了，那么mq的堆积问题如何解决呢？那答案自然是增加消费者的消费能力或者降低生产者的生产能力，当然降低生产者的生产能力显然是不现实呢，你总不能不让用户下单吧，用户的行为你无法管，因此要做的只能是增加消费者的消费能力了，比如增加多个进程同时消费处理，比如有3个生产者进程在生产，可以设置10个消费者进程来消费，或者更据具体的业务场景或者高效的处理语言与算法来增加消费者的消费能力，总之让生产者生产能力小于消费者的消费能力，通过这种方式就可以逐渐减少消息队列的数据堆积了。

另外，最后要说一点，mq只是一个技术模型，与哪种计算机语言无关系，大多数语言都可以实现mq，当然有的语言会更合适一点，对于mq的生产者代码与mq的消费者的代码，这两种代码完全可以是两种不同的计算机语言，在实际应用场景中，大家根据实际的业务情况使用最合适的语言，那么关于mq的讨论就暂时聊到这里了，接下来，关于mq你还有什么想说的继续在评论区进行留言。

以上所有图片均来之互联网

大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！(微信公众号：sssdhua )