由于redis服务器cpu100%的问题导致网站宕机访问大量出现504gateway time-out

背景：

某天公司突然发现整个网站访问很慢，请求大部分报502，基本处于宕机状态....时间大概持续一整晚,导致公司大量的投诉直接造成经济损失...

网站主要使用的技术栈：

nginx+php+mysql+redis

阿里云ecs

定位问题过程：

第一步就去查看mysql服务器状况，是否有慢查询导致，结果是mysql运行良好

第二步查看web服务器服务器情况，内存使用偏高，但整体负载并没有过红线

第三步查看redis服务器，服务器负载“运行良好”(这里先打个引号后面详细说明)

以上我把它称为排查问题的前置3部曲，检查问题的基本操作。

结果运维工程师告诉我3步完成后竟然一点问题都没有,我当时就有点蒙....

开始检查当天发布的代码是否有可能出现问题，但当时思绪是没有目标的，我们就像无头苍蝇一样扫代码(可想而知没有大概的范围是很难解决的，你得告诉开发工程师大概的方向才能定位问题)...

再次督促运维工程师继续排查...

二次定位问题过程：

检查nginx访问日志，全是60秒超时，查看高峰日志最高约1800/秒左右，这时突然想到我们的php-fpm是静态部署，每台设置260左右的数量(也就是并发最多260个访问左右)，我们有6台web 也就是1560(260*6)左右

得出第一结论：我们的web服务器访问数满负荷了，吞吐量很低，也就是访问要排队了

第一结论的疑问1：为什么访问接满负荷web服务器负载没有超红线？

原因：260静态常驻fpm是我们相对服务器内存保守计算得出的值，这个值并没有超载

第一结论的疑问2：为什么吞吐量很低呢，第一想到的是否mysql慢查询问题(工程师最容易犯错的地方)，但前面提到我们排查了mysql慢查询并没有，那是什么原因照成的呢？

这时运维同学发现新的问题，细化查询服务器性能发现redis服务器单个cpu100%了，那之前为什么没查出来服务器有问题呢？原来之前查看的是阿里云的监控界面，该界面是根据平均负载来给出的实时分析，而这台服务器是双核服务器，平均一下是正常的....掉坑了！大家都知道redis是单核的，还有一个cpu是空闲的。

终于定位到问题”来源“了：redis服务器cpu100%。

我们紧接着查看redis的当前状态，发现key的数量有500万+，日常我们只有30W左右，虽然如此但是内存其实并没有超过境界线

引发了我们新的一轮思考，是什么引起cpu100%的？为什么内存没有超标而是cpu超了？

为了先快速解决当前的窘境我们决定先尝试清空redis看是否能恢复网站(因为我们的业务代码对redis并没有很强的依赖)，毕竟快1分钟解决就是少损失一分钱，运维执行清空后，网站恢复了正常。

临时解决方案：备份redis，清空redis(flushall)

虽然问题”解决“了，但是我们还没有找到问题的根源，于是下定决心必须搞清楚，接下来就是探索和试验，时间和篇幅长度问题准备再下一篇中具体说明。

redis服务器cpu100%的原因和解决方案