文章目录
- 使用场景(限流削峰、异步解耦、数据收集)
- 1、限流削峰
- 场景一、
- 场景二、
- 2、异步解耦
- 1、微服务间基于Feign的调用——同步调用
- 缺点
- 2、 异步线程池
- 存在很多缺点:
- 3、使用异步消息队列
- 好处:
- 缺点:
- 3、数据收集
使用场景(限流削峰、异步解耦、数据收集)
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完成此类数据收集是最好的选择。