趣讲消息队列，搞懂消息队列到底是个啥

​ 今天想谈谈消息队列，洪爵大概可以猜测到大家听到消息队列有什么反应，大致可以分为以下几类人。

​ 第一类人，懵懵懂懂，刚大学接触编程，还没使用过消息队列，甚至以为消息队列就是代码里面去new一个List之类的；第二类人，听过消息队列，了解过消息队列，但具体是什么还不太了解，只知道一说到消息队列，立马脑中就出现三组词语，削峰、异步、解耦；第三类人，使用过消息队列，对它有一定的认识，但不知道为什么要这样设计，消息队列有怎样的前世今生，如何演变到现在这个模样？**第四类人，已经足够了解消息队列了，看本篇文章就是当做回顾和复习。**你是属于哪一类人呢？不管你对消息队列有多少了解，看完本篇文章，相信你会有所收获。

​ 消息队列是什么？我们到底为什么要用消息队列？真的只是看起来逼格高，因为用而用吗？当然不是了，一个技术的出现，往往是为了解决某种痛点，我们就从这个痛点出发，看看消息队列到底是为了解决什么问题而诞生的。

​ 相信大家在工作前，或者工作中接触到单体机的次数会更多一些，不管什么业务都一股脑的塞进一个系统里，这种情况接触到消息队列的场景会比较少。但随着业务增长，体量上来了，单机系统难以维护，也承载不了增长的并发量，就需要把原来的单体应用拆分成多个服务。比如说牛客网使用分布式架构，把原来的单体系统拆分成用户服务，题库服务，求职服务，讨论区服务等等，每个分布式节点又有集群保证高可用。

​ 那尽管在这样的微服务架构下，如果某个核心业务的并发量实在过大，系统也扛不住的。比如说淘宝、淘特、拼多多、京东等电商场景里的支付场景等，你在某宝下单并支付，调用了支付服务，完成支付后，还需要更新订单的状态，这个时候需要调用订单服务，那我们平常也下过单，除了简单完成这些操作外，还会给你相应的积分；商家也会收到下单的消息，并且给你发送旺旺消息确认订单无误；同时你也可以查到你的物流状态；并且系统内部为了给你推荐更适合你的商品，会根据你的下单做个类似的推荐等等，我说的这些是当我们下单后，肉眼能够察觉到系统所做的动作。

​ **一个支付的动作如果还需要调用这么多服务，并且等待它们的响应成功，最后再告诉给用户你支付成功了，用户整个在系统的体验会很不好。**想象一下，假设请求服务+处理请求+响应一共需要50ms，我们上面列举的场景：支付服务，订单服务，积分服务，商家服务，物流服务，推荐服务，一共就需要300ms。

​ 这还是在所有服务都调用成功的情况下计算出来的时间，比如支付服务调用积分服务失败了，重试也失败了（可能由于积分服务短暂时间的不可用），这个时候可能面临的是支付失败。但支付服务会觉得很委屈，明明我只管的是支付呀，你积分服务失败了，影响某宝GMV可是大事啊，说到底是系统没有解耦开来。这还是没有考虑并发量比较高的场景下，系统一次性处理不了这么多请求，整个响应给用户的时间就是成倍的增长，甚至因为链路太长导致系统宕机。

​ 试想一个在你看来简单支付的功能，都需要等待系统响应个半天，用户体验会好吗，用户会想是不是这个系统不行了，某电商平台好像不会这样啊。这个时候就给了竞争对手机会。

​ 所以有没有一种技术，可以解决这种问题，支付服务只管你支付订单，积分服务，物流服务等虽然我也要考虑，但不能影响到支付服务是否成功。

​ 这个时候为了解决这种痛点，消息队列就诞生了。你系统没有解耦开来是吗，我给你解耦，你调用其他服务是同步是吗，我给你异步，你的并发量太高是吗，我帮你把请求先存储起来，当你能处理的时候，你再从我这里拿。消息队列的诞生就是为了更好的实现削峰、异步、解耦。

​ 那到底啥是消息队列呢，其实有一个很生动形象的例子。大家都经历过考试，不管是在小学、初中、高中还是大学。简单来说，围绕着消息队列一共有三个方面的人，生产者、消息队列、消费者。生产者就是学生，学生去生产消息，消息指的就是你答的试卷。你做完了试卷（管你做没做完），
​ 就需要提交给监考老师，监考老师相当于一个服务器，这个服务器里面以某种特定的方式存储消息，也就是消息队列，监考老师收了你的试卷但不会现场批改（其实还真有现场批改过的…），你提交试卷给老师，老师会对你点点头，表示它已经接收到了你的答卷，这个时候你就放心的离开了，相当于你生产消息，放进消息队列成功。消费者在这里指的是批改试卷的老师，老师会从消息队列中（监考老师会把一叠试卷交给批卷老师）获取一份消息（试卷）进行消费（批改），还没有被批卷老师消费的消息就会保存在消息队列中，等待批卷老师的消费。

​ 所以消息队列其实就相当于一个中转站，我不管你什么时候消费消息，消息我已经发出去放在这了，你想什么时候拿就什么时候拿。就像快递一样，每次上门送快递，总会遇到失败的情况（不在家等情况），如果把快递放在快递柜里，整个送货/取货就解耦开来。

举了两个例子，想必大家已经了解消息队列到底是个什么东西。

​ 之前提到的下单支付场景中，为了应对高并发场景，把消息存在消息队列中，是为削峰、
消费者和生产者互不感知，我把消息放进消息队列里，谁去消费我并不关系，是为解耦、
生产者不需要等待消费者消费才返回成功（支付后，不需要管是否加了积分等），从同步变为了异步。
​ 好了，看完这边文章，你或许已经大概了解消息队列到底是个什么东西。那当我们学会怎么使用的时候，就应该去探究它的原理，洪爵接下来将带领大家遨游RocketMQ的海洋，准备好了嘛？

​ 愿每个人都能带着怀疑的态度去阅读文章并探究其中原理。

道阻且长，往事作序，来日为章。

期待我们下一次相遇！