【专项测试】限流测试

 简介

        限流的目的是防止恶意请求、恶意攻击，或者防止流量超出系统峰值时保护系统免受灭顶之灾。

限流的具体做法是是通过对并发访问/请求进行限速或者对一个时间窗口的请求进行限速在保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页），排队等待，降级（返回兜底数据、默认数据等）等。

通过压测找到系统的处理峰值，然后通过设定峰值阈值，在防止系统在流量过载时，通过拒绝过载的请求来达到高可用的目的。

限流的原则是防止流量穿透前端，打到后端薄弱的环节。

测试经验

1、被测物的限流算法：

常见的限流算法有：令牌桶、漏桶。计数器也可以用来进行简单粗暴的限流。

1.1 令牌桶

令牌桶算法，是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌，令牌桶算法的描述如下。：

• 假设限制2r/s，则按照500毫秒的固定速率往桶中添加令牌。
• 桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃或拒绝
• 当一个n个字节大小的数据包到达，将从桶中删除n个令牌，接着数据包被发送到网络上。
• 如果桶中的令牌不足n个，则不会删除令牌，且该数据包将被限流(要么丢弃，要么在缓冲区等待)。

1.2 被测物漏桶算法

漏桶作为计量工具(The Leaky Bucket A1goritbm as a Meter)时，可以用于流量整形(Traffic Shaping)和流量控制(Traffic Policing)，漏桶算法的描述如下：

• 一个固定容量的漏桶，按照常量固定速率流出水滴。
• 如果桶是空的，则不需流出水滴。
• 可以以任意速率流入水滴到漏桶。
• 如果流入水滴超出了桶的容量，则流入的水滴溢出了(被丢弃)，而漏桶容量是不变的。

1.3 令牌桶和漏桶的算法比较：

• 令牌桶限制的是平均流入速率，允许突发请求，只要有令牌就可以处理，支持一次拿多个令牌；漏桶限制的是流出速率，平滑处理突发流入的速率，虽然流入的速率可以是突发的，但是流出的速率是固定的。

1.4 计数器实现限流

 计数器法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置counter，具体算法的示意图如下：

 具体的伪代码如下：

计数器实现限流  展开原码

2、应用级限流

限流还有其他形式的限流：

• 限流总并发数/请求数
• 限流总资源数：有点资源是稀缺资源（如数据库连接、线程）而多个系统都会使用，需要加以限制
• 限流系统中某个接口的总并发/请求数：如果某个接口可能有突发访问情况，担心该接口的并发访问造成整个系统的瘫痪，则需要限制该接口的并发/请求数
• 限流某个接口的时间窗请求数

3、测试思路针对限流的测试思路

3.1 如何在测试环境模拟限流场景？

方案1：调整限流阈值为极限情况

方案2：在测试环境通过压测工具（jmeter, ngrinder，相对小的量也可以通过写一个简单的多线程客户端来实现）简单模拟

3.2 对限流场景的测试思路：首先了解清楚限流的实现方案的细节；其次，评估限流方案是否合理，是否对上下游系统造成影响；是否有更优的方案；最后，通过正例和反例验证限流逻辑的正确性，该限的流量是否被限，不该被限的流量是否没有被限。

 规范

1.  MUST测试环节需要测试人员评估限流对上下游系统的影响。
2.  MUST如果对上下游系统有影响，必要的情况需要和上下游系统共同商榷限流的方案，或者告知上下游系统限流 的方案。
3.  MUST要对以下情况进行测试：系统限流逻辑里应该有明确的标识说明该流量被应用限掉了，这样关联系统可以明确判断流量异常的原因，是被限掉了还是调用超时等其他因素。
4.  MUST限流配置数据的合理性也是测试范围。