为什么要使用消息中间件？
解耦、异步、削峰填谷
用我自己的话解释下这几个名词：购票和写入数据库的操作具有强耦合性，加入中间件后，实现了这两步操作的解耦（用户的购票消息先生成生产消息加入消息队列，然后交给后端应用进行消费，再由后端应用批量写入数据库）
用户提交订单后，系统要做一系列的事：扣减库存、生成订单、通知支付系统、发送购票成功的邮件，这些步骤依次调用，系统耦合度极高，如果一个环节宕机，整个购票流程就会卡住。那消息中间件如何实现解耦呢？当生成订单完成后，他只需要向队列发送一条消息，其他的服务各自从队列中拉取这条消息处理，这样就实现了各个环节的解耦。
异步其实就是用户提交订单，核心业务处理完后立即将用户返回，同时他将支付通知等消息异步地放入消息队列，用户无需等待这些环节的处理，可以被立即引导到支付页面。
高峰期，所有的购票请求被转化为"创建订单"消息，瞬间涌入高吞吐、高容量的消息队列 （如Kafka/RocketMQ）。后端的订单处理服务集群以一个相对稳定、且低于峰值的速度，持续地从队列中拉取消息进行处理。
对比一下常用的MQ
监控消息中间件常用的监控指标？
维度1：资源
- 磁盘使用率 内存使用率 CPU使用率 网络吞吐量 连接数
维度2：消息堆积与延迟
-
队列深度/消息堆积量
-
消费滞后（Consumer Lag）：消费者落后于生产者的消息数量
-
端到端延迟：从消息生产到消费完成的时间
维度3：吞吐性能
维度4：可用性与错误
-
生产速率（TPS/QPS）：每秒生产消息数
-
消费速率（TPS/QPS）：每秒消费消息数
-
节点状态：集群各节点的健康状态
-
错误率：生产/消费失败比例
-
重试队列/死信队列大小：处理失败的消息数量