1：应用解耦
1：原系统
缺点是耦合性太强，每个系统都要接入A，每次加入新系统是不是都需要修改代码？
2：应用解耦
需要被接入的系统A只需要将消息写入MQ即可，每个需要对接系统A的系统只需要订阅消息队列的消息，系统A的代码完全不需要修改。
3：举例
用户支付订单完成后，系统需要给用户发红包、增加积分、发货、物流等等行为，就可以通过这样的方式进行解耦。
2：异步处理
1：同步
一次请求耗时：3 + 300 + 200 + 600 = 1103ms
请求执行耗时较长有什么弊病：系统百分之80%的性能问题，都是慢查询导致
系统请求耗时较长 --- 吞吐量大幅降低 --- 系统资源占用陡升
特点：串行、逐个、同步
1. 系统A需要等待，BCD逐个执行完毕
2. 如果任意系统出错，那么真个流程就报错
3. 如果任意系统超时，那么整个流程就超时
2：异步
一次请求耗时：3 + 2 = 5ms
特点：异步、并行
前提：系统A返回的结果，并不依赖BCD处理的结果
MQ发送消息失败咋办？
3：流量削峰
系统A压测得出接口峰值处理能力500tps。
大多数系统，一定会有访问量的波峰和波谷。比如：12306、美团外卖...
如果在访问量大的情况下，所有请求都打到数据库上，那么再强悍的数据库也很难承受。
将多余请求积压在MQ中，系统A慢慢处理。把超过500峰值的流量削掉，填在空闲的其他低估时期，所以才叫削峰填谷。
消息队列会不会被打挂掉？
4：信息通信
1：概述
消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。
2：举例
IM 聊天
点对点消息队列。有基于消息队列的 RPC 框架实现，例如rabbitmq-jsonrpc ，用的人较少。
面向物联网的 MQTT 。阿里在开源的 RocketMQ 基础上，增加了 MQTT 协议的支持，可见 消息队列 for IoT 。
5：日志处理
1：如何使用
日志处理，是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。
日志采集client，负责日志数据采集，定时批量写入 Kafka 队列
Kafka，负责日志数据的接收，存储和转发
日志处理Server：订阅并消费 Kafka 队列中的日志数据，将日志信息进行分析，可视化展示等...
2：最常见日志解决方案：ELKK
Elasticsearch ：实时日志分析服务的核心技术，一个 schemaless ，实时的数据存储服务，通过index 组织数据，兼具强大的搜索和统计功能。
Logstash ：对接 Kafka 写入的日志，做日志解析，统一成 JSON 输出给 Elasticsearch 中。
Kibana ：基于 Elasticsearch 的数据可视化组件，超强的数据可视化能力是众多公司选择 ELK
stack 的重要原因。
Kafka ：接收用户日志的消息队列