这是我参与「第五届青训营」伴学笔记创作活动的第 15 天
情景分析
消息队列在互联网的各种业务中都发挥着重要作用
案例一：系统崩溃
首先模拟一种场景，用户在抖音APP中打开直播商城，搜索想要的商品、点金查看商品香精
这个过程涉及到的操作有：
- 搜索直播间、App会将搜索行为记录下来，发送到数据库中进行记录存储、
- 其次点击商品，点击行为记录也会被App放松到数据库进行记录存储。
- 那么如果此时数据库发生了故障，或者机房被删库跑路了，整个流程都会出现问题
案例二：秒杀抢购
在相中一件商品后，商品将在3分钟后上架开抢，当到时间的时候，点击下单
这个时候，涉及到的过程有：
- 发起订单
- 处理订单（因为服务器性能，只能同时处理10个订单请求）
当面对庞大的百万级请求量，处理订单的服务该如何去处理捏？
案例三：链路耗时长尾
用户看到APP下单后一直在加载处理请求，也不清楚是否抢到了商品，但过了一会，看到订单中有了该商品的记录
这个过程有：
- 发起订单（5ms）
- 库存记录-1（100ms）
- 订单记录+1（100ms）
- 通知商家（30s）
着四个过程就是下单成功的处理时间，这样的流程对用户而言等待时间是非常长的，应该给予优化
案例四：日志丢失
因为在下单过程中，服务发生了故障，导致日志丢失，无法对问题进行定位与解决......
将上面的问题总结起来，可以笼统概括为，就是：
- 系统崩溃
- 服务处理能力有限
- 链路耗时长尾
- 日志如何处理
解决方案
解耦
在场景一中
用户搜索商品、搜索行为记录会将点击行为记录发布到消息队列
由存储服务向消息队列拉取请求并进行消费（生产者、消费者模型）
即便存储服务发生了故障，消息也会顺利发布到消息队列中，待服务回复后可继续处理
削峰
由于服务器性能有限，同时处理订单数有限，此时面对大量的请求
可以将其放入消息队列中，每一次取出少数的请求进行处理
异步
在案例三中
订单记录+1、库存记录-1、通知商家并不是在同一链路上的
用户下单后，可以将发起订单的请求推送至消息队列中，并告知用户操作是成功的
将后续的三个操作进行异步处理。
当用户看到操作成功的信息后，查看订单状态，会是一个正在处理的状态，处理完成后，用户刷新，可以看到处理成功或处理失败的状态更新。
日志处理
线上服务，日志可以推送到消息队列中，处理消息的组件（LogStash）对消息进行消费处理，最后将处理后的日志写在专门的搜搜引擎（如ES）中，再通过日志展示平台分析工具（如Kibana）进行处理
消息队列的定义
消息队列（MQ）：指保存消息的一个容器，本质是个队列。但这个队列，需要支持高吞吐，高并发，并且高可用。
