马阳阳

去哪儿网高级研发，4+年从业经验，专注于云原生、效能领域。曾参与移动集团私有云 PaaS、企业级 DevOps 平台。目前负责代码瘦身平台、测试环境效率，致力于提升研发效能，助力业务快速发展。

一、引言

二、什么是高性能

三、何时考虑性能

1. 常规研发流程

• 系统设计阶段：在系统设计时需要估算业务压力，根据日均/峰值 QPS 、业务可接受的响应时间等指标，决定系统需要支撑怎么样性能，设计符合性能要求的架构。
• 系统上线前：在最终上线前，通过全方位性能测试来验证是否正真符合要求，不符合则进行优化，优化完再测，螺旋上升，直到满足性能要求。
• 系统运行期间：在系统运行期间，通过监控、告警等发现了问题，深入分析后发现是性能原因导致，此时就需要进行性能优化。创建约束理论的艾利·高德拉特告诉我们，“在瓶颈之外的任何地方做出的改进都是假象”，因此一定要先找出性能瓶颈点，再针对瓶颈进行改进。

2.  DevPerfOps

四、如何实现高性能

• 执行器的质量及数量，会直接影响 IO 和 计算的速度
• 流程会决定做哪些、怎么做，会影响性能
• IO 与计算的花费时间，当执行器和流程确定后，时间是固定的，因此不会影响性能

1. 执行器

• 关于质量

• 关于数量

1.1. 并发

案例一：Noah 环境构建流程

环境构建是指 根据配置创建整套环境的过程，如果全串行，那整个环境构建会非常慢，所以必须尽可能并行。可以根据各类型间依赖关系可以分为四个阶段，中间件阶段 -> 数据库阶段 -> 应用阶段 -> 网络阶段，如下图：

案例二：冗余请求

1.2 分片

案例一：java 中线程安全 Map

• Hashtable

Hashtable 现在很少用到了，因为有新的替代品 ConcurrentHashMap，性能比 Hashtable 高。

• 1.5 版本 ConcurrentHashMap

• 1.8 版本 ConcurrentHashMap

• 内部包含大量 CAS 操作和 synchronized 代码块来实现线程安全。CAS 是自旋锁也是一种乐观锁，更新某个共享变量值时先判断当前值是否符合预期，符合的话就尝试更新，不符合则说明有冲突，重新尝试更新一下，这在竞争不激烈的场景下性能表现好。对于复杂的处理流程，使用 CAS 会导致代码复杂度非常高，因此用 synchronized 代码块的方式来保证线程安全。随着 jdk 版本升级 synchronized 也在不断优化，增加锁升级特性来降低锁的使用成本，所以在 1.8 中性能也还行。
• 当发生哈希冲突时仍使用拉链法，当链拉的很长时性能会急剧下降。为了缓解性能下降问题，当拉链长度达到或超过 8 时，判断数组大小是否大于等于 64。如果不大于则先扩容，大于则将链表转换成红黑树（treeify），时间复杂度从O(N) 下降到 O(logN)

案例二：TLAB

案例三：GPM 模型

• 首先将每个 CPU 和一个线程进行绑定，这样可以避免同一个 CPU 上的线程切换。CPU 数量是确定的，因此线程数量也直接确定，这样就可以减少创建、销毁操作次数；
• 新增了用户态的“线程”，即 Goroutine 的概念。Goroutine 和线程一样可以调度执行，只不过是在用户态，调度也是由 Go 在用户态完成的；
• 多个 Goroutine 会和 OS 层的一个线程进行绑定，因为最终执行还是得依靠线程；
• Goroutine 很轻量，一个 Goroutine 消耗的内存资源是 Kb 级，一台几 G 服务器可以同时存在百万 Goroutine；
• Goroutine 的创建、销毁、调度和切换都可以在用户态完成，没有用户态、内核态切换，因此开销很小；
• 当在 Goroutine 中调用阻塞的 API 时，比如 sleep，本来会导致对应的线程也阻塞，但 Go 做了个巧妙地处理，它将所有系统调用中阻塞的 API 悄悄（对开发者无感）改成非阻塞版本，这样 API 能立刻返回，然后在当前 Goroutine 里类似 yield 一下，让出位置，使其他 Goroutine 立刻调度到这个线程上，这样线程将一直在做计算，理论上能让 CPU 利用率一直在 100%；

• G：Goroutine，协程，被调度的基本单位，相当于任务；
• P：Processor，调度器，每个 M 对应一个调度器，一个调度器会负责多个 Goroutine 的调度；
• M：Machine，内核线程，可配置数量，数量最好和 CPU 一致，并且进行绑定，这样性能最佳；

1.3 拆分

案例一：指令流水线

• 指令介绍

• 无流水线时

• 流水线化后

• 流水线带来的改变

• 拆分成多个阶段后，每个阶段的耗时不均等
• 任务拆分后可能导致损耗，存在更多上下文切换，即拆分后各阶段耗时之和会比一条指令完成时间略长
• 可并行度没这么高。指令 2 的 1 阶段可能需要等指令 1 的 2 阶段完成才能开始

案例二：Noah 环境构建流程

• 应用类型：1、创建运行时（如 docker、虚机）；2、安装自定义软件；3、运行服务启动前脚本；4、部署服务；5、运行服务启动后脚本；
• 数据库类型：1、创建运行时；2、安装数据库；3、初始化测试数据；
• 中间件类型：1、创建运行时；2、预装软件；3、安装中间件；
• 网络配置：1、到 Openresty 上更新配置；

2、IO 型流程优化

2.1 缓存

本节提的缓存只是 cache，不包含 buffer。buffer 一般用于写操作，将要写的数据放到缓冲区中，让 IO 设备可以批量处理，减少写的成本从而提升性能。

• 本地缓存：缓存数据就在服务器本地，比如内存或磁盘上。常见的实现包括 Ehcache、Guava、Caffeine；
• 集中式缓存：缓存数据在一台单独的远程服务器上，常见的实现包括 Redis、Memcached。

• 频繁被读到的数据：App 首页；
• 很少发生变化的数据：机票航班的数据，变更是比较少的。之所以要变更少，因为一旦原始数据变化，缓存一般也需要进行同步，此时会增加缓存维护的成本，这种高维护成本可能比不上缓存带来的性能收益；
• 对数据准确性要求不高：玩乐精选中的点赞数。

案例：一个读请求的处理

• DNS 缓存：第一件事要对请求的域名进行解析，获取域名的 IP 列表。先查看本机 hosts 文件，找不到则继续，查找本机的 dns 缓存，没有的话则向 DNS 服务器发送请求，将 DNS 服务器解析的结果（即 IP 列表）在本地缓存起来。这样下次访问同样的域名时，可以直接使用缓存，不再需要发送解析请求。
• 浏览器缓存：HTTP 协议在 Request header 中提供了缓存相关的属性，如 Cache-Control、ETag。在 HTTP1.1 规范中，Cache-Control 用来标识能否进行缓存、缓存有效期等信息。有些情况下浏览器甚至不会向服务端发起请求，直接使用了浏览器本地的缓存数据。
• CDN 服务：一般对于静态资源，可以通过 CDN 进行访问加速，CDN 可使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度。可以认为 CDN 网络就是浏览器和服务端之间的缓存。

• 页面缓存：tomcat 工作目录下会存在一个 work 目录用来存放页面缓存，如 jsp。
• processorCache：Tomcat 在处理每个连接时会将 socket 上下文封装成一个任务 SocketProcessor 进行处理。在 BIO 或 APR 模式下，每次有新的请求就会创建一个新的 SocketProcessor 对象。在 NIO 中为了提升性能，支持对 SocketProcessor 也进行缓存，用完后将状态重置重新放回缓存中。
• Mybatis 缓存：使用 Mybatis 框架查询 MySQL 时，Mybatis 也提供了两级缓存。一级缓存是会话（session）级，当使用同一会话先查询一次数据后，又立马再查询一次时，第二次查询会直接使用缓存而不请求 MySQL。二级缓存是 mapper 粒度的全局缓存，多个会话能共享，尽可能减少访问 MySQL 的次数来提高性能。

• 查询缓存（query cache）：在 8.0 之前版本的 MySQL 中，MySQL 服务端专门有一个缓存组件，叫“查询缓存”。当执行查询语句时，会先去查询缓存中查看结果，之前执行过的 sql 语句及其结果以 key-value 之类的形式存储在缓存中，如果能找到则直接返回，如果找不到，就继续执行后续阶段。在 8.0 版本开始，查询缓存组件被移除了，主要是因为该缓存命中率低，数据存在频繁变化，因此使用缓存效果不好。
• Prepared Statements 缓存：MySQL 服务端在收到一条 SQL 语句后，其中一个处理步骤是分析器对 SQL 进行语法/词法分析，这个过程一般比较耗时。MySQL 会使用一个内部结构体来承接解析出来的结果，并将其缓存，该缓存避免了在回话期间需要再次解析 SQL 语句时的开销。
• Buffer Pool：InnoDB 引擎提供了 Buffer Pool，虽然名字是 buffer，但它也起了 cache 的作用。buffer pool 是内存中的一个重要区域，占空的物理内存很大，用于对数据和索引进行缓存，使用 LRU 算法作为淘汰策略。这样在查询经常访问的数据时可以直接访问 buffer pool 而不是磁盘，从而加快处理速度。

2.2 压缩

• 有损：解压后的数据对比压缩前的数据可能存在丢失，如果个别数据差异不会造成太大影响，就可以使用有损压缩，有损压缩常应用与直播、音频、图像等。
• 无损：解压后和压缩前的数据完全一致，准确无误。对于数据准确性要求极高的场景，适合使用无损压缩。日常用的压缩软件一般都是无损压缩类型，比如常见的 zip、rar、gzip 等。

案例：HTTP 压缩

• HTTP 是基于 TCP 实现的请求-响应协议，存在大量的数据传输。为了提高传输速度，HTTP 协议中定义了压缩相关功能。HTTP 压缩通常使用的是 gzip 压缩算法来压缩 HTML、JavaScript、CSS 等文件，是否开压缩和具体压缩算法是由服务端决定的，具体细节如下：
• 用户通过浏览器发送请求时，浏览器会在 request header 里放一个关于压缩的参数 “Accept-Encoding: gzip, deflate, br”，表明支持 gzip、deflate、br 三种压缩算法；
• 服务器接收到浏览器的 HTTP 请求后，看浏览器是否支持压缩，支持哪些压缩；
• 如果浏览器支持压缩，服务器看自己开了哪些后缀文件的压缩。假设服务端启用了对 CSS 文件的压缩，则当请求 CSS 文件时，服务器到压缩缓冲目录中检查是否已经存在请求文件最新的压缩文件；
• 如果不存在压缩文件，则服务器向浏览器返回请求文件，并进行压缩，将压缩产物放到压缩缓冲目录下；
• 如果已存在压缩文件，则直接返回请求文件的压缩文件，并在 response header 里放一个参数 “Content-Encoding: gzip”，告知浏览器是 gzip 格式；
• 浏览器收到响应数据后，根据 header 中的参数决定是否需要解压、用什么算法进行解压，解压完成后再使用。

3. 通用流程优化

• 存在不必要的计算或 IO
• IO 操作，传输了不必要的数据

3.1 异步

• 调用异步：客户端角度的异步，是请求服务器 API，然后不等服务端返回结果，就继续去做其他事情；
• 流程异步：服务端角度的异步，是接收到一个客户端请求后，不占用连接线程立刻进行处理，而是丢给其他线程慢慢去处理，当处理完后再将结果返回。

• 逻辑解耦，提高扩展性：在不使用异步时，任务提交和执行是绑定的，一旦提交就必须等待执行完毕。在使用异步后，将任务的提交 和 任务的执行进行解耦，不再有强绑定关系。
• 提高可靠性：主干流程中的步骤减少了，出错的可能点 数量降低，因此可用性有了提升。
• 通常能和 批量（下一节会讲）一起使用，进一步提升性能。

• 分支逻辑通知主干结果：由分支通知主干，这种方式时效性好，对主干的执行器资源消耗少，但需要主干提供回调 API
• 主干逻辑轮询分支结果：主干执行器向分支执行器轮询结果，这种方案对结果的获取存在延迟，最大延迟时间是一个轮询周期间隔。同时主干执行器要用额外资源执行轮询任务，轮询并不是每次执行都能得到结果，因此存在不少浪费

案例一：客户端异步调用

• 传入 Callable：异步回调 API 的入参中，会有一个 Callable 类型对象，代表回调函数。当异步任务完成后会调用注册的回调函数，从而让调用者感知到任务结束了。
• 返回 Future：调用异步 API 时会方法返回一个 Future 对象，通过 Future 对象可以获取返回结果和状态相关信息。

案例二：MySQL 的 Relay log

案例三：短信验证码登录业务

3.2 批量/合并

• 抵消：将两个逆向的操作进行抵消，比如 新增一条数据、删除一条数据；
• 聚合：将多个操作进行聚合，比如 3 次转入 100 元，可聚合成一次转入 300 元。

案例一：Kafka 流转消息

• push

• pull

• Kafka 的实现

案例二：Redis rewrite 机制

• aof 文件不断进行追加，导致文件可能无限大；
• 根据 aof 进行数据恢复时，一条一条的命令执行，恢复时间会很长呀，速度慢。

• 在 4.0 之前，aof 文件是一个纯指令文件，触发重写后会进行运算，实现以下两点：
• 删除抵消的命令。如set k1 aa后又进行了rem k1，那么这两条命令就在 aof 文件中移除；
• 合并重复命令。如执行了一万次INCR k1，可以合并成执行一次INCRBY k1 10000。
• 在 4.0 之后，默认是让重写功能不再进行运算，而是会生成一个 rdb 文件，并将全量 rdb 内容放到 aof 的开始。之后增量地记录新来的写操作并 append 到 aof 文件中。使得 aof 变成了一个混合体，既有 rdb 磁盘消耗小、恢复快，又有 aof 的数据全特性。

3.3 复用

案例一：常量池

public class Demo { public static void main(String[] args) {  String s1 = "123";  String s2 = "123"; }}

s1 和 s2 的字面值一样，我们就可以把 “123” 这个字面值放到常量池中，只放一份即可，让 s1 和 s2 都指向常量池中的字面值。这样能节约内存空间，并且少创建一次字面值，性能也会有提升。

案例二：连接池

3.4 转移

案例一：MySQL 索引

• 数据页被访问时

• 当数据库空闲时

• 数据库正常关闭时

• 数据库缓冲池不够用时

• redo log 写满时

• 为了加快查询，提前创建索引并在更新数据同时维护索引

• 为了加快更新，将正真的更新操作进行后置

• 更新操作后置并合并，体现了 异步 和 合并 的思想

案例二：Noah 虚机创建

• 虚机的创建和销毁操作非常重，创建一个虚机至少是分钟级的；
• 虽然多个虚机的创建能并行，但并行度也很有限。当环境规模比较大 同时需要上百台虚机时，此时如果全并行，会对底层 openstack 平台产生很大压力；
• 虚机创建的成功率也不是百分百的，当调用平台接口超时或失败时，还需要重试，进一步拉长了处理时间；
• 创建虚机是核心步骤，必须要等虚机就绪了才能开始后续操作。

案例三：计算向数据移动

• SQL：DQL 语句中提供了很多计算能力，limit、order by、count 之类，这样就可以直接在 MySQL 服务端计算好，不需要全量数据来回传；
• 查询列表：业务系统一般都会有列表功能，并配备分页、过滤、排序功能。在前后端分离架构下，会让后台 API 支持分页、过滤、排序参数，而不会在前端查询全部数据后前端进行处理。

3.5 算法优化

五、小节

参考资料：

• MySQL 官方文档

• The Tail at Scale

• 《Computer Systems A Programme's Perspective》

• 《软件架构设计：大型网站技术架构与业务架构融合之道》

• 《软件研发效能提升之美》