高并发服务性能优化

一、性能优化手段

1.空间换时间

特点：系统时间是瓶颈

如：缓存复用计算结果，降低时间开销，因为CPU时间较内存容量更加昂贵。

2.时间换空间

特点：数据大小是瓶颈

如：网络传输是瓶颈

使用系统时间换取传输的空间，使用http的gzip压缩算法

如：App的请求分类接口，

使用版本号判断哪些数据更新，只下载更新的数据。

3.找到系统瓶颈

3.1.分析系统业务流程，找到关键路径并分解优化

3.2.一个服务集群4w的QPS，调用量前5的接口贡献了3.5w的QPS

3.3.对关键路径的代码优化收益最大，当然系统剩下的问他也 不能忽视，比如剩下的5k qps接口若性能有问题

也可能把整体服务性能拖垮。

总之：调用了多少RPC接口，载入了多少数据，使用了什么算法，非核心流程能否异步化，没有数据依赖的逻辑能否并行执行。

二、性能优化层次

1.架构设计层次

1.1.关注系统控制、数据流程

1.2.如何拆分系统，如何使各部分系统整体负载更加均衡，充分发挥硬件设施性能优势，减少系统内部开销等

2.算法逻辑层次

2.1.关注算法选择是否高效，算法逻辑优化，空间时间优化任务并行处理，使用无锁数据结构等。

时间密集型利用空间换时间

2.2.空间换时间

    如:ThreadLocal在线程内部进行共享

2.3.时间换空间：

    采用压缩算法压缩数据，更复杂的逻辑减少数据传输

3.代码层次优化

3.1.关注代码细节优化，代码实现是否合理，是否创建了过多的对象，手环遍历是否高效，Cache使用是否合理，是否重用计算结果等。

3.2.循环遍历是否合理高效， 不要在循环里调用RPC接口、查询分布式缓存、执行SQL等

注：先调批量接口组装好数据，再循环处理

3.3.代码逻辑避免生成过多对象或无效对象

注：输出log时候的log级别判断，避免new无效对象

3.4.ArrayList、HashMap初始容量设置是否合理

注：扩容代价

3.5.对数据对象是否合理重用，比如通过RPC查到的数据能复用则必须复用

3.6.根据数据访问特性选择合适数据结构，比如读多写少，考虑CopyOnWriteArrayList(写时Copy副本）

3.7.拼接字符串的时候是使用String相加还是使用StringBuilder进行append（在StringBuilder的容量预分配的情况下

StringBuilder的性能比String相加性能高15倍左右）

3.8.是否正确初始化数据。有些全局共享的数据，饿汉式模式，大用户访问之前先初始化好

总之：优化层次：从整体到细节，从全局角度到局部视角

4.数据库代码优化层次

4.1.数据建表语句能尽量小的数据结构

表的状态的字段，如果状态值在255以内使用unsigned tinyint， IP使用int而非varchar

4.2.使用enum的场景使用tinyint替代，enum扩展需要改表

4.3.避免使用select * 查询数据，只查询需要的字段，避免浪费数据IO、内存、CPU、网络传输

4.4.分析查询场景建立合适的索引，分析字段的可选择性，索引长度，对长的varchar使用前缀索引

4.5.字段尽量为NOT NULL类型，MySql手册说明允许NULL的字段需要额外的存储空间去处理NULL（见注解），并且很难查询优化。

4.6.目的为了降低服务器CPU使用率、IO流量、内存占用、网络消耗，降低响应时间。