教科书级的根因推导——必做题

发表于 | 分类于 | 次

教科书级的根因推导——必做题

问题描述

A服务访问 B 服务，突然在某个时间点有个访问毛刺，RT 从50 ms飙到了80 ms，如下图

image-20240607210416189

这个时候发现网络连接数也从10000 涨到了 11000

image-20240607210602281

当时的QPS 一直是 2万，没有任何明显变化，任何其它指标都没有变化

请回答问题

  1. 到底是 B服务慢了所以 RT 上涨，RT 上涨后触发了新建连接，还是突然大量新建导致 B服务慢了，请写出你的详细推导
  2. 你如何在A 端来验证这个问题；你又如何在 B段来证明这个问题

我的分析

首先是所有其他指标都正常，查下来看到的变化就是RT、总连接数同时抖了，所以以下分析都是基于在这个情形下，这两个指标到底谁是因、谁是果

分析的基本原则就是星球里最重要的概念：QPS、并发、RT 的关系

为什么说连接数上涨是根因？

抖动前 rt 50ms，QPS 2万，计算下来一个连接能扛的 QPS 是20( 1000ms/50ms =20 QPS 1秒等于1000ms)

1000个活跃连接就可以扛住这 2万的QPS，而总连接数在抖动前是10000，也就是连接数的水位只需要10% 就够了。按照抖动时的rt 80ms 则这10000个连接是可以扛 12.5万QPS 才会触发连接数不够创建新连接(理想值，也就是在QPS 到12.5万的80% 之前触发连接数不够的概率极小极小)

一个很关键的点：新建连接是业务端的行为，除非服务端太慢导致连接不够才会触发客户端新建，否则都是业务端的锅

几个注意的地方：

  • 另外一个注意下抖动的时候也没有触发业务端有超时报错(80ms 只是平均值)，如果真有超时报错可能会丢掉老连接，创建或者取新连接重试
  • 实际上连接有总连接数、活跃连接数，总连接就是我们这里说的1万，活跃连接对应的就是 1000——也就是你随机去看业务状态，有1000个连接在忙着做业务处理/查询，还有9000个连接在睡大觉

如何验证？

  1. 让客户建1000-2000 个新连接看看——应该会触发RT 飚一下，但不一定是充分条件，实际在同一个客户的其他实例上也有抖动的场景里没有触发新建连接——相当于间接验证
  2. 或者让客户在他们的网卡上加 30ms模拟抖动从50ms加到80ms，看会不会触发新建几百个连接，如果没有触发新建说明RT 这个幅度的上涨不会触发新建连接

不知道我解释清楚了没有