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

项目过去都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亿次。

 

 

 

你可能感兴趣的:(性能优化)