分布式消息中间件RabbitMQ学习笔记（一）——使用场景（限流削峰、异步解耦、数据收集）

使用场景（限流削峰、异步解耦、数据收集）

1、限流削峰

MQ可以将系统的超量请求暂存其中，以便系统后期可以慢慢进行处理，从而避免了请求的丢失或系统
被压垮。

场景一、

用户发起的请求5000次每秒，远超过系统A主机的允许的最大请求数2000次每秒。此时，过量的请求将会导致磁盘读写或网络通信（IO操作）的阻塞、数据丢失、服务器压力过大等问题，最终系统A无法访问。

场景二、

加入消息中间件RabbitMQ后，MQ会将超量的请求拦截下来，暂存到队列里，既避免过量请求导致系统A崩溃，也不会丢失用户的请求数据。

2、异步解耦

1、微服务间基于Feign的调用——同步调用

缺点

1、用户完成支付服务，需要调用订单服务、仓储服务、短信服务等等，并且需要等待调用的服务全部完成，才完成支付服务。那么，支付服务耗时为所有服务执行的总长，为500ms。我们知道，一次请求耗时过长，将会阻塞线程以及IO操作，影响其他请求，对系统资源造成严重浪费。
2、耦合度高，当其中某一个服务崩溃了，将会影响所有服务不可用

2、 异步线程池

当用户执行订单服务时，调用短信服务的同时，调用邮件服务、SMS短信等服务，等待调用的所有服务完成后，完成支付服务。该次总耗时长为100ms，提高了访问速度。

存在很多缺点：

1：耦合度高
2：需要自己写线程池自己维护成本太高
3：出现了消息可能会丢失，需要你自己做消息补偿
4：如何保证消息的可靠性你自己写
5：如果服务器承载不了，你需要自己去写高可用

3、使用异步消息队列

1、用户的响应时间相当于是订单信息写入数据库的时间，也就是50毫秒。
2、当用户执行订单服务时，订单服务调用其他服务时，只需要通过MQ发送订单消息通知其他所调用的服务完成任务即可，无需等待其他服务执行完。因为写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。

好处：

1：完全解耦，用MQ建立桥接
2：故障隔离：有独立的线程池和运行模型、没有直接调用，不存在级联失败问题
3：消息持久化：出现了消息可能会丢失，MQ有持久化功能
4：消息可靠：如何保证消息的可靠性，死信队列和消息转移等
5：高可用：如果服务器承载不了，你需要自己去写高可用，HA镜像模型高可用
6：流量削峰：不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件

缺点：

1：架构复杂了，业务没有明显的流程线，不好管理
2：需要依赖于Broker的可靠、安全、性能

3、数据收集

分布式系统会产生海量级数据流，如：业务日志、监控数据、用户行为等。针对这些数据流进行实时或批量采集汇总，然后对这些数据流进行大数据分析，这是当前互联网平台的必备技术。通过MQ完成此类数据收集是最好的选择。