这是我参与「第三届青训营 -后端场」笔记创作活动的第1篇笔记。
一.什么是消息队列
消息队列(MQ)，指保存消息的一个容器，本质是个使用队列来通信的转发器，包括发消息、存消息、消费消息的过程。但其需要支持高吞吐、高并发，并且高可用。它是大型分布式系统不可缺少的中间件，也是高并发系统的基石中间件。
二.消息队列的应用场景
2.1 应用解耦
传统做法业务系统直接调用存储服务系统，若存储服务系统发送崩溃或无法访问，业务就会失败，存在耦合关系。同时如果在业务下游进行扩充上游代码需要经常修改。这时引入消息队列，业务系统将消息写入消息队列，存储系统订阅消息队列。当存储系统发送故障，消息也能顺利写入。同时只要保证消息格式不变，消息发送和接收方不会相互影响完成解耦，更好接入更多下游服务。
2.2 流量削峰
当服务处理能力有限时，需要避免如秒杀场景带来的短期流量暴涨打垮应用系统的风险。这时候引入消息队列，可以存储大流量请求而每次只消费定量的消息从而削弱峰值流量减小系统负担。当流量高峰期过后，积压的请求可以慢慢处理而不至于丢失。
2.3 异步处理
解决链路耗时长尾问题，多个相关性不高的动作串行执行的话耗时久。引入消息队列可以实现异步，并行执行减少响应时间。如用户发起订单后，订单消息写入消息队列，下游系统异步读取消息队列消息，从而并行执行订单记录+1、库存记录-1及通知商家操作，提高响应速度。
2.4 日志处理
若服务器故障本地日志容易丢失，同时大型网站需要在页面上搜集大量用户的访问信息从而发现用户喜好及活跃情况。这时可以通过消息队列做日志处理，解决大量日志传输问题。log日志写入消息队列后日志处理服务消费日志消息，并将其写入ES这类的文本搜索引擎或大数据处理相关系统，便于存储与处理。
2.5 消息通讯
消息队列内置了高效的通信机制，可用于消息通讯。如实现点对点消息队列、聊天室等。
三.业界消息队列选型
- Kaffa：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色，适用于大数据领域的实时计算、日志采集场景。但存在运维成本高、负载不均衡问题。
- RockerMQ：阿里开源的分布式消息传递和流式数据平台，具有低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性的优点，在一些实时和事务性要求高场景如电商、金融中应用较广。
- Pulsar：下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性，被看作是云原生时代实时消息流传输、存储和计算最佳解决方案
- BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
