mysql cpu_mysql cpu 100%的问题和解决

现象: 用户高峰时段, 系统很卡, rds mysql cpu接近100%, 持续时间可达30分钟以上。

解决过程:

查nginx access log发现有个接口(暂且叫apiA)的请求非常多, 同一秒可能会有上百个。而根据目前

的用户情况是不合理的。我们在接口里用redis统计每个用户的请求次数, 也大大超过实际估计。

所以我们怀疑有ddos攻击。

为了不影响用户使用, 我们第一时间加了限流。

加限流的方法:

1) 接口里根据redis的统计限制单位时间的访问次数。这个改动较大

2) 我们猜laravel框架应该有这个限流功能。网上搜果然搜到。

使用注意:

错误的使用:

$api->get('apiA', ['middleware' => 'api.throttle', 'limit' => 60, 'expires' => 5, 'XXXController@index'])->name('apiA');

正确的使用:(需要加上uses)

$api->get('apiA', ['middleware' => 'api.throttle', 'limit' => 60, 'expires' => 5, 'uses' => 'XXXController@index'])->name('apiA');

无uses就报错:(因为传进去的函数callable是null)

"Function name must be a string"

限速后cpu很快降下来了, 系统不再卡顿。但是这个限速也影响了正常用户的使用，导致工作效率明显下降。

我们只好放开限流继续其他解决方案。

分析apiA我们发现其操作的mysql表的行数达几百万行。而实际使用时只要操作最近的几十万行即可。于是我们修改了接口，仅查询最近的几十万行。

然后我们也在前端加了优化，用户拼命刷新界面时，接口如果未返回就不重新请求服务器。

以上两个改动有较明显效果，系统卡顿的情况少了。

不过过了一两天，卡顿又如期而来。真是有点崩溃。

在卡顿时我们想到应该看看mysql的processlist, 根据这个log看到卡顿时大量请求在根据字段Y查询一个表, 而这个表的Y字段未加索引。

再看这个表也才2万多行。心想这个表会导致这么大卡顿吗？再想lg(20000)(小于15)和20000差别还是很大的，我们就立马加了Y的索引。

另外还有一个重要原因是，这个表有粉丝数字段，粉丝数时刻在更新，故对这个表查询的同时还对这个表修改，导致很卡顿。

加了这个索引后, 卡顿就彻底解决了。

另:当时出现这个bug, 和一个新功能上线时间重合。这是极重要线索。直接把代码回滚到出现bug之前的时间点，验证是否还有问题，是最快的方式。