38 | 限流的目标与模式

老师问一下， TPS：40 × 10 ÷ 5 = 80 这个公式的10是指哪个？

香农第二定律指出：信息通道的传输率是无法超越信道容量的，如果传输的信息超过了信道容量，出错的概率是100%。 如果不限流，请求数量超过了服务器的最大吞吐量，就会100%出错，所以一定要限流。 就像没有红绿灯的十字路口，如果车流量过大就会完全堵死，谁都过不去，有了红路灯（限流），车辆就可以有序通过了。

老师，货币化那块没太明白，怎么设计分配多少货币，跟哪些参数有关？然后每个请求基于哪些参数判断要消耗掉多少货币？感觉这些参数应该都是动态的，需要全局统计信息？

我们是通过service mesh能够限制单pod的某个接口的qps，但是还是会遇到问题，比如业务最开始设置了单pod撑200qps，但是经过一个季度的开发，就能撑120qps了，就不得不去修改限流配置。现在正在探索通过CPU限流

我接触的生产系统中，限流会针对集群的QPS去做（这里需要压测才知道），熔断会根据单机上接口在一段时间内的RT大于指定阈值的比例，例如5%的请求大于100ms后，熔断5 sec ，执行默认降级逻辑，然后恢复。框架就是Hystrix中的实现，集成到了公司的基础组件中。 还使用过guava的rate Limit，当时的场景时客户一次升级系统，需要更新很多数据，同时升级期间这个客户的服务会中断，为了不影响线上其他的客户，所以就在异步处理中将请求切片，设置每秒只处理N条数据更新

限流已成为当前应用系统的必备，如果周老师能对每种限流算法提供一种实现方式个人感觉对理解此知识点更佳，毕竟所有的理论终究需要落实到实践。 个人列举以上4种限流算法的具体实现： 1、redis的zset可以实现”时间窗限流算法“。 2、redis的 redis-cell可以很好实现”漏桶限流算法“。 3、guava可以实现”令牌桶限流算法“。

限流那点时 限流目的 保证系统的健壮性 流量统计指标 每秒事务数（Transactions per Second，TPS） 每秒请求数（Hits per Second，HPS） 每秒查询数（Queries per Second，QPS） 限流方式 1、 流量计数器模式 设置一个计算器，根据当前时刻的流量计数结果是否超过阈值来决定是否限流 弱项： 流量计数器模式缺陷的根源在于，它只是针对时间点进行离散的统计 2、 滑动时间窗模式 在不断向前流淌的时间轴上，漂浮着一个固定大小的窗口，窗口与时间一起平滑地向前滚动。在任何时刻，我们静态地通过窗口 内观察到的信息，都等价于一段长度与窗口大小相等、动态流动中的时间片段的信息 弱项： 对于超过阈值的流量就必须强制失败或降级，很难进行阻塞等待处理，也就很难在细粒度上对流量曲线进行整形，起不到削峰填 谷的作用 3、漏桶模式 把“请求”想像成是“水”，水来了都先放进池子里，水池同时又以额定的速度出水，让请求进入系统中。这样，如果一段时间内注水 过快的话，水池还能充当缓冲区，让出水口的速度不至于过快。 弱项： 桶的大小和水的流出速率不好确定 4、令牌桶模式 假设我们要限制系统在X秒内的最大请求次数不超过Y，那我们可以每间隔 X/Y 时间，就往桶中放一个令牌，当有请求进来时，首先要从桶中取得一个准入的令牌，然后才能进入系统处理。任何时候，一旦请求进入桶中发现没有令牌可取了，就应该马上失败或进入服务降级逻辑

文中限流目标处的(3)的计算结果是错误的，或者说是表达不够准确的。 可以去gitee看md格式的文档内容，这里最大只能2000字：https://gitee.com/k-alen/docs/blob/master/imiting_calc_error_correction.md 下面是核心逻辑的文字版： 可以直接从资源的角度来进行计算，也更容易理解： ● 这个集群有10个服务，每个服务20个实例，不考虑谁是谁的情况下，总共有200个实例，可以认为每一秒，这个集群拥有200个CPU计算资源。 ● (1) 的结论计算：一个业务要调用10个服务来处理，每个服务平均花费0.5个CPU计算资源，那么一个业务就是 10 * 0.5 = 5s的CPU计算资源（也就是5个CPU计算资源），这个结论和 (1) 是相同的。其实这里可以扩展开，如果服务全部是依次同步调用，那么这个业务调用总耗时就是5s，如果10个服务都是并发调用的，那么这个业务总耗时只有0.5s，只是并发消耗了集群里5s的CPU计算资源罢了（5个CPU计算资源）。 ● (2) 的结论计算：集群中每个服务每秒的处理请求数，也是类似的计算逻辑，一个服务有20个实例，那么每秒有20个CPU计算资源，一个服务每秒的处理量就是20 / 0.5 = 40，这和 (2) 的结论是一样的。 ● 最后来看(3)怎么计算：前面提到，整个集群共有200个实例，每秒拥有200个CPU计算资源，在整个超时时间范围内，也就是10s，可以使用的CPU计算资源是 200 * 10 = 2000，在 (1) 中计算过，一个业务调用消耗 5 个CPU计算资源，那么在10s超时范围内，不考虑顺序且请求分发均衡的假设前提下（其实应该可以理解成允许10个服务并发处理），一共可以处理 2000 / 5 = 400 个业务调用，平均到每秒是 40 个业务调用。所以，(3) 的结论如果是要求每秒平均值，那么应该是 40TPS 才对。这里说了平均值，那就有非平均的情况，也就是，如果不考虑平均值，只计算峰值，比如，这1秒有超过40个业务请求过来，后面的9秒都没有业务请求，那么这1s秒就是峰值。如果要计算峰值，其实也可以通过一个假设就能很简单的得出结论：假设10s内，400个业务调用都是在第一秒到达的，那么这400个业务调用刚好能够在不超时的前提下全部处理完毕。所以，(3) 的极限峰值就是 400TPS。

本人愚钝，对于作者 TPS 的公式不是很理解，所以按照自己的思路计算了一下，结果相同 10个服务分别为 A B C D E F G H I J。20个节点分别从 1 到 20，所有的节点数量就是 A1~A20...J1~J20，由于流量均匀分布，所以假设200个节点同时接到业务请求，由于一个业务操作，每个服务都会调用一次，所以需要调用10次才可以处理完一次业务操作，那么这200个业务请求的调用链如下： 第1次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第2次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第3次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第4次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第5次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第6次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第7次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第8次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第9次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 第10次调用 A1,A2...A20,B1,B2...B20~~~~J1...J20 至此，200个业务操作处理完毕，而10次调用需要花费 10 * 0.5 = 5s，也就是说5s的时间，集群处理了200个业务操作，可以认为，在这5s内除了这200个业务操作之外，集群无法处理新的业务操作。而集群除了正常处理的业务操作之外，还可以积压业务操作，可以积压的业务操作数量就跟超时时间有关了，目前超时时间是10s，那么集群在5s内除了正常处理的200个业务操作之外，还可以积压 （10 - 5）/ 5 * 200 = 200 个请求，也就是说5s内可以承受400个业务操作，1s就可以承受80个业务操作。 计算公式就等于 单服务实例数 * 服务数 * （超时时间 / 一次业务操作耗时）/ 一次业务耗时，即 20 * 10 * （10 / 5）/ 5 = 80

令牌桶模式问题，最多100个令牌，用来限制最多100个请求每秒并发，开始空闲，放入了100个令牌，然后0.5秒时，进来100个请求，消耗了100个令牌，也补充了一些（这些令牌获取时也会触发补充逻辑，因为距离上次时间戳很远，补充的剩余令牌数不超过总数100）那补充后的令牌数和当前正在执行的请求数量，肯定会大于100，那这时再来请求还会获得到令牌，相当于不就超过100个请求1秒内进来吗，这就达不到期望的限流效果？