探索从5秒到20毫秒的性能优化技巧，提升系统效率的优雅方法与策略

什么是高性能系统

首先，我们需要明确高性能设计的概念。官方定义为：高可用性（High Availability, HA）的核心目标是确保业务的连续性，从用户的角度来看，服务始终稳定正常。业界通常使用几个9（如99.9%）来衡量系统的可用性，通常通过一系列专门的设计，如冗余、消除单点故障等，减少业务停工时间，从而保持其核心服务的高度可用性。

高并发（High Concurrency）指的是系统能够并行处理大量请求。通常通过响应时间、每秒事务数（TPS）、并发用户数量等指标来评估。

**高性能则指的是程序处理速度极快，内存占用低，CPU利用率也较低。**高性能指标通常与高并发指标密切相关，因此提高性能的关键在于增强系统的并发能力。

本文将重点介绍和分享如何设计“高性能、高并发、高可用”的服务。

从哪些方面提升性能

每当谈到高性能设计，常常会涉及一些名词：IO多路复用、零拷贝、线程池、冗余等等。关于这些内容的文章很多，但实际上这是一个系统性的问题。系统优化离不开计算能力（CPU）和存储性能（IO）两个维度，我们可以总结如下：

1. 如何设计高性能计算（CPU）？

降低计算成本：通过优化代码降低时间复杂度，例如将O(N^2)优化为O(N)，并合理使用同步/异步、限流等方式减少请求次数；
让更多核心参与计算：通过多线程替代单线程、集群替代单机等方式。

2. 如何提升系统的IO？

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

高性能优化策略

计算性能优化策略

减少程序计算复杂度

让我们简单分析一下以下的伪代码（业务代码 facade 已去除敏感信息）：

boolean result = true;  
// 循环遍历请求的requests, 判断如果是A业务且A业务未达到终态返回false, 否则返回true  
for(Request 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;

在这段代码中存在一些明显的问题：

每次请求到来时，在第6行都去查询数据库，而在第8行对请求进行了判断和筛选，导致第6行的计算资源浪费，且访问DAO的数据是一个耗时的操作，应该先判断业务是否属于A再去查询数据库；
当前需求只需判断是否有业务A未达到终态即可返回false，因此在11行可以在获得false后直接break，减少计算次数。

优化后的代码如下：

boolean result = true;  
// 循环遍历请求的requests, 判断如果是A业务且A业务未达到终态返回false, 否则返回true  
for(Request 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;

优化后的计算耗时从平均270.75ms降低至40.5ms。

日常优化代码时，可以利用ARTHAS工具分析程序的调用耗时，对耗时较大的任务进行过滤，减少不必要的系统调用。

合理使用同步与异步

分析业务链路，明确哪些操作需要同步等待结果，哪些操作可以异步处理。核心依赖的调度应采用同步，而非核心依赖则应尽量采用异步。

举个场景：A系统调用B系统，B系统再调用C系统完成计算并将结果返回A，假设A系统超时时间为400ms，通常A系统调用B系统耗时300ms，B系统调用C系统耗时200ms。同时，C系统需要将调用结果返回给D系统，耗时150ms。

此时，A-B-C的现有调用链路可能会因为引入D系统而超时失败，因此应将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));  
    }  
});

做好限流保护

在故障场景中，A系统调用B系统查询异常数据，日常的调用频率大约在10TPS左右，但某一天因为代码bug和定时任务触发逻辑的变更，导致调用频率骤升至500TPS，并且由于ID传错，绕过了缓存直接查询数据库和Hbase，造成Hbase读热点，拖垮了集群，影响了存储和查询。

为此，后续对A系统做了查询限流，保障并发量在15TPS以内，核心业务服务需确保做好查询限流保护，同时也要提升缓存设计。

多线程代替单线程

在应急定位场景中，A系统调用B系统获取诊断结果，超时时间为500ms。对于一个异常ID事件，可能需要执行多个诊断项服务，并记录诊断流水；每个诊断的耗时大致在100ms以内。随着业务增加，超过5个诊断项时，计算耗时将累加到500ms以上，导致服务在高峰期短暂不可用。

将这段代码修改为异步执行，以减少最大的耗时。

// 提交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);  
    }  
}

集群计算代替单机

在此场景中，可以使用三层分发，将计算任务分片后执行，采用Map-Reduce思想，减少单机的计算压力。

系统IO性能优化策略

常见的FullGC解决方案

系统常见的FullGC问题较多，我们首先了解JVM的垃圾回收机制和内存分配策略。

JVM的垃圾回收机制：

堆区在设计上采用分代设计，划分为Eden、Survivor和Tenured/Old区，其中Eden区和Survivor（存活）属于年轻代，Tenured/Old区属于老年代或持久代。
一般将年轻代的GC称为Minor GC，老年代的GC称为Major GC，Full GC即针对整个堆的垃圾回收。

内存分配策略：

对象优先在Eden区分配；
大对象直接进入老年代；
长期存活的对象将进入老年代；
动态对象年龄判定（虚拟机不会永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果Survivor空间中相同年龄的所有对象的大小总和超过Survivor的一半，年龄达到该年龄的对象就可以直接进入老年代）；
只要老年代的连续空间大于（新生代所有对象的总大小或历次晋升的平均大小）就会进行Minor GC，否则会进行Full GC。

常见的触发FullGC的情况包括：

（1）查询大对象

业务中，历史巡检数据需要定期清理，删除策略为每天删除上个月之前的数据（通过软删除标记），然后等数据库定期清理任务彻底回收；

某一天，删除策略由“删除上个月之前的数据”改为“删除上周之前的数据”，因此删除的数据从1000条增加至15万条，数据对象占用了80%以上的内存，直接导致系统FullGC，其他任务受到影响。

许多系统代码在查询数据时没有数量限制，随着业务增长，系统容量在不升级的情况下，频繁查询出大量大对象List，导致出现大对象频繁GC的情况。

（2）设置了无法回收的static方法

A系统设置了static的List对象，本用于DRM配置读取，但某逻辑对配置信息查询后还进行了Put操作，导致随着业务增长，static对象不断增大且属于类对象，无法回收，造成系统频繁GC。

使用Object作为Map的Key本身存在不合理性，同时Key中的对象不可回收，导致出现GC。

当执行FullGC后若空间仍然不足，则会抛出以下错误：java.lang.OutOfMemoryError: Java heap space。为避免上述两种情况引起FullGC，调优时应尽量让对象在Minor GC阶段被回收，让对象在新生代多存活一段时间，同时避免创建过大的对象及数组。

顺序读写替代随机读写

对于普通机械硬盘，随机写入的性能较差，随着时间推移还会出现碎片，顺序写入显著节省磁盘寻址及盘片旋转时间，从而极大提升性能；许多中间件已实现此功能，例如Kafka的日志文件通过顺序写入消息和不可变性，消息添加到文件末尾，从而保证高性能读写。

数据库索引设计

在设计表结构时，应考虑后期对表数据的查询操作，合理设计索引结构。一旦表索引建立后，也要注意后续的查询操作，以避免索引失效。

（1）尽量避免选择键值较少的列进行索引，因为这些列的区分度不明显，重复数据较少；例如，若将is_delete列做索引，查询10万条数据时，where is_delete=0可能有9万条数据块，加上访问索引块带来的开销，不如进行全表扫描。

（2）避免使用前导like "%***"以及like "%***%"，因为前面的模糊匹配难以利用索引顺序访问数据块，导致全表扫描；而使用like "A**%"则不受影响，因为遇到以"B"开头的数据时就可以停止查找。

（3）其他可能导致索引失效的情况包括or查询、多列索引未使用第一部分查询、查询条件中含有计算操作或全表扫描的情况。

分库分表设计

随着业务增长，若集群节点数量过多，最终可能达到数据库的连接限制，导致集群节点无法持续增加和扩容，从而无法应对业务流量的增长；这也是蚂蚁实施LDC架构的原因之一，通过业务层的水平拆分和扩展，使每个单元的节点只访问当前对应数据库。

避免大量的表JOIN

阿里编码规约中规定，超过三个表的JOIN应被禁止，因为三个表的笛卡尔积计算会导致操作复杂度几何增长。在进行多个表JOIN时，确保被关联字段具备索引。

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

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

有时业务记录会进行count操作，若对时效性要求不高的统计和计算，建议在业务低峰期定时任务做好计算，并将结果保存至缓存中。

对于涉及多个表JOIN的情况，建议采用离线表进行Map-Reduce计算，然后将结果回流至线上表用于展示。

数据过期策略

一张表的数据量如果过大，若未根据索引和日期进行部分扫描而导致全表扫描，将极大影响DB的查询性能。建议合理设计数据过期策略，定期将历史数据放入history表，或备份至离线表中，以减少线上数据存储。

合理使用内存

众所周知，关系型数据库的底层存储在磁盘上，计算速度低于内存缓存。虽然缓存DB与业务系统连接存在一定的调用耗时，但其速度仍低于本地内存；从存储量来看，内存存储数据容量低于缓存。因此，长期持久化的数据应存储在数据库中，设计过程中需平衡成本与查询性能。

内存使用还存在数据一致性问题，如何保证DB数据与内存数据的一致性，是强一致性还是弱一致性，数据存储顺序及事务控制等都需要考虑，因此尽量做到用户无感知。

做好数据压缩

许多中间件采用压缩和解压操作来减少数据传输中的带宽成本。这里对数据压缩不再展开说明，但需要强调的是，在高并发的业务运行状态下，合理控制日志打印非常重要，避免为了方便排查而过度打印JSON.toJSONString(Object)，从而导致磁盘被迅速占满，同时，按照日志容量过期策略也要方便问题排查。建议合理使用日志，错误码尽量简化，核心业务逻辑应记录摘要日志，结构化数据有利于后续监控和数据分析。

在打印日志时，考虑以下问题：