如何最小改变架构,快速实现流控的?(第34讲)

《架构师之路:架构设计中的100个知识点》

34.快速流控

传统架构,为何不是默认流控的?

站点与服务,服务与服务上下游之间,一般如何采用两种通讯模式:

其一,RPC直接调用。

其二,MQ推送模式。

画外音:这也是MQ的默认模式。

这两种模式,都可能造成流量冲击:流量从端到站点,到服务,到数据库,流量会一路透传下来,引发雪崩。

举个秒杀业务的栗子。

  1. 上游:端上发起抢购操作;

  2. 下游:完成秒杀业务逻辑(库存检查,库存冻结,余额检查,余额冻结,订单生成,余额扣减,库存扣减,生成流水,余额解冻,库存解冻);

上游每秒并发1W个请求,下游每秒只能并发处理2K个请求,**如果流量直接透传,会导致下游系统被压垮。**雪崩出现后,整体系统并发处理能力归0。

如何避免雪崩,使得整体系统能够保持在一个并发2K的处理水平?

有两大类优化方向:

  1. 上游队列缓冲,限速发送;

  2. 下游队列缓冲,限速执行;

那哪种优化对架构改造最小?

下游队列缓冲,限速执行,对系统改造最小。

如何改造?

上下游之间加一个MQ,采用拉模式:

MQ-reciever根据自己的处理能力,实施流控,就能达到保护自身的效果。并且这是MQ提供的通用功能,无需上下游修改代码。

如果上游发送流量过大,MQ提供拉模式确实可以起到下游自我保护的作用,但会不会导致消息在MQ中堆积,导致全部超时?

下游处理过慢,确实可能会导致消息堆积,常见的有两种处理方法:

  1. 治标法,提前判断请求在队列中的停留时间,如果超时,直接快速返回,这样至少还能保证一部分请求不超时;

  2. 治本法,还是要优化下游业务系统,例如批量处理,才能从根本上提升吞吐量;

结论

削峰填谷,避免雪崩,实施流控,最小化升级:

  1. MQ要做的:MQ-client使用拉模式,定时或者批量拉取,可以起到削平流量,下游自我保护的作用;

  2. 业务系统要做的:优化处理吞吐量;

知其然,知其所以然。

思路比结论更重要。

补充阅读材料:

《MQ流控

https://www.enterpriseintegrationpatterns.com/ramblings/queues_flow_control.html

图1:MQ削峰填谷

图2:MQ雪崩保护

图3:MQ降级保护

文章比较系统,建议细读**。**

==全文完==

20年,系列1(已完结):

架构师定会遇到的80个经典架构问题!

21年,系列2(已完结):

关于即时通讯架构的一切!

24年,系列3(进行中):

《架构设计中的100个知识点》

**短视频+图文+直播+星球社群,**免费。

讲技术的宝藏号,日更,保护起来。

点赞,转发,在看,感激不尽!

相关推荐
BeyondCode程序员11 分钟前
设计原则讲解与业务实践
设计模式·架构
七夜zippoe13 分钟前
微服务配置中心高可用设计:从踩坑到落地的实战指南(二)
微服务·架构·php
hello_25041 分钟前
GitOps:一种实现云原生的持续交付模型
架构·argocd
胡耀超2 小时前
2、CPU深度解析:从微架构到性能优化
python·性能优化·架构·arm·cpu·x86·多核心
BTU_YC12 小时前
FastAPI+Vue前后端分离架构指南
vue.js·架构·fastapi
大咖分享课14 小时前
双活、异地多活架构怎么设计才不翻车?
架构·两地三中心·多活架构
云宏信息14 小时前
赛迪顾问《2025中国虚拟化市场研究报告》解读丨虚拟化市场迈向“多元算力架构”,国产化与AI驱动成关键变量
网络·人工智能·ai·容器·性能优化·架构·云计算
Juchecar17 小时前
翻译:为什么 本地优先应用 没有流行开来?
架构
echoyu.18 小时前
微服务-分布式追踪 / 监控工具大全
分布式·微服务·架构
love530love18 小时前
EPGF 架构为什么能保持长效和稳定?
运维·开发语言·人工智能·windows·python·架构·系统架构