访问数据库超时问题排障

1 排障过程

系统从圣诞节那天晚上开始，每天晚上固定十点多到十一点多这个时段，大概瘫痪1h左右，过这时段系统自动恢复。系统瘫痪时的现象就是，网页和App都打不开，请求超时。系统架构：

img

整个系统托管在公有云，Nginx作为前置网关承接前端所有请求，后端按照业务，划分若干微服务。数据保存在MySQL，部分数据Memcached做前置缓存。数据并没按微服务最佳实践要求，做严格划分和隔离，而是为方便，存放在一起。这对一个业务变化极快的创业公司合理。因为它每个微服务，随时都在随业务改变，若严格数据隔离，反而不利应对需求变化。

听问题描述，第一反应每天晚上十点到十一点这个时段，是绝大多数内容类App的访问量高峰，因为这个时候大家都躺在床上玩儿手机。初步判断和访问量有关

每天访问量图可印证判断：

img

排查重点应放在那些服务于用户访问的功能。如首页、商品列表页、内容推荐。在访问量峰值时，请求全部超时，随访问量减少，系统能自动恢复，基本排除后台服务被大量请求打死的可能性，因为若进程被打死，一般不会自动恢复。

排查问题的重点应该放在MySQL。观察MySQL CPU利用率：

img

故障时段MySQL的CPU利用率一直是100%。MySQL基本处不可用状态，执行所有SQL都会超时。MySQL这种CPU利用率高，绝大多数都是慢SQL导致，优先排查慢SQL。MySQL和各大云厂商提供的RDS都能提供慢SQL日志，分析慢SQL日志，是查找类似问题原因最有效方法。

一般慢SQL日志有信息：SQL、执行次数、执行时长。通过分析慢SQL找问题，并没有什么标准的方法，主要靠经验。

数据库非常忙时，执行任何一个SQL都很慢。所以，不是说慢SQL日志中记录的这些慢SQL都是有问题SQL。大部分导致问题的SQL只是其中一或几条。不能简单依据执行次数和执行时长判断，但单次执行时间特长的SQL，仍是重点排查对象。

找到一个特别慢SQL：红人排行榜，列出粉丝数最多的TOP10红人。

select fo.FollowId as vid, count(fo.id) as vcounts
from follow fo, user_info ui
where fo.userid = ui.userid
and fo.CreateTime between
str_to_date(?, '%Y-%m-%d %H:%i:%s')
and str_to_date(?, '%Y-%m-%d %H:%i:%s')
and fo.IsDel = 0
and ui.UserState = 0
group by vid
order by vcounts desc
limit 0,10

这种排行榜的查询，一定要做缓存。排行榜是新上线功能，可能忘记做缓存，通过增加缓存可有效地解决问题。

给排行榜加缓存后，新版本立即上线。本以为问题解决，当天晚上系统仍一样现象，晚高峰各种请求超时，页面打不开。再分析慢SQL日志，排行榜慢SQL不见了，说明缓存生效。日志中的其他慢SQL，查询次数和查询时长分布的都很均匀，也没看出明显问题SQL。

再看MySQL CPU利用率：

img

放大后的规律：

1. CPU利用率以20min为周期规律波动
2. 总体趋势与访问量正相关

猜测对MySQL CPU利用率的“贡献”来自两部分：

• 红线以下部分，正常处理日常访问请求的部分，和访问量正相关
• 红线以上部分，来自某20min为周期定时任务，和访问量关系不大

img

排查整个系统，没有发现20min为周期定时任务，继续扩大排查范围，排查周期小于20min定时任务，最终定位问题。

App首页聚合非常多，像精选商品、标题图、排行榜、编辑推荐等。这些内容包含很多数据库查询。当初设计时，给首页做个整体缓存TTL=10min。但需求不断变化，首页要查询内容越来越多，导致查询首页全部内容越来越慢。

通过检查日志发现，刷新一次缓存的时间竟然要15min。缓存是每隔10min整点刷一次，因为10min内刷不完，所以下次刷新就推迟到20min后，这就导致了上面这个图中，红线以上每20分钟的规律波形。

由于缓存刷新慢，也会很多请求无法命中缓存，请求直接穿透缓存打到DB，这部分请求给上图红线以下部分，做很多“贡献”。

找到了问题原因，做针对性的优化，问题很快解决：

img

2 如何避免悲剧重演

问题原因在于开发犯了错误，编写SQL没有考虑数据量和执行时间，缓存使用也不合理。最终导致在忙时，大量查询打到MySQL，MySQL繁忙无法提供服务。总结经验：

编写SQL要谨慎评估。问自己：

• 你的SQL涉及到的表，它的数据规模多少
• 你的SQL可能遍历的数据量多少
• 尽量避免写慢SQL

能不能利用缓存减少DB查询次数？使用缓存时，还要注意缓存命中率，要尽量避免请求命中不了缓存，穿透到DB。

优秀的系统架构，可以在一定程度上，减轻故障对系统的影响。针对这次事故，我给这个系统在架构层面，提了建议。

上线一个定时监控和杀掉慢SQL的脚本。这个脚本每分钟执行一次，检测上一分钟内，有没有执行时间超过一分钟（这个阈值可以根据实际情况调整）的慢SQL，如果发现，直接杀掉这会话。这有效避免一个慢SQL拖垮整个数据库。即使慢SQL，数据库也可以在至多1分钟内自动恢复，避免数据库长时间不可用。代价是，可能会有些功能，之前运行是正常的，这个脚本上线后，就会出现问题。但是，这个代价还是值得付出的，并且，可以反过来督促开发人员更加小心，避免写慢SQL。

做一个简单的静态页面首页作为降级方案，只要包含商品搜索栏、大的品类和其他顶级功能模块入口的链接。在Nginx做个策略，如果请求首页数据超时的时候，直接返回这个静态的首页作为替代。这样后续即使首页再出现任何的故障，也可以暂时降级，用静态首页替代。至少不会影响到用户使用其他功能。

这两个改进建议都是非常容易实施的，不需要对系统做很大的改造，也立竿见影。

当然，这个系统的存储架构还有很多可以改进的地方，比如说对数据做适当的隔离，改进缓存置换策略，做数据库主从分离，把非业务请求的数据库查询迁移到单独的从库上等等，只是这些改进都需要对系统做比较大的改动升级，需要从长计议，在系统后续的迭代过程中逐步地去实施。

总结

1. 根据故障时段在系统忙时，推断出故障是跟支持用户访问的功能有关。
2. 根据系统能在流量峰值过后自动恢复这一现象，排除后台服务被大量请求打死的可能性。
3. 根据CPU利用率曲线的规律变化，推断出可能和定时任务有关。

在故障复盘阶段，除了对故障问题本身做有针对性的预防和改进以外，更重要的是，在系统架构层面进行改进，让整个系统更加健壮，不至于因为某一个小的失误，就导致全站无法访问。

我给系统提出的第一个自动杀慢SQL的建议，它的思想是：系统的关键部分要有自我保护机制，避免外部的错误影响到系统的关键部分。第二个首页降级的建议，它的思想是：当关键系统出现故障的时候，要有临时的降级方案，尽量减少故障带来的影响。

这些架构上的改进，虽然并不能避免故障，但是可以很大程度上减小故障的影响范围，减轻故障带来的损失，希望你能仔细体会，活学活用。

FAQ

什么样的SQL算是慢SQL？如何才能避免写出慢SQL？

慢SQL 我感觉也没有个人标准，个人的标准也要分场景，业务复杂度等；如果作为常规的用户业务系统，超过1秒就是慢SQL；但是如果是类似生成报表的服务，选择在业务低峰期，从库执行等策略，时间长点也不是不能接受。 避免慢SQL：第一点肯定想到的是合适的索引，毕竟SQL执行速度的快慢关键还是语句需要扫描数据的行数，如尽量不要使用 对where 条件列进行计算的做法让MySQL查询优化器不知道怎么选择索引，特定业务 可以设置联合索引让需要查询返回的列都在索引中避免回表操作。 第二：排序也是可能完成慢SQL的因素，尤其是数据量大，需要使用外部排序的时候又可以与磁盘IO性能扯上关系等，常见的问题还有limit m,n m很大又无法使用索引的时候 第三：多表联合查询的时候，尽量使用小表驱动大表。 第四：避免大事务，这也是发生死锁常见的雷区，尽量减小事务粒度，尽量注意不同事务对表操作的顺序一致，大事务其实也包含着批量操作的隐式事务，如一个update 影响100万行数据。

第五：见过的关于架构方面的慢SQL问题 1～数据量到达一定规模后，单机性能容易受限导致数据库响应慢；2～读写分离，从库提供读服务，错误的认为从库只需要提供查询服务采用了达不到性能指标的机器，其实是主库承受的数据更新压力，从库一个不落的都要承受，还要更多的提供查询服务

上面那个小型创业公司的微服务架构，想知道有关 Nginx 的主备是怎么实现的？

我们例子里面当时它采用的就是人肉冷备，主节点出问题的时候人肉切换到备用节点上。

其实更合理的做法是做通过负载均衡器或者域名把流量均匀的打到多个NGINX节点上，配合探活机制，当某个节点有问题的时候，自动摘掉这个节点。

做一个Mysql的本地熔断方案。就是监控对每一个表的操作语句，通过机器数量在配置中心配置每个服务的访问频次、访问时间等。比如Mysql的TPS是4000，我们有10台机器，平均下来每个服务的上限为400/s。碰到超限、或者超慢的情况就熔断、告警。可以整体监控，也可以对热点表进行监控，这种方案是否可行？

必须可行啊。但要注意一下配置中心的高可用。别出现因为配置中心宕机，导致不能熔断了。

当第一个慢查询SQL处理完成后，MySQL的CPU使用率已经降到了20%以下。那么即便会有周期性的SQL执行，但是以这个利用率不足以整体导致服务不可用吧。

20%左右那个是闲时的图，忙时依然是100%。

为什么后台服务被大量请求打死的话无法自动恢复呢？

一般“服务被打死”，比较常见的情况是内存溢出、栈溢出或者进程直接挂掉，这些情况都是不能自动恢复的。

案例中用的什么cache，怎么refresh的？

案例中用的是Memcached，刷新的策略也是根据不同业务有不同的策略。

慢SQL要以业务场景来区分。例如做即时通讯或者消息类等有实时性要求的，可能2秒就算慢查询了，但是读从库做大数据分析的场景，可能跑一个小时也不算慢。另外，对于请数量大的时候，如果存在多个请求会加锁，即使一个查询是毫秒级别的，上百个查询访问一个热数据加锁也会有很大的问题，所以，没有慢查询的具体标准，影响到业务，拖慢了服务的，就算慢查询。

作者文中描述的问题可以理解成就是缓存更新慢，导致的缓存穿透

\1. 缓存热点数据 ： 因为使用连表查询等复杂语句在数据量大的时候会产生慢差 。是否该考虑修改查询语句或者上搜索（es / 阿里open search ) 然后再加一道缓存 缓存的读写策略采用旁路策略。

\2. 像这种定时任务应该大部分公司都会有很多，一般都是放到凌晨来执行 ，经常会有人问当数据量大的时候 这种定时任务是否可行。 所以像数据量非常大（京东这种级别数据） 定时任务扫表是否还可行 有没有其他的解决思路

这种大查询，首先肯定是要用缓存，但要根据实际情况选择合适的缓存更新策略。

数据量特别大的统计分析，一般选择放到其它分析型数据库或者数据仓库中去执行，或者使用流计算来解决。

首页缓存过期时间要设置一个随机值，不然会造成缓存雪崩。

重构:用自己的话，重述内容

对于一次系统高峰时段出现的问题，从排查分析到解决，到复盘总结，过程的一次演练。 根据出现的时间段，分析出是用户请求超时导致的结果，进而对系统中的慢sql进行分析，分析出慢sql之后进行修复，从数据库cpu使用率上分析出定时任务的存在，并分析出定时任务的周期，至此问题解决。但在复盘的时候从架构的层次进行了更为本质的分析，并给出数据库慢sql的预处理模式，数据库分离的建议以及页面降级预案。

架构上有自我保护机制这点学习了。这个例子中，我觉得应该打开代码层面的数据库模块的日志开关，例如mybatis有拦截器可以记sql语句和数量，应该能根据sql语句看到异常的sql(首页请求没命中缓存），或者选取2个时间段，一个有问题，一个没问题，把同类sql按总数量大小从大到小用表格比一下，应该也能发现问题。日志是非常重要的一环。