如何最小改变架构，快速实现流控的？（第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个知识点》
短视频+图文+直播+星球社群，免费。
讲技术的宝藏号，日更，保护起来。
点赞，转发，在看，感激不尽！