一.前言
消息队列是什么，我就不在这里给大家介绍了，写这篇文章的目的就是为了和大家聊一聊为什么使用消息队列，最近听几个朋友说面试的时候简历上写了MQ相关的技术点儿，结果面试的时候被面试官一阵连环炮提问给炸蒙了。连环炮式提问如下：
1.你们项目中是如何使用消息队列？
2.你们为什么要使用消息队列？
3.消息队列有什么优缺点？
4.kafka、activemq、rabbitmq、rocketmq都有什么区别？
5.你们项目是如何保证消息的高可用的？
6.如何保证消息不被重复消费？
7.如何保证消费的时候是冪等的？
8.如何保证消息的可靠性传输啊？
9.如何保证消息的顺序性？
上面的连环炮式的提问你能回答上几个呢？所以自己简历上写了就尽量都准备充分，不要把模棱两可的技术都写上去，不要觉得自己项目用了这个技术就是优势，如果自己没有了解清楚，那把这些技术点写入简历反而会成为自己的拖累，好了不多说了，我们就针对上面的提问来聊一聊消息队列吧！
二.为什么要使用消息队列
这个问题一般我们应该从消息队列的使用场景上来考虑，知道了消息队列适用哪些场景，自然就知道为什么要使用消息队列了！
1.解耦
场景介绍：用户下单后，订单系统需要通知库存系统，传统的做法是，订单系统调用库存系统的接口
消息队列应用场景-解耦
传统模式的缺点在于，如果调用库存系统失败的话那么用户下单也会失败，如果这种事情经常发生那么该网站会损失很多用户。
那么如果引入消息队列后是什么样呢？
消息队列应用场景-解耦
订单系统：用户完成下单后，将订单信息持久化到订单库，将相关信息写入消息队列，返回用户下单成功
库存系统：订阅下单的消息，获取到下单消息后，库存系统根据下单消息后进行库存操作
如果用户在下单时库存系统不能正常使用，也不会影响用户下单操作，因为下单后，订单系统将消息写入消息队列就不再关心后面的操作了，这样就实现订单系统和库存系统的解耦！
2.异步
场景介绍：比如那我们的机票订单结算系统来说，机票数据导入系统后需要和订单数据进行匹配，传统做法很简单，就是一堆流程放在一起串行执行就可以了！
消息队列应用场景-异步
用户上传机票文件耗时50ms，机票与订单匹配需要450ms，那么用户需要等待500ms，如果需要匹配的机票和订单量很大，那么时间会更长，这样对用户就不太友好了，极端情况下，如果用户上传的机票文件就10几条记录，但是匹配却很耗时，那么用户会疯的，就上传十几条记录你让我等这么长时间！
如果引入消息队列会是什么效果呢？
消息队列应用场景-异步
效果是不是很明显，用户上传文件很快就能得到响应，这样对于用户来说是非常友好，因为用户当前的关注点就是文件导入，至于你后续的匹配对于当前用户来说属于非必要的业务，像这样的需求我们就可以使用消息队列进行异步处理！
3.削峰
削峰及流量削峰，削峰这种场景一般在互联网企业遇到的比较多，对于内部项目很少能够用到消息队列这个功能。
场景介绍：秒杀或者赶上什么周年纪念日搞活动
消息队列应用场景-削峰
购票系统在平时能够支持2K/s的并发请求，但是赶上五一或者国庆假期的时候购票需求激增，这时用户有可能增加的5K/s的并发请求，大量请求涌入到后台数据库，可想而知数据的压力有多，如果数据库扛不住那么系统就可能崩掉，想想都吓人（不过我没有遇到过，哈哈哈哈）
那么消息队列能帮我们做什么呢？
消息队列应该场景-削峰
引入消息队列后，当大量请求涌入时，这些请求只是进入队列中，我们的购票系统按照数据最大能够承受的并发量从MQ中拉取请求进行处理即可
三.消息队列有哪些优缺点
优点就不在重复了，上面的使用场景就是消息队列的有点，那么消息队列有哪些缺点呢？
- 系统可用性降低了
系统引入的外部依赖越多，系统的可用性就越低
2.系统复杂性提高了
你以为只是简单加个MQ进来就行了吗？你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？后面一大堆问题呢，想想都头疼
3.一致性问题
你想想用户下单后，订单系统将消息写入队列后直接返回成功了，用户就真的以为这个购买是成功了，如果库存系统最终处理消息失败了怎么办，你这个数据就会出现不一致了
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉。
四.kafka、activemq、rabbitmq、rocketmq都有什么区别？
图片来自于网络如有侵权请联系作者删除
至于如何保证队列的高可用，如何防止重复消费等问题不是一两句话就能说清楚，有的需要结合实际业务进行说明，我会在后续的文章中进行说明，今天就先写到这里，记得关注【不爱八阿哥】一个热爱分享技术的码农
