如何最小改变架构，快速实现流控的？（第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

==全文完==

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

点赞，转发，在看，感激不尽！