浅谈系统性能提升的经验和方法

一、背景

二、什么是高性能系统

三、从哪几个方面做好性能提升

• 如何设计高性能计算(CPU)

• 减少计算成本: 代码优化计算的时间复杂度O(N^2)->O(N)，合理使用同步/异步、限流减少请求次数等；
• 让更多的核参与计算: 多线程代替单线程、集群代替单机等等；

• 如何提升系统IO

• 加快IO速度: 顺序读写代替随机读写、硬件上SSD提升等；
• 减少IO次数: 索引/分布式计算代替全表扫描、零拷贝减少IO复制次数、DB批量读写、分库分表增加连接数等；
• 减少IO存储: 数据过期策略、合理使用内存、缓存、DB等中间件，做好消息压缩等；

四、高性能优化策略

1.1 减少程序计算复杂度

boolean result = true;// 循环遍历请求的requests, 判断如果是A业务且A业务未达到终态返回false, 否则返回truefor(Requet request: requests){     // 1. query DB 获取TestDO     String id = request.getId();     TestDO testDO = queryDOById(id);     // 2. 如果是A业务且testDO未到达中态记录为false     if(StringUtils.equals("A", request.getBizType())){         // check是否到达终态         if(!StringUtils.equals("FINISHED", testDO.getStatus)){             result = result && false;         }     }}return result;

1. 每次请求过来在第6行都去 查询DB，但是在第8行对请求做了判断和筛选，导致第6行的 代码计算资源浪费，而且第6行访问DAO数据，是一个比较耗时的操作，可以先判断业务是否属于A再去查询DB；

2. 当前的需求是只要有一个A业务未到达终态即可返回false, 11行可以在拿到false之后，直接break，减少计算次数；

boolean result = true;// 循环遍历请求的requests, 判断如果是A业务且A业务未达到终态返回false, 否则返回truefor(Requet request: requests){// 1. 不是A业务的不走查询DB的逻辑if(!StringUtils.equals("A", request.getBizType())){continue;     }     // 2. query DB 获取TestDO     String id = request.getId();     TestDO testDO = queryDOById(id);     // check是否到达终态     if(!StringUtils.equals("FINISHED", testDO.getStatus)){         result = false;         break;     }}return result;

1.2 合理使用同步异步

 



此时A系统- B系统- C系统已有的调用链路可能会超时失败，因为引入D系统之后，耗时增加了150ms，整个过程是同步调用的，因此需要C系统将调用D系统更新结论的非强依赖改成异步调用。

// C系统调用D系统更新结果featureThreadPool.execute(()->{   try{      dSystemClient.updateResult(resultDTO);   }catch (Exception exception){      LogUtil.error(exception, logger, "dSystemClient.updateResult failed! resultDTO = {0}", JSON.toJSONString(resultDTO));   }});

1.3 做好限流保护

1.4 多线程代替单线程

将这段代码改成异步执行，这样执行诊断的时间是耗时最大的诊断服务 

// 提交future任务并发执行futures = executor.invokeAll(tasks, timeout, timeUnit);// 遍历读取结果for (Future<Res> future : futures) {    try {        // 获取结果        Res singleResult = future.get();        if (singleResult != null) {            result.add(singleResult);        }    } catch (Exception e) {        LogUtil.error(e, logger, "并发执行发生异常!,poolName={0}.", threadPoolName);    }}

1.5 集群计算代替单机

 这里可以使用三层分发，将计算任务分片后执行，Map-Reduce思想，减少单机的计算压力。

2.1 常见的FullGC解决

 某一天修改了删除策略，从“删除上个月之前的数据”改成了“删除上周之前的数据”，因此删除的数据从1000条膨胀到了15万条，数据对象占用了80%以上的内存，直接导致系统的FullGC, 其他任务都有影响； 

A系统设置了static的List对象，本身是用来做DRM配置读取的，但是有个逻辑对配置信息做了查询之后，还进行了Put操作，导致随着业务的增长，static对象越来越大且属于类对象，无法回收，最终使得系统频繁GC 。

2.2 顺序读写代替随机读写

2.3 DB索引设计

2.4 分库分表设计



2.5 避免大量的表JOIN

如果为了业务上某些数据的级联，可以适当根据主键在内存中做嵌套的查询和计算，操作非常频繁的流水表建议对部分字段做冗余，以空间复杂度换取时间复杂度。 

2.6 减少业务流水表大量耗时计算

2.7 数据过期策略

一张表的数据量太大的情况下，如果不按照索引和日期进行部分扫描而出现全表扫描的情况，对DB的查询性能是非常有影响的，建议合理的设计数据过期策略，历史数据定期放入history表，或者备份到离线表中，减少线上大量数据的存储。 

2.8 合理使用内存

 说到内存，就会有数据一致性问题，DB数据和内存数据如何保证一致性，是强一致性还是弱一致性，数据存储顺序和事务如何控制都需要去考虑，尽量做到用户无感知。

2.9 做好数据压缩

2.10 Hbase热点key问题

5. 暂时不能支持Master server的故障切换，当Master宕机后，整个存储系统就会挂掉。

• 反转： 比如用户ID2088这种前缀，以及BBCRL开头的这种相同前缀，都可以适当的反转往后移动。
• 加盐： RowKey 的前面增加一些前缀，比如时间戳Hash，加盐的前缀种类越多，才会根据随机生成的前缀分散到各个 region 中，避免了热点现象，但是也要考虑scan方便

• 哈希： 为了在业务上能够完整地重构 RowKey，前缀不可以是随机的。 所以一般会拿原 RowKey 或其一部分计算 Hash 值，然后再对 Hash 值做运算作为前缀。

五、实战-应急链路系统设计方案

以资金应急系统为例分析系统设计过程中的性能优化。如下图所示，异常处理系统涉及到多个上游App(1-N)，这些App发“差异日志数据”给到消息队列, 异常处理系统订阅并消费消息队列中的“错误日志数据”，然后对这部分数据进行解析、加工聚合等操作，完成异常的发送及应急处理。 

• 发送阶段高可用设计

• 生产消息阶段： 本地队列缓存异常明细数据，守护线程定时拉取并批量发送（优化方案1中单条上报的性能问题）

• 消息压缩发送： 异常规则复用用一份组装的模型，按照规则则Code聚合压缩上报（优化业务层数据压缩复用能力）

• 中间件帮你做好了消息的高效序列化机制以及发送的零拷贝技术

• 存储阶段

• 目前Kafka等中间件，采用IO多路复用+磁盘顺序写数据的机制，保证IO性能
• 同时采用分区分段存储机制，提升存储性能

• 消费阶段

• 定时拉取一段数据批量处理，处理之后上报消费位点，继续计算

• 内部好做数据的幂等控制，发布过程中的抖动或者单机故障保证数据的不重复计算

• 为了提升DB的count性能，先用Hbase对异常数量做好累加，然后定时线程获取数据批量update

• 为了提升DB的配置查询性能，首次查询配置放入本地内存存储20分钟，数据更新之后内存失效



• 对于统计类的计算采用explorer存储，对于非结构化的异常明细采用Hbase存储，对于结构化且可靠性要求高的异常数据采用OB存储

1. 然后对系统的性能做好压测和容量评估，演练数据是异常数据的3-5倍做好流量隔离，对管道进行拆分，消费链路的线程池做好隔离 

2. 对于单点的计算模块做好冗余和故障转移, 采取限流等措施

3. 对于系统内部可以提升的地方，可以参考高可用性能优化策略去逐个突破。

六、高性能设计总结

1.1 冗余能力

1.2 故障转移能力

1.3 系统资源隔离性

2.1 做好监控

2.2 做好限流/熔断/降级等

2.3 提升代码质量