如何最小改变架构,快速实现流控的?(第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个知识点》

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

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

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

相关推荐
不爱学英文的码字机器3 小时前
零信任架构:重塑网络安全的IT新范式
安全·web安全·架构
却道天凉_好个秋6 小时前
系统架构设计(二):基于架构的软件设计方法ABSD
架构·系统架构
泯泷6 小时前
「译」解析 JavaScript 中的循环依赖
前端·javascript·架构
抹茶san6 小时前
前端实战:从 0 开始搭建 pnpm 单一仓库(1)
前端·架构
cooldream20099 小时前
深入解析大数据的Lambda架构:设计、特点与应用场景
大数据·架构·系统架构师
uhakadotcom11 小时前
rAthena:快速入门与基础知识详解,附实用示例代码
面试·架构·github
cooldream200912 小时前
深入理解MVP架构:让UI层与业务逻辑完美分离的设计模式
ui·设计模式·架构·系统架构师
MonkeyKing_sunyuhua12 小时前
2.2 主流大模型架构:GPT、DeepSeek、GLM、Claude、QwQ、Qwen2.5-Max等模型的比较与应用场景
gpt·架构
bookcman13 小时前
Seata 部署手册
后端·架构
丘山子13 小时前
如何在 1000 亿级数据规模下实现高效的去重统计?
后端·面试·架构