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

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

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

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

相关推荐
骥龙4 小时前
零信任架构:重塑现代企业安全基石
安全·架构
码界奇点9 小时前
KingbaseES一体化架构与多层防护体系如何保障企业级数据库的持续稳定与弹性扩展
数据库·架构·可用性测试
掘金-我是哪吒9 小时前
分布式微服务系统架构第169集:1万~10万QPS的查当前订单列表
分布式·微服务·云原生·架构·系统架构
attitude.x10 小时前
微服务架构的五大核心挑战与应对策略
微服务·云原生·架构
mqiqe10 小时前
架构-亿级流量性能调优实践
java·架构
qb12 小时前
vue3.5.18源码-编译-入口
前端·vue.js·架构
milanyangbo14 小时前
“卧槽,系统又崩了!”——别慌,这也许是你看过最通俗易懂的分布式入门
分布式·后端·云原生·架构
失散1314 小时前
分布式专题——1.1 Redis单机、主从、哨兵、集群部署
java·数据库·redis·分布式·架构
2301_7795037614 小时前
MySQL集群高可用架构---mysql高可用之组复制 (MGR)
数据库·mysql·架构
大咖分享课15 小时前
系统越拆越乱?你可能误解了微服务的本质!
微服务·云原生·架构