限流的目标和模式

限流的目标和模式 什么是限流？ 我们简化一个电商项目，主要分以下4个服务，全部成功请求才算成功，该业务总超时时间是5秒，每个服务平均处理时间是0.5秒，我们通过集群的方式给每个服务部署5个节点

 1.客户下单
 2.进行扣款
 3.物流发货
 4.通知客户下单成功

以下有几个问题(理想状态下) 1.单个用户成功下单需要多长时间？

答案：4 × 0.5 = 2 秒 
4个服务都成功 乘以  每个服务0.5秒 这里就是我们常说的CPU处理时间

2.集群中每个服务每秒最多处理多少个请求？

答案：（1 ÷ 0.5）× 5 = 10 
每秒 除以 每个服务的请求时间0.5秒 乘以 5个集群 这里是我们常说的QPS 也就是每秒查询数

3.如果我们不考虑业务顺序并且请求是均衡的，在不超时的情况下，该系统每秒最多能承受多少个用户下单？

答案： 10 × 5 ÷ 2 = 25
10就是我们每个服务每秒最大处理的请求数  5是超时时间5秒 2是每次下单成功的业务至少需要2秒
这个25就是我们的每秒事务数(TPS)，这也是衡量我们系统吞吐量的最终标准

4.如果该系统在一段时间内持续收到50TPS的请求，会出现什么情况？

答案：理想状态下，50%的请求会成功
实际上，很少能有下单成功的用户，因为用户下单需要4个业务全部走完才算成功，大多数业务可能都只走了一两个

我这里简单介绍几种模式 1.漏桶模式 我们小时候都做过这样一道数学题，“一个水池以每秒X升的速度注水，同时又以每秒Y升的速度出水，问多长时间能注满?”

我们可以把请求想象成注水，系统处理请求想象成出水，水池就是我们的漏桶
漏桶模式一定程度上跟我们的先入先出队列很相似，漏桶满了就拒绝新的请求

2.令牌桶模式 令牌桶模式就像是我们去银行办业务所用到的取号机，它与漏桶算法一样都是基于缓存区的限流算法，只是方向相反，漏桶是出水，令牌桶是系统往叫号机中放入令牌。

假设银行等候区最多只能容纳20人，且每人手上都取了号，此时取号机就不再对外放号了，直到有人办完业务

本文是根据周志明老师的软件架构课自己总结的，仅供参考