什么是消息队列？什么场景用消息队列？用消息队列会产生什么问题？

一、什么是消息队列？

 

消息队列，一般我们会简称它为MQ(Message Queue)，它本质就是一个消息转发器，一个不赚差价的“中间商”。

先说一下队列，应该都很熟悉，队列 = 一种按顺序排好队的数据结构。

• 把数据放到消息队列叫做“生产者”
• 从消息队列里边取数据叫做“消费者”

二、为什么要用消息队列？

主要解决了三个问题

1. 异步
2. 解耦
3. 削峰

1.首先异步，在我们平常接口和方法调用的时候，需要一个一个按顺序调用，那对于一个重要的业务功能来说，可能调用的链路特别长...

链路长了就慢了...

其实有些流程我们可以同时执行，我去执行保存支付明细的同时也可以执行保存会员卡积分信息，然后加个会员等级，加个业绩什么的，是吧。

正常的流程我们似乎没办法同时执行，怎么办？异步

收银后把结果推送到消息队列中，下游其它服务订阅这个消息，收到消息执行加积分，加等级，加业绩...

2.解耦，像下图中收银订单流程，业绩、库存、欠款...这么多业务，每增加一个都需要改动代码，而且其中只要有一个出现报错，其它流程就无法正常流转，那使用体验是不是很差？

而且排查问题的时候，一个方法调用一个方法，都得找到自闭好么。

用了消息队列，耦合问题迎刃而解。

3.削峰，我们都知道，服务器有容纳请求的一个上限，redis、mysql，各自的容忍度不同，那如果全部一起接收，那肯定会把服务器打挂。

redis能来十万，mysql两千就GG...

咋办？把请求内容丢消息队列中呗，每次消费1000条，慢慢的保存到数据库中，这样，系统就能平稳的抗住了短时间的高峰请求！

三、用消息队列会产生什么问题？

消息队列是用爽了，那问题也随之而来，我们都知道，技术是把双刃剑，解决问题的同时也会产生很多问题，那我们攻城狮这个岗位就是解决问题的。所以，遇到问题不要方，一个个解决。

可能会出现哪些问题呢？

1. 消息丢失
2. 重复消费
3. 消息积压

1.消息丢失有很多情况：

怎么解决？

2.同一条消息重复消费，可能导致很多问题产生，比如加积分，100加了十次...，扣款扣了十次...

我们可以给消息加上唯一的编号，消费的时候进行判断，如果用了就剔除这条消息，没用就继续使用！

3.消息发出去了，消费者挂了，mq队列中积压了大量的数据，怎么办？

其实除了以上问题，可能还会出现很多问题。

数据一致性（这么多个系统，如果某个系统出问题，其它系统数据也得回滚，分布式事务）

可用性（系统本身可能没有问题，MQ挂了，积分不加了，扣款不扣了？祭天吧）

...