故障描述

1.双十一高峰前的新功能上线，距离封版还有两天时间，准备把新功能版本数据上线。测试环境已测试通过，准备上线，开始灰度环境验证，也是没问题。检查数据也是正常,开始正式发布，因为排名需要重新计算，清除生产缓存数据。过了10分钟监控开始报警，服务不可用，db数据库也开始报警，数据库连接池配置200，一启动完成数据库连接池就被用完。

故障排查

首先想到是新功能版本代码的问题，马上联系运维，代码回滚到历史正常的版本，开始观察。发现服务已经起不来了。连续dba查看数据库连接情况，发现数据库已经连不上了，只能重启数据库。数据库启动完成之后再次启动服务，已经可以正常启动，先启动一个节点，发现数据库连接又全部占用。服务又可用。归滚，重启大法都无效！！！！
第一次开始想到是分布式锁的问题，是不是锁时间太长，执行的事务没有释放，先排查代码。
同步查看监控慢sql，运维开始查占用连接的执行的sql，最后发现是计算排行榜的SQL执行一直占用连接。问题定位到开始排查代码，排名榜的数据一直都是做T+1计算，为啥这次会出这个问题，开始review代码。发现排行榜数据读的是缓存数据，缓存不存在开始计算排行榜数据。 这里是巨大坑，不应该在此计算，sql在数据量较少时候并没有发现问题，（数据每月/100多万）现在数据量已经到700多万的数据。再次检查其实这里代码是存在很多问题，缓存失效，sql复杂，也是迟早会暴露出来。一次缓存删除导致问题提前暴露出来。
从问题发现到解决花了两个多小时时间，活生生的经验啊。

问题解决

首先把计算逻辑先干了，不做复杂sql排名操作，优化代码。

总结

  • 类似排名或者其他复杂的sql，但在前期这块的设计上没有把关好，没意识到这里的风险，服务的请求应该是的结果数据，不应该实时去计算。
  • 风险意识需要加强，功能灰度是十分必要的。
  • 生产缓存数据设计一定要思考好，哪些是能删除哪些不能随意删除，不能随意删除生产缓存数据。
  • 发版风险没管控好。