共计 1074 个字符，预计需要花费 3 分钟才能阅读完成。
相信很多后端研发的同学有过类似的感觉：平时经常听到“服务雪崩”这个词，但总觉得是一知半解。今天我将从数学的视角来诠释“服务雪崩”。
“服务雪崩”，通常是指客户端的请求量超过了服务端处理的能力上限，最终导致服务不可用。
“雪崩”一词形象生动的描述了当请求量暴涨时，请求响应时间像“滚雪球”一样持续的变大，直到所有的客户端请求全部超时，服务端后续的任何响应都会被客户端所忽略，服务完全不可用，进而“雪崩”。
上面的描述依然很抽象，那该如何理解呢？我们先从服务端的处理能力入手，一般我们使用 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 个和后续的请求都会超时。