一、什么是消息队列？
消息队列，一般我们会简称它为MQ(Message Queue)，它本质就是一个消息转发器，一个不赚差价的“中间商”。
先说一下队列，应该都很熟悉，队列 = 一种按顺序排好队的数据结构。
- 把数据放到消息队列叫做“生产者”
- 从消息队列里边取数据叫做“消费者”
二、为什么要用消息队列？
主要解决了三个问题
- 异步
- 解耦
- 削峰
1.首先异步，在我们平常接口和方法调用的时候，需要一个一个按顺序调用，那对于一个重要的业务功能来说，可能调用的链路特别长...
链路长了就慢了...
其实有些流程我们可以同时执行，我去执行保存支付明细的同时也可以执行保存会员卡积分信息，然后加个会员等级，加个业绩什么的，是吧。
正常的流程我们似乎没办法同时执行，怎么办？异步
收银后把结果推送到消息队列中，下游其它服务订阅这个消息，收到消息执行加积分，加等级，加业绩...
2.解耦，像下图中收银订单流程，业绩、库存、欠款...这么多业务，每增加一个都需要改动代码，而且其中只要有一个出现报错，其它流程就无法正常流转，那使用体验是不是很差？
而且排查问题的时候，一个方法调用一个方法，都得找到自闭好么。
用了消息队列，耦合问题迎刃而解。
3.削峰，我们都知道，服务器有容纳请求的一个上限，redis、mysql，各自的容忍度不同，那如果全部一起接收，那肯定会把服务器打挂。
redis能来十万，mysql两千就GG...
咋办？把请求内容丢消息队列中呗，每次消费1000条，慢慢的保存到数据库中，这样，系统就能平稳的抗住了短时间的高峰请求！
三、用消息队列会产生什么问题？
消息队列是用爽了，那问题也随之而来，我们都知道，技术是把双刃剑，解决问题的同时也会产生很多问题，那我们攻城狮这个岗位就是解决问题的。所以，遇到问题不要方，一个个解决。
可能会出现哪些问题呢？
- 消息丢失
- 重复消费
- 消息积压
1.消息丢失有很多情况：
怎么解决？
2.同一条消息重复消费，可能导致很多问题产生，比如加积分，100加了十次...，扣款扣了十次...
我们可以给消息加上唯一的编号，消费的时候进行判断，如果用了就剔除这条消息，没用就继续使用！
3.消息发出去了，消费者挂了，mq队列中积压了大量的数据，怎么办？
其实除了以上问题，可能还会出现很多问题。
数据一致性（这么多个系统，如果某个系统出问题，其它系统数据也得回滚，分布式事务）
