互联网中常见优化手段

你有没有想过，为什么跨行转账要告诉你2小时内到账，而不是立即到账？为什么抖音那么多用户同时在使用，却很少出现崩溃的情况？电商网站是如何支撑住双十一全国人民买买买的？

性能优化对一个产品的重要性不言而喻，它直接影响网站的用户留存率，APP在商店的评分和用户粘性。一个响应慢的应用，即便它功能再强大，也留不住用户。

性能优化对一个程序员同样非常重要——如果你是一个有追求的程序员的话。我们说，大多数人的职业生涯发展都应该是一个T字型，要在某一方面有深度，也要有广度。而性能优化，恰恰是一个既需要深度，又需要广度的话题。相信很多程序员都有一个成为架构师的梦，如果想要成为一个系统架构师，那性能优化是不得不学习了解的。

找到最慢的节点

我们谈性能时，一般来说有两个指标，一个是响应时间，一个是吞吐量。

说到响应时间，最直观的感受就是快与慢。打开一个网页需要多少毫秒、点击一个按钮需要等待多长时间、刷一个抖音视频需要加载多久？这些都是在说响应时间。

吞吐量指的是系统在单位时间能够承受的请求数量，反映是系统的承载能力。

下面列出一些常见的影响性能的地方。

• 网络传输

影响响应时间的因素有很多，我们可以通过一些监控去测试。但我可以很负责任的告诉你，在大多数场景，一次完整的网络请求中，最多的时间往往是消耗在网络传输上。

网络传输有很多种，比如服务端到客户端的请求和响应，还有服务端各个微服务之间的接口调用耗时，还有应用与数据库、应用与缓存、应用与消息中间件等等之间的网络传输。

当然，大多数时候，我们会把后端的一些东西尽量放在一个机房里面，这样可以直接走内网，网络传输时间不会很高。但相比于大多数应用代码的执行时间来说，这些网络传输也是一笔不小的消耗。

• SQL查询

我们应用的数据可能会持久化在不同的地方，不管是关系型数据库、非关系型数据库、还是搜索引擎，一旦数据量上去了，如果没有做好性能优化，查询的时候很容易就耗费大量的时间。

最常见的就是SQL慢查询了，一旦产生了慢查询，轻则响应时间变慢，重则拖满线程池导致整个服务不可用。所以SQL查询也是我们经常会考虑到的性能优化方向。

• 线程等待

线程等待指的是线程同步造成的问题。现代服务器往往是多核的，我们通常会使用线程池来发挥多核服务器的优势。但使用多线程经常会遇到的问题就是线程的同步问题。

在高并发下，线程同步其实是一个很危险的操作。如果临界区的操作比较耗时，就会导致大量的线程等待、堆积，最终撑满线程池。比如上面提到的慢SQL就常常会导致这个问题。

所以我们在使用多线程的时候，一定要小心谨慎。尽量弄清楚它的原理，想办法避免或者更轻量级地上锁。多线程是一块比较大，也比较难的知识点。

• Full GC

Full GC其实影响整个应用性能的概率比较小。但如果你的程序没写好，或者JVM参数没有设置好，造成了频繁Full GC或者Full GC时间过长，也是有可能会影响性能的。

对JVM有所了解的朋友都知道，Full GC会STW (Stop The World)，这段时间程序会暂停，也就没法响应用户。

G1对Full GC做了优化，把单线程的Full GC变成了多线程并行Full GC。但如果Full GC频繁，仍然会影响应用的性能。这里列一下Full GC频繁的原因，有兴趣的朋友可以自己再深入了解一下：

老年代设置的空间太小
永久代空间不足
程序中写了很多大对象
晋升老年代的代数阈值设置太小

高频优化思路

针对上面提到的几个最容易影响程序性能的点，下面介绍一些高频的性能优化思路，大多数都是针对网络传输的，从各种角度去减少网络传输的消耗。从这些思路入手，大概率可以很明显地提升性能，小伙伴们可以作为参考。

• CDN

前面提到，一般来说，一个用户请求大多数时间是消耗在网络传输上的，尤其是客户端与服务端之间的网络传输。

CDN全称是“Content Delivery Network”，翻译过来叫内容分发网络。原理其实很简单，就是把资源分发到全国各地甚至是世界各地，使得用户可以就近取得资源，缩短网络传输的距离，降低延迟，所以可以很明显地提升响应速度和成功率。

所以CDN多是用于文件分发，比如网站的css、js、图片、视频等资源文件。曾经听过一句话：如果你的网站没有使用CDN，那么使用CDN基本上可以让你的网站性能得到大幅度提升。

CDN一般是和OSS配合起来使用的。现在各大主流云厂商基本都提供了OSS和CDN的产品，比如阿里云。

• 压缩

另一个优化网络传输消耗的思路就是压缩了。CDN的思路是让网络传输的距离更短，压缩的思路是让网络传输的内容更小。尤其适用于js/css等文本文件，压缩收益非常高，往往能节省很多的网络传输开销。

图片和视频当然也可以压缩，不过需要选择合适的压缩算法。比如我们用微信发送图片时，如果不点击“发送原图”，那图片就会被微信压缩，虽然可能没那么高清，但是文件小很多，使得用户可以更快收到图片，提升用户体验。

现在大多数网站都会使用nginx作为前端服务器或者负载均衡器，在nginx里面可以非常方便地启动gzip压缩功能：

server{
    gzip on;
    gzip_buffers 32 4K;
    gzip_comp_level 6;
    gzip_min_length 100;
    gzip_types application/javascript text/css text/xml;
    gzip_vary on;
} 

在浏览器打开“开发者控制台”，查看资源的网络请求，可以查看该资源是否启用了压缩算法。

• 预加载

前面讲到了两个网络传输的优化思路。我们可以另辟蹊径：既然网络传输那么消耗时间，那我们偷偷在不忙的时候提前下载好不行吗？

大家可以做一个实验：刷抖音刷到一半，等一会儿，然后停掉自己的网络，再往下刷，可以发现还能刷好几个视频。

这就是因为抖音使用了预加载技术，当你在专心致志地看一个有趣的视频的时候，这个时候网络其实是空闲的，抖音就在悄悄下载后面几个视频，这样你就可以一直刷刷刷，用户体验就会很顺畅。

试想一下，如果不使用预加载，用户每次往下刷，都得等几秒钟把这个视频下载下来才能看，那自然用户体验极差。

当然了，预加载并不适用于所有场景。毕竟预加载是提前下载，并不是不下载。如果不是有特定的业务场景，其实也没必要使用预加载。不合理地使用预加载甚至有可能会影响正常的业务，还有可能造成数据不一致的问题。

• 慢SQL优化

很多应用后端会使用关系型数据库来持久化数据。如果数据量大了，索引设置不合理，就很有可能会产生慢SQL。

生产环境最好加上慢SQL监控和分析的工具。阿里出品的Druid就很不错。对很多中小型项目来说已经足够了。慢SQL优化一般有几个思路。

先看是不是没有命中索引，如果没有命中，是否可以调整索引或者SQL语句？
看能不能从业务代码层面解决？
能不能在应用层面加缓存？
考虑是否需要分库分表？

• JVM调优和升级

频繁的GC会占用大量的JVM资源，还会浪费CPU的资源。所以如果是生产环境，推荐给JVM也加上监控和告警，这样能够随时观察JVM的状况是否健康。

尤其是对于Full GC，要格外注意，因为Full GC会Stop The World。前段时间我们有一个应用就是因为永久代空间不足，触发Full GC，而每次回收效果又不好，导致一遍又一遍地Full GC，影响应用的正常工作。

Java也在对JVM不断进行优化和升级，比如最新的ZGC，在大堆下性能表现优异。G1也非常不错，如果项目条件允许，建议使用稍微新一点的垃圾收集器。

后端架构优化思路

前面介绍了一些高频的性能优化思路，这部分主要从架构的视角去谈谈如何优化你的应用，不只是性能，有包括稳定性和吞吐量。

一开始我们的应用可能是一个很简单的单体应用，慢慢地用户变得越来越多，这个时候最开始那种简单的架构可能已经不足以支撑这个用户量和数据量，这个时候就需要对它进行升级，那如何升级呢？核心就是一个字：拆。

微服务是从业务视角把一个大的应用拆成许多小的应用。使应用减小依赖，更容易开发、部署、管理。而拆成一个个微服务后，一些高频使用的微服务需要搭建集群对外提供能力，这个时候可能就要依赖微服务框架的负载均衡和弹性扩容/缩容能力了。

• 负载均衡

单台服务器的处理能力是有限的。所以我们可以在多台服务器上部署一模一样的应用。这样进来的请求就可以分摊到多台服务器上。

负载均衡的手段和算法有很多种。软件的话有nginx，可以支撑好几万的并发。一些微服务框架比如Spring Cloud也提供了负载均衡的能力（Ribbon）。

• 弹性扩容/缩容

使用负载均衡能够让应用支撑住更多的请求。但服务器是要花钱滴，很多应用的访问量在一天中并不是均衡的，可能在某个时间段会显著比其它时间段要高一些，比如下班后到睡觉这段时间。也可能会有一些访问量激增的情况。不管是意料之中（比如电商网站的秒杀活动），还是意料之外（比如某明星绯闻上了微博热搜）。

弹性扩容和弹性缩容，可以在检测到流量上升的时候增加服务器的数量，在流量下降的时候减小服务器的数量。这样就可以在保证业务正常运行的情况下，尽可能地节约成本。

容器时代已经来临，k8s提供了容器的弹性扩容和缩容功能，用户只需要进行很简单的配置，即可实现弹性扩容和缩容，非常的nice。

• 读写分离

解决了应用层面的问题，接下来我们就需要解决数据库层面的问题了。因为Web应用都是木桶原理，如果在数据库层面性能不行，哪怕你的应用层面做得再好，那也无济于事。

在大多数业务场景中，读的请求一般是远远大于写的请求数量的。而写的时候，往往比较耗时，还有可能锁住某些行，导致读数据库的请求阻塞。

所以我们可以把单个数据库拆成主库和从库，然后把所有到数据库的请求分成读请求和写请求。一般为一主一从或者一主多从。其中，主数据库负责处理写请求，然后同步到从数据库。从数据库主要负责读请求。如果是多个从节点，一般会在前面负载均衡。由于数据库请求一般是走的TCP协议，所以比较推荐的负载均衡开源工具是LVS。

使用读写分离也是有一定的代价的。比如主从同步的时间间隙可能会造成用户读到的数据不是实时数据，只能保证主从节点上的数据是最终一致的。所以这点要从业务上考虑清楚，是否可以接受这种数据不一致。

• 分库分表

读写分离后可以在一定程度上缓解数据库压力。但如果数据量持续增多，使用读写分离也不能解决问题。分库分表或者分布式数据库可以解决这个问题。比如MySQL，如果一个表数据上了千万级别，就可以考虑拆分了。

如何拆分呢？对于分表来说，我们一般有垂直分表和水平分表这两种思路。

垂直分表

垂直分表是把一个表按照不同的字段分成多个表。举个常见的例子，商品列表页和商品详情页。商品列表页往往是分页查询一个列表，所以需要高性能的一个索引。而商品列表页往往不会展示太多的信息，所以商品列表页的字段和商品详情页的字段可以拆开成两个表，它们之间用商品id关联起来就行了。

这样商品列表页所在的表，一行的字段就比较少，也可以维护各种查询索引。而商品详情页，只需要维护一个商品id的索引就行了。

当然了，垂直分表需要从业务视角去考虑，需要匹配业务的需求，不能盲目拆分。上面举的商品列表页和商品详情页应该在开发的时候就考虑到这一层。不过有些老旧的设计，可能还存在这种把很多字段放在一个表里面的情况。

垂直拆分也不能完全解决数据量过大的问题，比如商品数量上亿、甚至是几十亿、几百亿的时候，数据库一样承受不住。这个时候就要考虑水平分表了。

水平分表

水平分表指的是把数据放到不同的表里。水平分表一般适用于两种情况，这里分别介绍一下。

单机水平分表

第一种是数据“冷热不均”，比如经常用到的就是最近一段时间新写入的数据。比较典型的业务场景是微信朋友圈。最近几天新发的朋友圈的读写请求明显比几个月前要大得多。

那这种情况我们可以很简单的按照写入的顺序把数据分成多个表。比如每张表放一千万数据，写完后就新建下一个表。或者按照时间来，比如2020年5月份的数据放在202005，6月份的数据放在202006。

单机水平分表非常适合那种数据“冷热不均”的场景，比如日志记录等等。可以保证热点数据的读写性能，也能支持数据量的无限增加（只要磁盘够大）。最重要的是，它的成本不大，不需要额外的机器。所以如果业务支持的话，可以考虑单机水平分表哟。

分库分表

另一种是数据热度相对分布均匀的，比如前面提到的商品表，或者是并发量确实太大的。这种情况一般会使用分库分表，把数据按一定的分布算法（比如根据某个字段哈希），水平分布到多个库里，一般来说都是一个库对应一个服务器节点，这样就可以把流量拆分到每个节点，大大减小数据库的压力。

水平分表的问题

水平分表会带来问题，很多复杂一点的查询都需要去查找所有的表，然后把结果聚合起来，经过加工整理再返回。比如想count查询一个数量，需要去每个节点都count一次，然后把结果加起来。至于涉及order、join之类的查询就更复杂了。

还有自增ID的问题，如何才能保证全局的自增ID，也是一个需要注意的问题。

解决这些问题有两个办法，第一种办法是使用数据库中间件，这方面的开源产品有MyCat、shardingsphere（推荐）等。另一种办法是实现一个分布式数据库，用户就像使用单机数据库一样去使用它。比较典型的产品有TiDB等。分布式数据库由于需要自己实现查询引擎，所以不一定能够100%兼容所有最新语法，不过也能够满足绝大多数的需求了。

代码中的优化思路

前面介绍了一些架构上的优化思路。最终我们还是回归到代码本身，聊一聊在代码中的一些性能优化思路。因为改动架构的成本是非常大的，其实很多时候时候可能瓶颈并不在架构上，而是因为不合理的代码，造成了性能瓶颈。

我们的T字型发展，架构的优化思路是横向，那代码优化思路就是纵向了，是作为一个程序员的基本功，是我们吃饭的根本。

• 应用内缓存

俗话说，要想快，加缓存。一层不够加两层，两层不够加三层。

缓存的原理是把计算结果暂时存储在内存中。这样就可以在下次需要这个计算结果的时候，直接从内存中去取，可以省去重复计算和重复的网络开销。

许多框架都利用了缓存的技术，尤其是许多持久化框架，比如Hibernate和Mybatis，都支持两级缓存。如果你的应用是分布式的，也可以在一些地方加上缓存。比如你的程序在好几个地方都会去调同一个接口。那可以在第一次调用的时候把它存起来，后面需要用到的时候直接去内存中取，不需要再次调用。

加缓存是一种思想，实现缓存有很多种工具和方式。如果你的缓存需要在多个服务节点之间共享，那推荐使用redis这种内存数据库。如果你的缓存仅仅是在单个节点里面临时使用，那推荐Ehcache等工具，Google提供的Guava Cache也很不错。

使用缓存有几个需要注意的点。一个是注意缓存的生命周期，该清理的时候要清理，该过期的时候要过期，不要让无效的缓存占据大量的内存，因为内存是很贵的。另外需要注意数据的一致性，如果业务上要求数据的一致性和及时性，就要好好考虑使用缓存会不会让应用受到影响。

• 串行改并行

另外一种常见的代码优化思路是串行改并行。比如，有时候你执行多个任务，他们可能彼此之间并没有数据的前后关系。那是不是可以由改到并行提升计算效率呢？Java 8的函数式编程提供了串行和并行两种Stream，如果数据量比较大，可以使用并行的Stream来利用计算机的多核优势。

collections.stream(); // 串行stream
collections.parallelStream(); // 并行stream，并行stream底层是使用的ForkJoin框架来实现的

这个方法同样适用于网络请求。比如下面这段代码中，需要去调用三个接口，然后把他们的结果收集起来进行下一步处理。这个时候我们就可以利用多线程，让他们同时去请求这几个接口，而不是串行的去做这个事情。

// 串行方式：
OneDTO one = oneService.get();
TwoDTO two = twoService.get();
ThreeDTO three = threeService.get();
nextHandle(new Result(one, two, three));

// 并行方式：
Result result = new Result();
CompletableFuture oneFuture = CompletableFuture.runAsync(
    () -> result.setOne(oneService.get()));
CompletableFuture twoFuture = CompletableFuture.runAsync(
    () -> result.setTwo(twoService.get()));
CompletableFuture threeFuture = CompletableFuture.runAsync(
    () -> result.setThree(threeService.get()));

CompletableFuture.allOf(oneFuture, twoFuture, threeFuture)
    .thenRun( () -> nextHandle(result))

• 异步

我在这篇文章的开头提到过一个问题，就是我们使用支付宝转账的时候，为什么支付宝不会告诉你立即到账，而是说两个小时之内到账呢？因为转账是一件非常复杂的操作，比较耗时。如果每次转账都要等转账完全结束之后再返回给用户，那需要等很久，而且会产生大量的长连接，没有必要。

这个优化的思路就是从业务上把它变成异步的。用户点击转账之后就异步进行转账操作，立即返回结果。等转账完成后，再发通知告诉用户已完成。异步是一种思想，我们程序员最常用的使用异步的方式就是用多线程、NIO、消息中间件。

• 使用合理的数据结构和算法

合理使用数据结构和算法是作为一个程序员的基本素养。

Java的工具类提供了很多十分方便的数据结构，比如List、Map、Set等。至少常用的几种常用的工具类底层的数据结构我们要明白，这里也列一些最最基础的：

数组和链表实现的区别
红黑树有什么用，是什么原理
ArrayList和HashMap的扩容过程
Map是如何做到查找时间复杂度是O(1)的

很多时候，我们用List的时候，先问自己一句，这个地方是不是可以利用Set和Map来提升性能？在初始化ArrayList和HashMap的时候，是不是可以考虑到初始容量，避免它在后面频繁扩容？

前面提到的MySQL索引，也是需要理解索引底层的数据结构，才能更好地理解和掌握索引。使用Redis的时候同样需要注意数据结构。五大基础的数据结构底层是如何实现的？布隆过滤器、bitmaps、HyperLogLog是什么原理，他们分别有什么应用场景？这些都可以去了解一下。

• 避免线程同步

使用多线程可以利用服务器多个CPU的优势，但很多时候可能我们需要多个线程之间的协作。比如多个线程去获取同一个资源，可能需要上锁排队。如果这个过程比较长，就有可能越来越多的线程卡在那，造成线程池爆满，严重的时候甚至拒绝服务。慢SQL导致服务器宕机就是一个典型的例子。

其实有时候我们是可以使用一些手段，去避免线程同步，或者缩小线程同步和范围的。比如：使用threadLocal；弄清楚JMM模型和HappensBefore原则，如果可以使用volatile等轻量级的实现，就尽量不要上锁；锁有很多种，有些场景可以使用“读写锁”来增加读的性能。