【专项测试】限流测试
简介
限流的目的是防止恶意请求、恶意攻击,或者防止流量超出系统峰值时保护系统免受灭顶之灾。
限流的具体做法是是通过对并发访问/请求进行限速或者对一个时间窗口的请求进行限速在保护系统,一旦达到限制速率则可以拒绝服务(定向到错误页),排队等待,降级(返回兜底数据、默认数据等)等。
通过压测找到系统的处理峰值,然后通过设定峰值阈值,在防止系统在流量过载时,通过拒绝过载的请求来达到高可用的目的。
限流的原则是防止流量穿透前端,打到后端薄弱的环节。
测试经验
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 对限流场景的测试思路:首先了解清楚限流的实现方案的细节;其次,评估限流方案是否合理,是否对上下游系统造成影响;是否有更优的方案;最后,通过正例和反例验证限流逻辑的正确性,该限的流量是否被限,不该被限的流量是否没有被限。
规范
- MUST测试环节需要测试人员评估限流对上下游系统的影响。
- MUST如果对上下游系统有影响,必要的情况需要和上下游系统共同商榷限流的方案,或者告知上下游系统限流 的方案。
- MUST要对以下情况进行测试:系统限流逻辑里应该有明确的标识说明该流量被应用限掉了,这样关联系统可以明确判断流量异常的原因,是被限掉了还是调用超时等其他因素。
- MUST限流配置数据的合理性也是测试范围。