啊？马上要国庆了生产又崩溃了？一个生产问题记录

问题： 2024.9.24日 16:30 ：小程序访问异常，页面显示空白，或提示“糟糕，网络或服务器开了会小差”； 系统可以正常访问后，线上反馈接口请求响应慢，21点完成问题修复

突入其来的问题，没有在生产进行任何操作～ 不过既然发生了 必有缘由！

排查问题

首先服务肯定崩溃了，崩溃原因先不看 先排查现在接口响应慢的问题（这个优先级更高）
大量接口响应慢，且还能重现那么我们先拿到其中的一个curl保障能复现。

请求接口后发现确实慢，响应时间在5s左右，这还只是其中一个接口。
我们项目中是有网关的存在的，可以看到地址 : https://xxxxxx/super-gw/xxx
让我们把网关去掉先试试看看是不是接口调用变快了。验证结果：网关去掉后接口响应在毫秒级别。

那就可以得到结论 是网关导致慢，网关中的链路导致。网关内部没有任何别的操作逻辑，只有白名单和鉴权。
那么一个一个排除。首先看看是不是redis内存崩了。在排查下是不是鉴权接口慢。

当时没截redis的内存使用图，不过redis是好的没有发生问题。那么问题肯定就在鉴权接口上发生了。那怎么排查呢？这个时候 arthas 真香了！arthas.aliyun.com/

通过命令 trace 下相关的接口
“trace cn.ideamake.zeus.usercenter.service.impl.TenantUserServiceImpl getUser -n 5 –skipJDKMethod false ‘#cost > 1000’”
** cost 可以用来判断当前接口是否请求时长超过 1s 单位是 ms！**
我这里给一个案例，因为慢点问题已经处理了 1s 查不出来了～

可以看到我们慢的到底是哪个方法，在一个一个跟下去就得到了最终的慢的地方！！

定位到了 是因为一个sql 查询带来的 （每次网关都会访问这个sql不过id不同）

那为什么这个sql会带来这么大的影响呢？
是这个数据表锁表了吗？ 还是说每s 有上百个这个请求导致数据库执行不过来了呢？且这个sql为什么会慢呢？

首先 是否锁表了？ 问了下DBA并没有锁表

这个sql为什么会慢呢？
排查到是因为有一个用户”李老师“进行了大量违规操作909个账号批量来回切换使用。

关联链路可能是 A微信 A 手机号。A微信 B手机号 B微信 A手机号 C微信 B手机号。

可以通过日志看到 昨天把这个用户禁用后 系统就回复正常并且没有在多次高频的进行合并动作

禁用后系统恢复正常

每s 有多少个这样的请求呢？ 这取决于这909个用户是否一直在重复的访问小程序。每访问一次调用一个带有网关的接口都会触发一次5s的请求，导致数据库压力剧增，别的用户也就慢了。

不过每s有多少请求这个还没有得到具体的答案，dba还没回复～

如果没有使用 arthas 的话 估计我们只能一次一次的发布版本 打印日志来判断了～ 或者是通过经验静态看代码进行判断～ 大家还有什么别的好方法么？

如何解决

• 网关鉴权增加缓存逻辑
• 网关不应该因为一个接口导致整体崩溃，在请求鉴权接口时应该设置一个响应时间
• 业务层面进行逻辑调整优化用户关联逻辑

不过马上要过节了，假期前还是不要有大动作吧～ 先把数据清理了 加一个监控如果再次发现此类数据 可以先人工操作一下～

留一个课题： 从运维角度有方案可以优化此类问题吗？