这是一个典型的数据库超时案例。

1. 要习去其中的经验教训，日后不要在踩类似的坑
2. 遇到类似的问题，掌握分析方法，快速解决问题。

最重要是，学习存储系统架构设计思想，在架构层面限制故障对系统的破坏程度。

事故排查过程

系统，每天晚上10-11点系统瘫痪，时间过了之后自动恢复。系统瘫痪的现象是，网页和APP打不开。

系统架构图，如下所示：

整个系统在公有云上，Nginx作为前置网关承接前端所有请求，后端按照业务，划分了若干微服务分别部署。数据保存在MySQL，部分数据用Memcached做前置缓存。

初步判断，这个故障是和访问量有关系的，看下面这个系统每天的访问量的图，可以印证这个判断。

基于这个判断，排查问题的重点，应该放在服务于用户访问的功能上。比如说首页、商品列表页。

在访问量峰值的时候，请求全部超时，随着访问量减少，**系统能自动恢复，基本可以排除后台服务被大量请求打死的可能性。**因为进程被打死了，一般不会自动恢复。排查问题的重点应该放到MySQL 。MySQL的CPU利用图，发现问题。

从监控图上可以看出来，故障时段 MySQL 的 CPU 利用率一直是 100%。这种情况下， MySQL 基本上处于一个不可用的状态，执行所有的 SQL 都会超时。

MySQL 这种 CPU 利用率高的现象，绝大多数情况都是由慢 SQL 导致的，所以我们优先排 查慢 SQL。MySQL 和各大云厂商提供的 RDS 都能提供慢 SQL 日志，分析慢 SQL 日志， 是查找类似问题原因最有效的方法。

慢SQL日志中，含有：SQL、执行次数、执行时长等信息。排查慢SQL主要靠经验。

首先，要知道数据库非常繁忙时，执行任何一个SQL都很慢。因此，并不是所有的慢SQL日志的慢SQL都问题，大部分请求下是其中的一条。但是，单次执行时间特别长的SQL，是重点排查对象。

最终找到了一个特别慢的SQL，是计算粉丝数最多了TOP10红人。