从数学的视角来诠释“服务雪崩”

相信很多后端研发的同学有过类似的感觉：平时经常听到“服务雪崩”这个词，但总觉得是一知半解。今天我将从数学的视角来诠释“服务雪崩”。
“服务雪崩”，通常是指客户端的请求量超过了服务端处理的能力上限，最终导致服务不可用。

“雪崩”一词形象生动的描述了当请求量暴涨时，请求响应时间像“滚雪球”一样持续的变大，直到所有的客户端请求全部超时，服务端后续的任何响应都会被客户端所忽略，服务完全不可用，进而“雪崩”。

上面的描述依然很抽象，那该如何理解呢？我们先从服务端的处理能力入手，一般我们使用TPS或者QPS来衡量一个服务的处理能力，即吞吐量。

服务吞吐量 = 服务并发数 （单位时间 / 平均响应时间），这里举一个简单的例子，比如你去银行某个营业厅办理业务，这个营业厅一共有5个柜台可以办理业务，平均每个人的办理时间为10分钟，那么这个营业厅一个小时的服务吞吐量 = 5 (60 / 10) = 30。

相对的如果我们有一个后台服务，它有10个进程在并发处理请求，每个请求的平均响应时间为20ms，则这个服务每秒的吞吐量（QPS）= 10 * (1000ms / 20ms) = 500。

知道了服务吞吐量如何衡量，另一个重要的概念是响应时间。响应时间 = IO时间 + 计算时间 + 等待时间。服务“雪崩”的关键在于等待时间持续变长，导致请求超时。

为了方便讨论，我们这里假设客户端请求的分布是完全均衡的，服务端的处理能力是不变的，服务端的吞吐量到达上限时的平均响应时间为Tavg，如果此时请求量上升为吞吐量上限的n倍，Tni表示请求上升到n倍后的第i个请求的响应时间，那么我们可以得到如下的公式：

第i个请求的等待时间 = 前i-1个请求的处理时间 - 第i个请求的达到时间

第i个请求的响应时间 = 前i-1个请求的处理时间 - 第i个请求的达到时间 + 请求处理时间

如果客户端的请求量还未达到服务端的吞吐量上限，即0 < n <= 1，则此时服务响应时间在理想情况下是等于Tavg的。

因为当n > 1时，Tni是一个增函数，所以越晚达到的请求，其响应时间则越长，当Tni的值大于客户端设置的超时时间时，就会发生服务“雪崩”。

上面的推导过程可能过于抽象，这里举一个具体的“栗子”。假定我们有一个服务，它的QPS上限为100，则它的Tavg为10ms。当每秒的请求量达到200时，第二个请求的响应时间为：10ms(第一个请求的处理时间) - 5ms(第二个请求5ms的时候达到服务端) + 10ms(第二个请求的处理时间) = 15ms。

根据上面推到的公式，此时Tni = (i + 1) * 5ms，如果客户端设置的超时时间为500ms，则第100个和后续的请求都会超时。