theme: github
highlight: a11y-dark
消息队列前世今生
1.1 案例一： 系统崩溃
首先大家跟着我想象一下下面的这个的场景，
看到新出的游戏机，太贵了买不起，这个时候你突然想到，今天抖音直播搞活动，打开抖音搜索，找到直播间以后，你点开了游戏机详情页，看到价格只要500。 这个时候我们分析一下，就我们上面这几步操作，在我们的程序背后，做了什么事情。
首先，请求会先到搜索商品这个服务上，并记录下你的搜索行为; 然后点击商品的时候，又记录了我们的点击商品，这些数据最终都会通过计算分析; 目的是为了下一次给你更准确的信息，这个时候问题来了，如果这个时候，负责记录存储的数据库被一个小哥删库跑路了。我们的所有操作都动不了了，这个时候我们应该怎么办，带着这个问题，我们继续往下看
1.2 案例二：服务能力有限
看到这个价格，你非常心动，商品即将在3分钟后开抢，这个价格必须要抢到啊！但此时在无数台手机的后面，藏着无数和你一样饥渴的同学，再来看看，后面的程序又做了哪些事情呢？
一堆人都发起了订单请求，可是公司给的预算不够，服务器的配置太弱，订单服务只能同时处理10个订单请求。这个时候我们又该怎么办呢。继续往下看
1.3案例三：链路耗时长尾
在我们点击提交订单之后，这个怎么一直转圈圈，卡在这个页面啊，等了半分钟后， 啊终于抢到了，不过这个app也太慢了，下次不用了。我们进一步看一下这次问题出在哪里了
一通分析，发现，库存服务和订单服务都挺快的，但是最后通知商家（30s）这一步咋这么慢，是不是还可以进行优化呀？
1.4 案例四：日志存储
在字节跳动的会议室里传出了悲伤的声音，因为刚刚有服务器坏掉了，我们的本地日志都丢掉了，没有了日志，我们还怎么去修复那些刚刚出现的那些问题，周围一片寂静，突然小张站出来缓缓的说了一句话，众人才露出了微笑准备下班离开，大家能猜到小张到底说的什么吗
1.1.1 案例一 解决方案
1.2.1
既然 服务器等其他原因导致 处理能力有限 ，我们可以把大量请求放到消息队列；每次拿10个处理
1.3.1
把“发起订单”请求放到《消息队列》，异步做那三个事，逻辑上在库存-1的时候就可以返回：下单成功，剩下的时候做商家通知，不用等他完事了再return 成功；
1.4.1
2.0 消息队列
2.1消息队列发展历程
消息中间件其实诞生的很早，早在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，在目前互联网应用中消息队列中间件基本上成为标配。
