53 | 过载保护与容量规划

所谓过载,最直白的理解,当然就是因为活跃的用户超过了资源的承载能力范围,导致某类资源耗尽,进而体现出系统过载

本质上,这是一个容量规划的问题。

资源怎么会不够了?

这种因为重试而带来的请求次数放大,可能会导致系统的资源储备不足,进而引发了过载

过载了,会带来什么样后果?

CPU 负荷过高,持续接近 100% 下不来。如果 CPU 资源不足以应对请求负载,一般来说,所有的请求都会变慢。这个场景会造成一系列的副作用,比如处理中的请求数量上升。因为处理请求需要较长的时间,同一时间服务器必须同时处理更多的请求(上升到一定数量可能会开始进入队列排队)。这会影响其他所有的资源,包括内存、socket 连接以及其他后端服务器资源的消耗也相应增加。

过载通常是会有连锁反应的。某类资源的耗尽,会导致其他资源出现问题。某个服务的过载,经常会出现一系列的资源过载现象,看起来都很像是根本问题,这会使得定位问题更加困难。

过载现象可能会是一个短时现象,过一段时间就撑过去了。但也有很多时候会由于正反馈循环(positive feedback)导致恶化,短时间内就快速形成雪崩效应,击垮系统

雪崩效应是如何形成的?

我们假设某个服务实例能够承受的正常 QPS 为 10000,如果某个时刻正常业务所产生的自然请求数是 11000,那么其中就有 1000 个请求会失败,如果失败重试导致的请求放大至 9 倍的话,那么系统的 QPS 就增加到 20000,是正常负荷的 2 倍。

这样的高负荷,会直接压垮这个服务实例。在这种情况下,这个服务实例的所有请求会被转移到其他互备实例,从而导致这些互备实例承受了更为巨大的压力。故而,互备实例同样一个个很快被压垮。最终,该服务完全挂掉。

过载的监控

常见的是给服务的 QPS 设置一个阈值,当 QPS > 阈值时,就触发服务已经过载或即将过载的告警。

更好的解决方案,是直接基于该服务所依赖的关键资源,如 CPU 和内存等,来衡量服务的可用容量。我们为该服务预留了多少资源,这些资源已经用了多少,预计还能够用多久。

我们基于基础资源的用量来估算,比基于服务的 QPS 要稳定可靠得多。在绝大部分情况下(当然总会有例外情况),我们发现简单地基于 CPU 使用量作为服务容量的指标,效果已经非常好了。

过载的应对策略

大的思路来说,无非两个方向,一个是把过载发生的概率变低。另一个是即使发生了过载,也要杜绝雪崩效应,把因为过载产生的损失降到最低。

过载的应对策略 (2)

K 值决定了过载时服务端的拒绝率,默认为 K=2

这意味着服务端过载的时候有 50% 的处理率。如果我们调整为 K=1.1,那么算法变得非常激进,服务端有 90% 的处理率


有疑问、勘误、请您在下方留言,感谢您的支持 ღ( ´・ᴗ・` )!

感谢您阅读,这篇文章归 极客点子版权所有.
如果转载,请注明出处: 极客点子版权所有(/page/981.html) 知识共享许可协议
本网站使用 创作共用 归属 - 非商业用途 - 共享4.0国际许可协议的相同方式 许可.

关于作者:

    简介:

    系统架构师 、作家、
    研究方向:数据分析、 深度学习、 服务器架构、 系统原理