抢购性能问题排查之一——数据库性能优化

1 线上问题的爆发

啥也不说了，先看看能不能保护好系统，给我们争取解决问题的时间吧。

增加限流功能，所有限流统计放在redis中操作，启动4台专用于限流查询的服务器。
页面都优先请求限流接口，被拒绝了，就等待5秒才允许继续访问。

2 定位问题

先把访问日志拿出来看了一下，请求数量有很多，直接针对接口并不是一个好办法。

所以，换个角度，从用户去操作的角度来看，哪个页面是用户并发访问最多的，那个页面就是要重点优化的对象。
取出该页面所有相关的操作，后台请求的数量也就是最多的请求，针对这些接口进行优化。

3 解决问题

3.1 数据库的制约性

不论我们上层怎么去搞微服务，底层数据我们只有一份，而且要准确一致的。因此这也成为了系统难以绕过的瓶颈。

有时候真的非常感叹阿里做的OceanDB，居然去从底层来解决这个异地存储一致性的问题。我们内部商量了一下，以后还是基于用户来做信息分段比较方便。

3.2 提升查询性能

说到数据库优化，第一反应肯定就是解决慢查询。把高峰时段的慢查询导出来进行分析调整。主要以下两个策略：

1. 优化慢查询的SQL语句
2. 增加更高效的索引

3.3 减少非必要操作

简单来说，就是做缓存。不停的去想还能怎么做，最后总结了几种思路。

1. 在页面层面，已经可以知晓的信息，直接使用本地数据，能不请求就不发请求
2. 对于页面中需要的一系列数据，尽量合并接口，避免多次请求
3. 微服务本身读多写少的数据进行缓存
4. 将定时脚本进行错峰执行

4 后记

非常搞笑的是，我们每优化完了一个页面，就会发现慢的地方就会集中到下一个步骤的页面，然后一直到我们把整个用户操作链路的页面都优化完，才把这个数据库层面的慢查询基本消灭