案例分析

案例一：系统崩溃

首先大家跟着我想象一下下面的这个的场景，有一天晚上晚上我们上完课，回到宿舍，想着新出的游戏机，但又摸了摸钱包，太贵了买不起，这个时候你突然想到，今天抖音直播搞活动，瞬间你掏出了手机打开抖音搜索，找到直播间以后，你点开了心心念念的游戏机详情页，看到价格只要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，在目前互联网应用中消息队列中间件基本上成为标配。

业界消息队列对比

• Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
• RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
• Pulsar：是下一代云原生分布式消息流平台，集信息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
• BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群