QPS、并发数与限流保护漫聊
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.引言 Google的网站可靠性工程师小组（SRE）定义了四个需要监控的关键指标。他们称之为“四个黄金信号”：延迟（Latency），流量（Traffic），错误（Errors）和饱和度（Saturation）。这些与微服务的RED度量密切相关：速率，错误和持续时间，以及关注利用率，饱和度和错误的USE方法。这四个信号应该是服务级别目标（SLO）的关键部分，因为它们对于提供高可用性的服务至关重要。 流量（Traffic） 其中流量可以很多指标来衡量，比如QPS(每秒处理的请求数)、Inbound Bandwidth（输入带宽）、Outbound Bandwidth(输出带宽)等。 2.Little’s law QPS: query per second，每秒处理的请求数 RT: response time，平均响应时间或平均处理时间 Concurrent：并发数 QPS、RT、Concurrent之间存在如下关系： Concurrent = QPS * RT 某个服务可以被想象成一条单向高速公路。 每一个需要处理的请求或者任务可以想象成正在这条公路上行驶的汽车。 汽车从入口驶入，到从出口驶出所需要的时间就是平均响应时间(RT) 当前公路上的所有车辆数就是并发数(Concurrent)，它一个瞬时值 车辆流速稳定后(从入口驶入和从出口驶出的速率 相同)，每秒从入口驶入的车辆数就是每秒处理的请求数(QPS) 3.定性分析 3.1 RT变大 如果服务处理任务的过程依赖其它服务，比如MySQL、或者第三方服务。如果第三方服务出现问题，处理时间变长（RT变大），在QPS不变的情况下，由Little’s law可知，Concurrent会变大 3.2 QPS 如果客户端调用量突然增大，即QPS增大，RT不变的情况下，由Little’s law可知，Concurrent也会变大 3.3 请求触达速率和请求完成速率不一致 这种情况对于处理长作业的服务尤为明显。如果任务到达的快，处理的慢，那么通常只有2个结局，要么提交任务的时候，任务被直接拒绝，要么任务被扔在某个等待队列中，等待执行。在外部的用户看来，这些任务都是在并发执行中，可以看做是并发数。 4. 限流保护 在很多服务中，针对每个请求，都会独立分配额外的资源。比如Golang的web框架在gin中，每个连接都会分配3个协程；MySQL会针对每个请求创建User Thread），如果并发数一直增大，则服务很可能会被OOM或者陷入某种假死状态。 Concurrent = QPS * RT 结论 由于并发数受到2个变量QPS和RT的影响，RT受到第三方服务的影响而不可控，因此仅对QPS限制是无法保护服务的，还需要对Concurrent进行限制。 参考资料 1.Little’s law 2.QPS和并发数，这次给你说清楚 3.QPS、TPS、RT、并发数、吞吐量理解和性能优化深入思考