上线后线上cpu持续跑满。查看日志发现很多连接获取不到的错。定位出错代码行数是定时轮询获取经纬度位置表查询时间过长。
再去看这个表发现致命错误：自动分裂的表id不是主键？？？？
再接着explain一下根据id获取一条记录，是全表扫描。
准备重建一下主键索引，还好不是业务高峰期，哪怕锁表占用时间过长也能接受。
试着设定主键，问题又来了：id有重复值，无法设定id为unique主键。
思考了一会，位置信息表一共有4张，直接在线上操作风险很大，这几张表都是几百万的记录，直接执行删除重复id的sql执行会很慢很慢。 上线时间是晚上，基本不会有查询位置的业务操作。
解决思路：复制一个空库，线上先指向空库，保证线上能跑通，暂时查不了数据，等处理完重复数据后建主键索引切回原库，将增量的数据再拷贝回去。
结果：指向空库，写了去重的脚本跑了一晚上，第二天来切回主库建好索引后，仍然cpu很高。因为数据量大，还好提前想好了应对方法，轮询的方法里加了redis缓存。
再次上线：第一次轮询cpu还是跑满的，因为redis没缓存，全打到数据库里了。第二次轮询基本就正常了。过了几轮cpu又阶段性跑满：因为redis缓存失效的时间都差不多，导致阶段性的全打到数据库里。解决方案：让redis缓存失效的时间分散些，随机数。
总结：轮询等大量请求数据库的功能，要做好缓存。注意1：缓存设置和更新的调用处 2：缓存和数据库同步3:第一次上线前，要提前把缓存写进去，防止瞬间大量请求4：缓存失效的时间，防止瞬间所有缓存失效
网友评论