性能优化记录

性能优化记录

先直接列出优化后的成果吧
* 数据库qps从5K下降到2K
* 数据库机器CPU使用率从80%下降到30%

问题根源

• 数据库相关不存在记录，查完DB后没有设置缓存直接返回，导致每次cache miss
• 没有分析具体业务场景

优化过程

业务上线后，数据库的qps一直保持在较高的水平，cpu的占用率也一直很高。通过和DBA沟通交流后，发现某一类型的SQL请求一直占据绝大部分。业务是评论系统，用户每次打开网页后都会加载评论列表，通过监控数据库查询发现，数据库访问量最大的是查询用户是否对页面下的评论已经点赞。照理说查询用户是否点赞信息只有用户第一次访问的时候会进行数据库查询，查询完数据库后将点赞列表加载进缓存，以后每次请求都可以直接从缓存获取点赞列表，数据库的点赞查询不可能这么多。
但是仔细分析业务后发现，对评论点赞用户占总用户的数量微乎其微，90%以上的用户在数据库根本没有对评论的点赞记录，因此用户第一次访问时虽然查询了数据库，但是因为数据库中没有记录，所以并不会在缓存中加载点赞列表，用户后续的每次访问还是会继续查询数据库。这就会导致大量的缓存不命中，数据库压力自然也就上去了。
解决方法其实也很简单，就是在用户第一次访问查询的时候，由于是第一次访问，肯定会导致cache miss进而查询DB，但是之前的逻辑是只有DB有结果的时候才设置缓存。优化的方法就是如果DB返回的数据为空，那么就初始化一个默认的数据，并加载进缓存，这样用户下一次查询的时候，会直接根据用户id在缓存中命中，因为命中的结果是默认初始化的值，说明用户并没有相关的记录，可以直接返回而不必再去查询数据库。这样自然就会大量减少DB的请求

总结

• 业务出现问题时，需要根据具体业务场景进行分析
• 多和DBA沟通，加强DB的查询监控，根据监控热点进行相应的优化处理

遗留的问题

由于优化的方法是即使用户不存在记录，也在缓存中为用户设置一个key，这相对之前的方法很明显一下子增加的90%的key。很有可能导致缓存不够用