#网络安全#一行代码引起的协程泄露网络安全

文章图片

文章图片

文章图片

文章图片

前言最终定位到的结果比较蠢，巨佬可以直接查看结果，本文只为记录寻找该bug时使用的方法而生。本人平日维护一个公司运营平台的一个配置库，由于降级措施比较好，而且公司容器实例也比较多，所以在爆发错误的时候并未及时跟进。该问题应该从该服务出生开始就已经有了，一直没有爆发的原因应该是因为以前迭代得比较多，一周也差不多会发布四到五次，再加上平台在去年使用人数还是比较少的，后面逐渐成为公司一个中流砥柱的产品，被许多部门所使用，所以问题就爆发了。
第一次猜想“这服务怎么协程突然暴涨了”
第一次协程暴涨的时候，发现有一台实例突然就跪了，协程数疯狂暴涨，内存也疯狂暴涨，第一反应是db出现了慢查询，但是实际上。而查看监控，并没有特别多接口跪，如图。

而实际上能很明显看到有几个实例的协程数直线上涨。

其实因为服务设计原因，没有那么多接口跪是符合预期的，因为其他接口都做了内存全表缓存，至于为什么做内存全表缓存就后面再说吧。通过pprof定位，很容易就发现那几个跪了的接口都有一个共同点，协程泄露。
此时扫了一眼代码，那几个接口除了没有做缓存，其他实现都蛮合理的，因为怀疑是慢查询了，所以尝试去扫了一下表，大概最长耗时接近1s ，该表数据也差不多到了3w多数据了，所以认为是因为扫这个表导致线程被占用，而当多台机子都并发读该接口时因为慢查询给堵住，没有超时设置所以获取协程的吞吐量不成比了。
所以就溜下去给这个接口做了内存缓存，暂时缓解了两三个星期，但是几周过后又出现了协程泄露，不得而解。。
第二次猜想再次出现协程泄露时，没什么其他手段去排查了，只能干读代码，不是因为读库的原因，那是因为什么呢？
产生了这个想法的我，看向了写操作的代码，有没有可能是因为读写没分离，写超时了导致出现这个问题呢。
因为再次出现协程泄露的时间很奇特，在半夜四点，突然给电话打醒。所以突发奇想，跟同事去查了一下当天凌晨4点平台的操作，发现确实，有一个人在晚上4点的时候申请了一个东西，写了库，时间恰好吻合。
所以确实是因为写数据的问题了，于是我又去扫了一眼代码，发现整个库表都是读主库的，从库从来不用， emmmmmm 。于是就给服务做了一次读写分离，做起来也不复杂。
不出所望过了两周，问题又爆发了。。
第三次猜想首先，我在质疑代码里的timeout真的是奏效的吗，为什么明明设置了超时时间还会超时，而且不单只只有代码通过框架设置了超时， db平台也设置了超时，按道理来说应该会kill掉的。不会是某个时刻操作比较多库比较渣所以就跪了，但是实际上操作的qps并不高，秉着质疑，我发现，线程池里只设置了10个线程数，对于这个服务来说10个线程完全不够啊，所以我就跑去扩线程了。