5000万pv小程序，高并发及缓存优化，入坑

Posted 2020-11-01 听风且雨

小程序日均5000万的pv，超出想象，流量一路涨上来，服务器压力太大，各种宕机，不得不开始各种优化。

首先硬件的升级是必不可少，是革命的本钱，硬件升级如下

1 单机

2单机+云数据库

3单机+云数据库+6G的redis缓存

4五台服务器负载均衡 + 云数据库多台主从读写分离 + 16G的redis缓存

5十台服务器负载均衡 + 云数据库多台主从读写分离 + 32G的redis缓存

因为我们的小程序有很少图片文件，没有考虑CDN和oss文件存储

硬件不够用了就升级，不过可以一个月一个月的买，不然太贵了

下面的按一条一条的写，想到哪里写哪里。

1、分析瓶颈，小程序是兄弟公司的新手做的，不过效果还挺好，拿到我们这边来推广，没想到流量一路上涨。当流量多了以后，首先系统的瓶颈出现在数据库，查询很慢，看了看表，索引做的不好，甚至有些关键的地方都没有索引，赶紧加上索引。

数据库的压力刚缓解一会，服务器cpu的占用一直在90%以上，甚至出现宕机，分析了一下业务，我们的小程序主要是社交出题答题类的，并没有很高的计算需求，也就在最后用户生成分享图片的地方会有计算压力，果然在从单机扩展到负载均衡以后，服务器的cpu没有再出现过压力。从此压力主要围绕在数据的读和存这一块，也就是数据库和redis压力

2、redis是个好东西，每次能正确的缓存常用的数据，数据库的压力就能减轻很多。redis有两种缓存思想，一是针对数据库缓存，在用户写入数据的时候例如出题、答题，往数据库和redis中都写入，查询的时候先插redis的数据，没有的话从数据库中取；二是针对接口缓存，直接缓存接口返回的json数据，用户再次查相同的内容，直接返回json数据。我个人比较喜欢第二种缓存方式，简单高效，但要针对数据不怎么变化的接口，根据查询条件生成合理的redis key值，还要设置合理的过期时间，不然数据量太大。例如有一个接口是用户查询自己之前出的题及正确答案，因为自己出的题不可能再变，就根据他的这一套题的id进行缓存；

3、负载均衡，将流量分发到不同的服务器上进行处理，对cpu的压力大大减轻，但因为数据库的数据要共享，只能用云数据库，对数据库的帮助不明显

未完待续

4、小程序矩阵

5、业务代码优化

6、数据库表结构问题

7、前段提交数据过滤