系统的性能优化--记项目总结

项目过去都3个多月了，也没系统的总结，今天总结一下

 

系统背景：

1.访问量大：每天承受20亿+服务调用

2.海量数据：核心表都是5亿条数据，而且每天还在以几十万的速度增加

3.之前架构：由于读写比例很高，已经采用分布式cache--db单点的架构

4.db负载高：在小机上，业务高峰期时，db的cpu的占用率曾达到70%-80%，响应明显变慢

5.业务特性：读写比例高，大部分业务可以接受细微的延迟。

 

目标：

1.高可用：去DB单点，app、cache、db任何一个节点宕机，不影响可用率

2.性能优化

 

新的架构：n个app--n个cache--1个写库--n个读库，除了去单点的功效，还在架构层面解决60%性能问题。

 

细节的优化措施：

1.将业务数据分级，核心数据还在db上，不重要&&写频率高的数据存入其他相对不重要的存储（比如登录、密码校验等一下优化了4000w次写）

2.cache，还是cache：对于互联网类型的业务，一般都是单个查询，较为方便构造缓存的key，最多2级key。绝大部分的数据，都放到了cache上。

3.空查比例较高的高并发的查询：采用布隆算法，或者cache中加入空对象表示业务上的空，防止数据穿透到db。

4.将若干关系紧密的表合并：对于我们的应用，虽然几张表表示不同的业务，但关系紧密，可以说95%的情况下，是查了一张表，必须查另外一张表的情况，而且查询频率非常之高。这样做的好处，从db层面，查询2张表减少为查询1张表，减少了io等不必要的操作。

5.构建批量查询：减少对db的多次请求和网络传输。

6.增加标志位，用于控制是否查询附属表：我们的模型比较复杂，存在3张附属表，这3张附属表，只有1%的用户具有这样的特性，每次构造模型时，用此标志位检查是否有此业务，减少查询

7.评估cache的失效时间：适当增加cache的失效时间，提升命中率

8.提供定制化查询服务：对于外围一些访问量比较高的系统，针对具体业务，提供批量查询。比如外围有些业务系统，一次业务要查询会员信息10次， 可以针对具体特性，开发单个接口，满足其业务需求，减少了服务调用。拿数据说话吧，现在每天查询从20亿-25亿次查询，优化到10亿次。