这是我参与「第三届青训营 -后端场」笔记创作活动的第2篇笔记
什么是消息队列？
消息队列消息队列，顾名思义消息队列本身就是一种队列，队列这种数据结构，想必在座的各位应该都烂熟于心了，在此不再赘述，那“消息”呢？这里的“消息”在实际的应用场景中通常是一端对另一端发出的各种各样调用服务的请求，也可以只是单纯的文本内容，还可以是非常复杂的对象信息，那消息队列也就不难理解了，它即是一种用于收发“消息”的“容器”。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。
消息队列干嘛的？
异步
考虑场景如下：
对于以上场景，如果不采用消息队列，那么用户在发起订单后，势必会等待服务器对于请求处理的响应，这些请求包括但不限于修改订单状态、修改库存记录、通知商家等等，这些处理通常会有数百毫秒的耗时，对于用户来说，其实是比较不好的体验，特别是当服务器遇到流量聚集的情况，可能还会还会导致响应失败……
那这样的流程该怎么优化呢？其实不难发现，操作链路上很多的操作是可以同时进行的，比如修改库存和修改订单状态，这二者并没有直接相关性，因此消息队列就派上用场了，它让用户不再傻傻地等待服务端返回的响应，用户只需要发出相应的请求，剩下的交给消息队列就好了
削峰
考虑场景如下：
当某一时间段的请求量剧增的时候，对于处理请求的服务器也会在这时面临庞大流量的压力，一旦承受不住这股压力，服务器也许就嗝屁了，毕竟服务器的“胃口”也有限，人家一次只能吃一碗，你让人家必须一次吃一桶，那人家咋办嘛……
因此，加上消息队列，就服务器的“胃口”进行匹配，对请求数量进行管控，将适度的请求量发给服务端，让它工作在它的舒适区，这样才可以彼此安好不是:D
解耦
考虑场景如下：
对于以上场景，当负责存储的服务器宕机了之后，整个请求的链路都会失效甚至阻塞，这对于用户的体验来讲是非常糟糕的，因此为了解决类似问题，消息队列又可以派上用场了！
加上消息队列之后，将服务请求和服务处理解耦，因此即便负责处理的服务器宕机了，对于用户端的影响也会小很多
