这是我参与「第五届青训营 」伴学笔记创作活动的第9天，开始的开始除了准备学习相关的知识，还要规划好每天的日程。
有一段时间没总结笔记了，今天的收获主要是消息队列的原理与治理实践。
首先哪些场景会用到消息队列呢，先从三个问题入手。
在搜索商品时请求会先到搜索商品这个服务上，记录下搜索行为，记录商品然后进行计算分析，如果这个时候记录存储的数据库丢失了所有操作都动不了。
在抢购商品时，一堆人发起了订单请求，订单服务只能同时处理10个订单请求。
点击提交订单后，卡在页面一直转圈圈，等了半分钟后，终于抢到了，但是太慢了，体验极差。一通分析发现发起订单、库存记录-1、订单记录+1都很快，最后通知商家占用了绝大多数时间。
以上问题都可以通过消息队列来解决，对于问题一可以使用消息队列来解耦搜索服务与存储服务。对于问题二可以使用消息队列来削峰，一次只获取10个请求进行处理。对于问题三可以使用消息队列来异步处理库存记录-1、订单记录+1和通知商家。
消息队列是什么呢，本质上是一个保存消息的容器，但是需要支持高吞吐、高并发、并且高可用。
下面是业界常用的消息队列
Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场量下发挥较为出色。
RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广。
Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。
BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的鹿线业务场量，逐步替换掉对应的Kafka集群。
