这份避坑指南请收好 访问数据库总超时

01意外排查环节

电商公司大都宿愿做社交引流，社交公司大都宿愿做电商，从而将流质变现，所以社交电商不时是抢手的守业方向。这个实在的案例来自某家做社交电商的守业公司。上方就来一同看下这个典型的数据库超时案例。

从圣诞节安康夜开局，每天早晨固定十点到十一点这个期间段，该公司的系统会瘫痪一个小时左右的期间，过了这个期间段，系统就会智能复原反常。系统瘫痪时，网页和App都打不开，数据库服务恳求超时。

如图1所示，该公司的系统架构是一个十分典型的小型守业公司的微服务架构。

图1　典型的小型守业公司系统架构

该公司将整个系统托管在私有云上，Nginx作为前置网关承接前端的一切恳求。后端依据业务，划分了若干个微服务区分启动部署。数据保管在MySQL数据库中，部分数据用Memcached做了前置缓存。数据并没有依照微服务最佳通常的要求，启动严厉的划分和隔离，而是为了繁难，寄存在了一同。

这种存储设计形式，关于一个业务变动极快的守业公司来说是比拟正当的。由于它的每个微服务，随时都在随着业务需求的变动而出现扭转，假设做了严厉的数据隔离，反而不利于应答需求的变动。

开局剖析这个案例时，我首先留意到的一个关键现象是，每天早晨十点到十一点这个期间段，是绝大少数内容类App访问量的高峰期。由于这个期间段很多人都会躺在床上玩手机，因此我初步判别，这个缺点或许与访问量无关。图2所示的是该系统每天各个期间段的访问量趋向图，正好可以印证我的初步判别。

图2　系统访问量

基于这个判别，排查疑问的重点应该放在那些服务于用户访问的配置上，比如，、商品列表页、内容介绍等配置。

在访问量到达峰值的时刻，恳求所有超时。而随着访问量的增加，系统又能智能复原，因此基本上可以扫除后盾服务被少量恳求冲垮，进程僵死或分开的或许性。由于假设进程出现这种状况，普通是不会智能复原的。排查疑问的重点应该放在MySQL上。

观察图3所示的MySQL主机各时段的CPU应用率监控图，咱们可以发现其中的疑问。从监控图上可以看出，缺点时段MySQL的CPU应用率不时是100%。这种状况下，MySQL基本上处于无法用的形态，口头一切的SQL都会超时。在MySQL中，这种CPU应用率高的现象，绝大少数状况下都是由慢SQL造成的，所以须要优先排查慢SQL。MySQL和各大云厂商提供的RDS(相关型数据库服务)都能提供慢SQL日志，剖析慢SQL日志，是查找形成相似疑问的要素最有效的方法。

图3　MySQL主机各时段的CPU应用率监控图

普通来说，慢SQL日志中，会蕴含这样一些信息：SQL语句、口头次数、口头时长。经过剖析慢SQL查找疑问，并没有什么规范的方法，关键还是依托阅历。

首先，咱们须要知道的一点是，当数据库十分忙的时刻，任何一个SQL的口头都会很慢。所以并不是说，慢SQL日志中记载的这些慢SQL都是有疑问的SQL。大部分状况下，造成疑问的SQL只是其中的一条或几条，不能繁难地依据口头次数和口头时长启动判别。然而，单次口头期间特意长的SQL，依然是应该重点排查的对象。

经过剖析这个系统的慢SQL日志，我首先找到了一条特意慢的SQL。以下代码是这条SQL的完整语句：

7andfo.CreateTime19order

这条SQL撑持的配置是一个“网红”排行榜，用于陈列出“粉丝”数最多的前10名“网红”。

请留意，这种排行榜的查问，必定要做缓存。在上述案例中，排行榜是新上线的配置，由于没有做缓存，造成访问量高峰期间段服务卡死，因此参与缓存应该可以有效处置上述疑问。

为排行榜参与缓存后，新版本立刻上线。本认为疑问就此可以获取处置，结果到了晚高峰期间段，系统依然出现了各种恳求超时，页面打不开的疑问。

再次剖析慢SQL日志，我发现排行榜的慢SQL不见了，说明缓存失效了。日志中的其余慢SQL，查问次数和查问时长的散布都很平均，找不到显著有疑问的SQL。

于是，我再次检查MySQL主机各时段的CPU应用率监控图，如图4所示。

图4　系统参与缓存后，MySQL主机各时段的CPU应用率

把图加大后，我又从中发现了如下两点法令。

1)CPU应用率，以20分钟为周期，十分有法令地启动动摇。

2)总体的趋向与访问量正相关。

那么，咱们是不是可以猜想一下，如图5所示，MySQL主机的CPU应用率监控图的波形关键由两个部分形成：参考线以下的部分，是反常处置日常访问恳求的部分，它与访问量是正相关的;参考线以上的部分，来自某个以20分钟为周期的定时义务，与访问量相关不大。

图5　系统参与缓存后，MySQL主机各时段的CPU应用率(附带参考线)

排查整个系统，并未发现有以20分钟为周期的定时义务，继续扩展排查范围，排查周期小于20分钟的定时义务，最后终于定位到了疑问所在。

该公司App的聚合了少量的内容，比如，精选商品、题目图、排行榜、编辑介绍，等等。这些内容会触及少量的数据库查问操作。该系统在设计之初，为做了一个全体的缓存，缓存的过时期间是10分钟。然而随着需求的不时变动，上须要查问的内容越来越多，造成查问的所有内容变得越来越慢。

经过审核日志可以发现，刷新一次性缓存的期间居然长达15分钟。缓存是每隔10分钟整点刷新一次性，由于10分钟内刷不完，所以下次刷新就推早退了20分钟之后，这就造成了图5中，参考线以上每20分钟一个周期的法令波形。由于缓存的刷新比拟慢，造成很多恳求无法命中缓存，因此少量恳求只能穿透缓存间接查问数据库。图9-5中参考线以下的部分，蕴含了很多这类恳求占用的CPU应用率。

找到了疑问的要素所在，上方就来启动针对性的优化，疑问很快就获取了处置。新版本上线之后，再也没有出现过“午夜宕机”的疑问。如

图6所示，对比优化前后MySQL主机的CPU应用率，可以看出，优化的成果十分显著。

图6　优化前后MySQL主机的CPU应用率对比

02如何防止喜剧重演

至此，造成疑问的要素找到了，疑问也获取了圆满处置。单从这个案例来看，疑问的要素在于，开发人员在编写SQL时，没有思索数据量和口头期间，缓存的经常使用也不正当。最终造成在访问高峰期时，MySQL主机被少量的查问恳求卡死，而无法提供服务。

作为系统的开发人员，关于上述疑问，咱们可以总结出如下两点阅历。

第一，在编写SQL的时刻，必定要小心审慎、细心评价，首先思索如下三个疑问。

第二，能不能应用缓存减少数据库查问的次数?在经常使用缓存的时刻，咱们须要特意留意缓存命中率，应尽量防止恳求由于命中不了缓存，而间接穿透到数据库上。

不过，咱们无法保障，整个团队的一切开发人员都不会再犯这类错误。然而，这并不象征着，上述疑问就无法防止了，否则大企业的服务系统会由于每天上线少量的BUG而无法反常上班。实践状况是，大企业的系统通常都是比拟稳固的，基本上不会出现全站无法访问的疑问，这要归功于其低劣的系统架构。低劣的系统架构，可以在必定水平上，减轻缺点对系统的影响。

针对这次意外，我在系统架构层面，为该公司提了两条改良的倡导。

第一条倡导是，上线一个定时监控和杀掉慢SQL的脚本。这个脚本每分钟口头一次性，检测在上一分钟内，有没有口头期间超越一分钟(这个阈值可以依据实践状况启动调整)的慢SQL，假设发现，就间接杀掉这个会话。

这样可以有效地防止由于一个慢SQL而拖垮整个数据库的喜剧。即使出现慢SQL，数据库也可以在至少1分钟内智能复原，从而防止出现数据库长期间无法用的疑问。不过，这样做也是有代价的，或许会造成某些配置，之前运转是反常的，在这个脚本上线后却出现了疑问。然而，总体来说，这个代价还是值得付出的，同时也可以反上来催促开发人员，使其愈加小心审慎，防止写出慢SQL。

第二条倡导是，将首面做成一个繁难的静态页面，作为升级打算，上只需蕴含商品搜查栏、大的品类和其余顶级配置模块入口的链接就可以了。在Nginx上成功一个战略，假设恳求数据超时，则间接前往这个静态页面的作为代替。后续即使再出现任何缺点，也可以暂时升级，用静态代替，至少不会影响到用户经常使用其余配置。

这两条改良倡导的实施都是十分容易的，不须要对系统启动很大的变革，而且成果也是空谷传声的。

当然，这个系统的存储架构还有很多可以改良的中央，比如，对数据做适当的隔离，改良缓存置换战略，将数据库更新为主从部署，把非业务恳求的数据库查问迁徙到独自的从库上，等等，只是这些改良都须要对系统做出比拟大的改动更新，须要从长计议之后再在系统后续的迭代环节中逐渐实施。

03小结

本文剖析了一个由于慢SQL造成网站主机访问缺点的案例。在“破案”的环节中，我分享了一些很有用的阅历，这些阅历关于大家在上班中遇到相似疑问时会有很大的参考作用。上方再来梳理一下这些阅历。

1)依据缺点时段出如今系统忙碌时这一现象，推断出缺点要素与允许用户访问的配置无关。

2)依据系统能在流量峰值事先智能复原这一现象，扫除后盾服务被少量恳求冲垮的或许性。

3)依据主机的CPU应用率曲线的法令变动，推断出缺点要素或许与定时义务无关。

在缺点复盘阶段，咱们针对缺点疑问自身的要素，做了针对性的预防和改良，除此之外，更关键的是，在系统架构层面也启动了改良，整个系统变得愈增强健，不至于由于某个小的错误，就造成出现全站无法访问的疑问。

我为该系统提出的第一个倡导是定时智能杀死慢SQL，要素是：系统的关键部分要有自我包全机制，以防止由于外部的错误而影响到系统的关键部分。第二个倡导是升级，要素是：当关键系统出现缺点的时刻，要有暂时的升级打算，以尽量增加缺点形成的不良影响。

这些架构上的改良措施，只管不能齐全防止缺点，然而可以在很大水平上减小缺点的影响范围，减轻缺点带来的损失，宿愿大家能够细心体会，活学活用。

关于作者：李玥，美团基础技术部初级技术专家，极客期间《后端存储实战课》《信息队列高手课》等专栏作者。曾在当当网、京东批发等公司任职。从事互联网电商行业基础架构畛域的架构设计和研发上班多年，曾屡次介入双十一和618电商大促。专一于散布式存储、云原生架构下的服务控制、散布式信息和实时计算等技术畛域，努力于推动基础架构技术的翻新与开源。