https://blog.csdn.net/qq_44240587/article/details/104630567
核心的就是：解耦、异步、削锋
1、解耦
现有ABCDE五个系统，最初的时候BCD三个系统都要调用A系统的接口获取数据，一切都很正常，但是突然，D系统说：我不要了，你不用给我传数据了，A系统无奈，只能修改代码，将调用D系统的代码删除，这时候还没删除呢，E系统发送了请求，但是A系统这时候还没处理完D系统的请求，A系统卒！！！彻底崩溃。看下图↓↓↓↓↓↓↓↓↓↓↓
- 上述场景中，BCDE都需要用到A系统提供的数据，A系统跟其他四个系统严重耦合，需要时时刻刻考虑其他四个系统要是挂了怎么办，需不需要重新发送数据给他们，这个时候的A系统内心是崩溃的。
- 但是如果使用了MQ之后 ，A系统的数据只需要放到MQ里面，其他的系统想请求获取数据只需要去MQ里面消费即可，如果突然不想请求了，就取消对MQ的消费就行了，A系统根本不需要考虑给谁去响应这个数据，也不需要去维护代码，也不用考虑其他系统是否调用成功，失败超时等情况。详细看下图↓↓↓↓↓↓↓↓
总结：通过MQ发布订阅消息的模型，A系统就成功的跟其他系统解耦了。
面试技巧：你需要思考一下，在你自己的系统里面有没有类似的情况，一个系统或者模块，调用了多个系统或者模块，它们互相之间的调用非常复杂，并且维护起来很麻烦，但其实这个调用是不需要直接同步调用接口的，如果用MQ给它异步化解耦也是可以的，你就需要思考在你的项目里，是不是可以用MQ给它进行系统的解耦，可以自己组织一下语言回答。
2、异步调用
场景二，还是ABCD四个系统，A系统收到一个请求，需要在自己本地写库，还需要往BCD三个系统写库，A系统自己写本地库需要3ms，往其他系统写库相对较慢，B系统200ms ，C系统350ms，D系统400ms，这样算起来，整个功能从请求到响应的时间为3ms+200ms+350ms+400ms=953ms，接近一秒，对于用户来说，点个按钮要等这么长时间，基本是无法接受的，正常来讲互联网行业通常要求是响应时间200ms。详情如下图↓↓↓↓↓↓
- 一般的互联网企业，对于用户请求响应的时间超时了，所以上面的现象是不可取的
如果用了MQ，用户发送请求到A系统耗时3ms，A系统发送三条消息到MQ，假如耗时5ms，用户从发送请求到相应3ms+5ms=8ms，仅用了8ms，用户的体验非常好。
3、流量削峰
场景三，这次举个实例吧，也是近期发生的，我们都知道 ，2020年爆发的这场新冠病毒，导致各大线上商城APP里面的口罩被抢购一空，在这种情况下，JD商城开启了一场每晚八点的抢购3Q口罩的活动，每天下午三点进行预约，晚上八点抢购，从JD商城刚上线这个活动，我连续抢了近一个周，也算是见证了一个百万并发量系统从出现问题到完善的一个过程，最初第一天，我抢购的时候，一百多万预约，到八点抢购估计也能有百万的并发量，可是第一天，到八点我抢的时候，由于并发量太高，直接把JD服务器弄崩了，直接报了异常，可能JD在上线这个活动的时候也没能够想到会有那么高的并发，打了一个猝不及防，但是这只是在前一两天出现报异常的情况，后面却没有再出现异常信息，到后来再抢购只是响应的时间变得很慢，但是JD系统并没有崩溃，这种情况下一般就是用了MQ（或者之前用了MQ，这次换了个吞吐量级别更高的MQ），也正是利用了MQ的三大好处之一——削峰。
- JD系统每天0—19点，系统风平浪静，结果一到八点抢购的时候，每秒并发达到百万，
假设JD数据库没秒能处理1.5w条并发请求（并非实际数据，主要为了举例）,到八点抢购的时候，每秒并发百万，这直接导致系统异常，但是八点一过，可能也就几万用户在线操作，每秒的请求可能也就几百条，对整个系统毫无压力。
如果使用了MQ，每秒百万个请求写入MQ，因为JD系统每秒能处理1W+的请求，JD系统处理完然后再去MQ里面，再拉取1W+的请求处理，每次不要超过自己能处理的最大请求量就ok，这样下来，等到八点高峰期的时候，系统也不会挂掉，但是近一个小时内，系统处理请求的速度是肯定赶不上用户的并发请求的，所以都会积压在MQ中，甚至可能积压千万条，但是高峰期过后，每秒只会有一千多的并发请求进入MQ，但是JD系统还是会以每秒1W+的速度处理请求，所以高峰期一过，JD系统会很快消化掉积压在MQ的请求，在用户那边可能也就是等的时间长一点，但是绝对不会让系统挂掉。
消息队列的缺点：
虽然好处挺多，但是万一MQ挂掉了呢，那样你系统不也就挂掉了
系统复杂程度提高
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；
4、MQ重复消费问题，以及怎么解决？
4.1、重复消费产生
1、生产者：生产者可能会重复推送一条数据到MQ中，比如Colltroller节课被重复调用了两次，没有做节课幂等性导致的。
2、MQ：在消费者从MQ中获取了数据，并准备给响应ACK消息到MQ时，这时MQ突然挂掉了，导致MQ以为消费者还未消费该数据，MQ恢复后再次推送了该条信息，导致重复消费。
3、消费者：消费者已经消费完信息，正准备但是还未响应给MQ信息时，此时消费者挂了，服务重启后，MQ以为消费者还未接收到该消息，再次推送了该条消息。
4.2、解决方法：
1、使用数据库唯一键约束
缺点：局限性很大，仅仅只能用在我们数据新增场景，并且性能也比较低。文章来源：https://www.toymoban.com/news/detail-850025.html
2、生产者发送消息的时候带上一个全局唯一的id,消费者拿到消息后，先根据这个id去redis里查一下，之前有没消费过，没有消费过就处理，并且写入这个id到redis，如果消费过了，则不处理。文章来源地址https://www.toymoban.com/news/detail-850025.html
到了这里，关于MQ消息队列详解以及MQ重复消费问题的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
