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

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

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

1 单机

2单机+云数据库

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

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

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

由于咱们的小程序有不多图片文件，没有考虑CDN和oss文件存储

硬件不够用了就升级，不过能够一个月一个月的买，否则太贵了

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

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

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

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

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

未完待续

四、小程序矩阵　　社交类小程序免不了分享之类的操做，使用多个小程序部署，小程序之间使用unionid互通，减少微信忽然抽风封你功能或小程序带来的损失

五、业务代码优化   

六、数据库表结构问题

为了不过多的join联合查询，能够采起以空间换时间的策略，例如用户的出题表，确定会存用户的id，而后再根据id去用户表里查昵称，若是只是查昵称就不划算了，干脆在出题表里也存昵称，就不用去用户表里查询了，只是举个例子

七、前端提交数据过滤

前端数据过滤及验证，虽然并不能保证100%安全，但能大大的减小bug出现的风险和可能大大减小服务器的压力

八、上千万条记录甚至上亿记录的大表，不要使用limit分页查询，即便有索引，速度必定慢到怀疑人生，通常相似的需求，不如直接使用主键的区间，例如十万的区间按主键取数据，id 1~100000,100000~200000，以此类推，这样的取 

九、开发时不少人都有喜欢处处记日志的习惯，问题这些日志隐藏在代码中，也不影响使用，但当访问量多起来，这些日志文件动辄就达到上G的大小，浪费磁盘空间和IO，要是只是错误日志也就罢了

十、各类手机设备的兼容性问题