消息队列在互联网的各种业务中发挥着至关重要的作用 ，但是在大学的课程中却少有提及，因此希望通过此次分享帮助大家去了解工业界比较成熟消息队列的底层原理、架构设计、以及它们的一些高级特性，让同学们在以后的学习中或者工作中更加熟练地去使用消息队列或者进行技术选型。

一、引入

案例一、系统崩溃

首先想象一下一个场景，有一天晚上我们上完课，回到宿舍，想着新出的游戏机，但又摸了摸钱包，太贵了买不起。这个时候你突然想到，今天抖音直播搞活动，瞬间你掏出了手机打开抖音搜索，找到直播间以后，你点开了心心念念的游戏机详情页，看到价格只要 500。这个时候我们分析一下，上面这几步操作，在程序背后做了什么事情。

首先，请求会先到搜索商品这个服务上，并记录下你的搜索行为。然后点击商品的时候，又记录了我们的点击商品。这些数据最终都会通过计算分析，目的是为了下一次给你更准确的信息。这个时候问题来了，如果这个时候，负责记录存储的数据库被一个小哥删库跑路了，我们的所有操作都动不了了，这个时候我们应该怎么办，带着这个问题，我们继续往下看

案例二、服务能力有限

看到一个价格，你非常心动，定睛一看，商品即将在 3 分钟后开抢，这个价格必须要抢到啊！但此时在无数台手机的后面，藏着无数和你一样饥渴的同学，时间快到了，心里面想着赶紧抢。我们再来看看，后面的程序又做了哪些事情呢？

一堆人都发起了订单请求，可是公司给的预算不够，服务器的配置太弱，订单服务只能同时处理 10 个订单请求。面对庞大的请求量，处理订单的服务一脸茫然。这个时候我们又该怎么办呢？继续往下看

案例三、链路耗时长尾

在我们点击提交订单之后，怎么一直转圈圈卡在这个页面啊，等了半分钟后终于抢到了，不过这个 app 也太慢了，下次不用了。我们进一步看一下这次问题出在哪里了

一通分析发现，库存服务和订单服务都挺快的，但是最后通知商家这一步咋这么慢，对于这个流程应该怎么优化来挽回这个暴躁的用户？

案例四、日志存储

在大家都抢到了自己心仪商品准备睡去的时候，在字节跳动的会议室里传出了悲伤的声音，因为刚刚有服务器坏掉了，我们的本地日志都丢掉了，没有了日志，我们还怎么去修复那些刚刚出现的那些问题？周围一片寂静，突然小张站出来缓缓的说了一句话，众人才露出了微笑准备下班离开，大家能猜到小张到底说的什么吗

到这里以上四个场景就都结束了，我们现在来看看，刚刚遇到的几个问题，分别应该怎么解决

• 系统崩溃
• 服务处理能力有限
• 链路耗时长尾
• 日志如何处理

案例一解决方案

面对存储行为服务崩溃的时候，解决方案：解耦

案例二解决方案

解决方案：削峰

案例三解决方案

解决方案：异步

案例四解决方案

什么是消息队列？

消息队列（MQ），指保存消息的一个容器，本质是个队列。但这个队列，需要支持高吞吐、高并发并且高可用

二、消息队列的前世今生

消息中间件其实诞生的很早，早在1983年互联网应用还是一片荒芜的年代，有个在美国的印度小哥Vivek就设想了一种通用软件总线，世界上第一个现代消息队列软件The Information Bus(TIB)，他 TIB受到了企业的欢迎，这家公司的业务发展引起了当时最牛气的IT公司IBM的注意，于是他们一开始研发了自己消息队列软件，于是才有了后来的wesphere mq，再后来微软也加入了战团。接近2000年的时候，互联网时代已经初见曙光，全球的应用程序得到了极大地丰富，对于程序之间互联互通的需求越来越强烈，但是各大IT公司之间还是牢牢建立着各种技术壁垒，以此来保证自己的商业利益，所以消息中间件在那个时候是大型企业才能够用的起的高级玩意。 但是时代的洪流不可逆转，有壁垒就有打破壁垒的后来者，2001年sun发布了jms技术，试图在各大厂商的层面上再包装一层统一的java规范。java程序只需要针对jms api编程就可以了，不需要再关注使用了什么样的消息中间件，但是jms仅仅适用于java。2004年AMQP（高级消息队列协议）诞生了，才是真正促进了消息队列的繁荣发展，任何人都可以针对AMQP的标准进行编码。有好的协议指导，再加上互联网分布式应用的迅猛发展成为了消息中间件一飞冲天的最大动力，程序应用的互联互通，发布订阅，最大契合了消息中间件的最初的设计初衷。除了刚才介绍过的收费中间件，后来开源消息中间件开始层出不穷，常见比较流行的有ActiveMQ、RabbitMQ 、Kafak、阿里的RocketMQ，以及目前存算分离的Pulsar，在目前互联网应用中消息队列中间件基本上成为标配。

到目前为止， 比较流行的MQ是以下几个