这五个字，能优化你80%的程序性能问题

本篇关注程序性能优化。聚焦这个主题，本是偶然。始于玩笑，终于本心。本想找点高大上的让人直呼牛逼的东西，奈何能力有限，只能给大家一些既便宜、又好用、还简单的普通东西了，不知道你们会不会喜欢。

分为五个主题，分别是『池』『序』『分』『减』『并』：

一、『池』字诀

池化，降低可重用对象的创建和回收代价。

不知道你们发现没有，无论是电影还是游戏中，主角总是孤胆单英雄，最多三五成群。但Boss不一样，Boss手一挥，必须有一群小怪一拥而上，毕竟帮主角刷点经验也是好的。

小怪的特点是：数量多，容易死，循环用。电影不可能请太多的群演，因此我们经常能发现一人分饰多角的超级龙套。而游戏里，也不可能每一个小怪都完全不一样，因为创建它们还挺消耗时间和内存的。哈哈，现在你知道了，你正在打的小怪很可能与刚刚死前掉金币的那只是同一只。

代码中，如果某些对象有重用的价值，并且创建的时候会消耗大量的CPU或IO资源。那么在出现性能瓶颈的时候，一个合理的优化方向就是池化。刚刚例子中，对游戏中小怪进行池化，通常称为对象池，类似的还有线程池、连接池等。

灰太狼：我一定会回来的~

二、『序』字诀

顺序读写，减少随机IO，减少cache miss。

『内存顺序读写的性能要远好于随机读写』，『磁盘顺序读写的性能要远好于随机读写』。类似的话我相信很多程序员都似曾相识，然而，我同样相信很多程序员在写代码的时候从来没有认真考虑过这件事件。

当年做游戏的时候，我见过很多人使用hash表存储场景中的各类对象：花鸟鱼虫、白云苍狗，并每帧遍历hash表以确定位置或攻击信息。我建议他们改成遍历有序表的快照（MVCC了解一下），其中一个原因是可以提高遍历性能，而另一个更重要的原因是可以在遍历的过程中修改表结构（插入删除对象）。

有序表一种基于有序数组的字典结构，C#中有一个名为SortList的标准库实现

多年以来，CPU一直是计算机中跑得最快的部件，也因此被惯出来一个多吃多占的毛病。无论是读内存还是读磁盘，从来不讲究按需分配，而是大块大块的拿数据。当把一大块连续的数据拿到手里的时候，CPU自己也知道一次肯定吞不下，但总觉得多吞几次就好了。

但这个特点其实是需要程序员去配合的，如果代码使用连续内存的数据结构，比如array，那在遍历的时候就相当于投其所好；而如果代码使用hash表，则遍历的时候cache miss的可能性就大大增加。

鉴于java在服务器领域的成功，有些公司使用java开发游戏服务器，我建议他们换一种语言。原因是游戏服务器很可能需要处理大量跟点、向量等三维空间相关的运算，而在java中，默认一切都是对象。于是在一个Vertex（顶点）数组中，看似连续的Vertex对象在物理内存中实际上是离散的，这样的遍历效果就会差很多。而对C , Golang，甚至C#这类语言来说，它们都支持struct。当把Vertex定义为struct的时候，一个Vertex数组的占用的内存就是连续的，遍历效果会比java好很多。

在后端的技术栈中，kafka绝对是一个非常另类的存在。擅长kafka的人，觉得无它不欢，而不了解它的人，则觉得可有可无。关于kafka为什么这么快的讨论有很多，其中有一个绕不过的原因是：kafka会顺序读写磁盘。我们通常认为磁盘的读写性能远低于内存，但实际上，在关闭fsync的前提下，SSD固态硬盘的顺序读写速度与内存的随机读写速度是相当的，大概都是1 GiB/s，而如果是随机读取，则SSD固态硬盘SSD的Seek速度会直降到70MiB/s，速度下降到1/15。

三、『分』字诀

鸿蒙伊始，民智不开。为教化万民，神器计算机降世。下凡走得急，零件没凑齐。计算机天生残疾，CPU与其它IO部件速度差异过大。为平衡这种速度差异，人间有智者布局各方，分字诀应劫而生，它们是分批、分帧、分页、分时、分片、分区、分库、分表、分离。

1. 分批≈缓存 缓冲

所谓读优化靠缓存，写优化靠缓冲，而分批≈缓存 缓冲。往小了说，缓存就是一块用于读内存，缓冲就是一块用于写的内存。往大了说，缓存就是Redis，缓冲就是Kafka。这些都是在微服务体系中司空见惯的招数，不用我多说。

分批优化化身千万，可谓无孔不入，甚至多数流行的数据中间件都提供了批量IO操作的API：

MySQL的insert语句支持在values中一次插入多行数据。Redis的Pipeline操作可以批量执行多个操作。ElasticSearch有专门的_bulk api支持在单次调用中索引或删除多条数据。Kafka更是把分批操作贯彻到了极致：它根本就不提供发送单条消息的功能，使用send()发送的单条消息其实会被Kafka偷偷在内存里攒起来，是的你被骗了。包括MySQL, Redis在内的各类数据中间件，跟WAL日志落盘时机相关的配置中，一定有一条是只写Page Cache，然后后台线程定期刷盘的策略。（注：严格说来，Redis那个不能叫WAL，因为它是写后日志。）在游戏引擎中，把顶点数据提交的显卡的Draw Call也都是合并批次的，否则会卡死你。

分批的缺点是在数据一致性差，无论是缓存还是缓冲都存在同样的问题。缓存的话，如果不存在严格的一致保障手段，往往只建议展示用，不作为数据修改依据。参考文章《缓存就像showgirl，看看就行了》。而缓冲在内存的这段时间内，如果进程崩溃了，会丢失部分数据。因此在选择分批优化的时候，架构师需要仔细斟酌数据一致性问题，比如是否可以接受偶尔丢失数据，或者是否需要在数据输入端提供重试策略。

但不管如何，分批都可能是最重要的IO优化手段：它逻辑简单，不涉及多线程并发，对数据结构没有特殊的要求，系统改造成本低。可以说，无论何时遇到IO性能瓶颈，分批改造都应该是顺位第一的候选方案。

2. 分帧、分页、分时

1）分帧，是专用于单线程 阻塞IO的平滑技术

很多时候，由于受框架限制（比如游戏或网页渲染），我们不得不在单一线程中同时处理用户逻辑与IO操作，这时如果IO消耗时间过长，就会阻塞用户逻辑代码，从而让用户感觉到卡顿现象。

Redis由于其单线程特性，很多耗时比较长的操作也需要分摊到多帧执行。比如hash表的rehash操作，当表的键值对过多时，rehash会产生的庞大的计算量，如果一次性完成可能会导致server对外暂停服务。Redis选择将rehash分摊到多次执行，称为渐进式rehash。

另外，对于比较大的hash表，hgetall一次性获取所有数据可能会卡死server进程甚至导致宕机，建议采用hscan来分次获取hash表中的数据。Redis中像这类支持迭代式扫描的命令有四个，分别是：scan, sscan, hscan和zscan。

2）分页可以看作是一种另类的分帧操作：

在运营类项目中，由于后台数据庞大，很多时候无法在单一网页中显示，通过分页显示，可以避免一次性数据获取带来的DB加载压力和网络传输压力。

3）分时复用指多对象轮流使用同一个硬件的技术，多见于跟硬件打交道的底层软件。

比如，分时操作系统：一种采用时间片轮转的方式同时为几个甚至几百个用户服务的操作系统；分时复用网络：指采用同一物理连接的不同时段来传输不同的信号，以达到多路传输目的的网络基础设施。

但有一种分时复用技术，虽然它的名字里没有分时二字，却与后端开发息息相关，那就是IO多路复用（洋名：Reactor）：单线程同时监听多个文件句柄，哪个句柄就绪，就通知应用线程读写哪个句柄的技术。

3. 分片、分区、分库、分表

随着77年恢复高考，这些年近视的年轻人越来越多了，于是人们越发的无法区分那些换个马夹儿就重新出来混的二货们。就像洗发水，猛一看飘柔、海飞丝、潘婷百花齐放，仔细一看，全特么是宝洁的。没错，这么土味的名字，竟然不是国货，害我自以为爱了这么多年的国。

分片、分区、分库、分表也一样，名字挺花，疗效一样，都是为了突破单体性能限制的水平扩展的方案，洋名字：scale out。因为方案类似，大家遇到的问题自然也是相同的。它们首先要搞定的就是路由问题，也就是把数据拆分之后，某个key储存到哪个分片/区/库/表的问题。路由方案可简单分为两类：

一种是非确定性路由，即相同的key多次路由可以映射到的不同的计算单元，常见方案有：轮询、随机。非确定性路由多用于无状态节点间的任务分配，比如nginx把请求随机分配到无状态的微服务节点上。

另一种是确定性路由，即相同的key多次路由必须映射到的相同的存储单元，常见方案为：区间，Hash，配置表。确定性路由多用于有状态节点间的任务分配，比如Kafka按user_id把来自同一用户的请求映射到同一个存储分区。

以MySQL为例，它支持四种分区类型，分别是Range, List, Hash, Key。因为跟存储密切相关，它们全是确定性路由算法，其中Range对应区间，List是配置表，Hash与Key则都是Hash类型。

除了应用于多机水平扩展，在单机内存中分片方案也有应用。比如JDK1.8之前，ConcurrentHashMap通过将整个Map划分成N（默认16个）个Segment，而每个Segment各自持有独立的锁，从而从整体上减少并发冲突。

4. 分离

分离式设计是一种架构模式，通过把单元功能单一化、纯粹化、专业化，可以降低开发和维护成本，同时提高功能单元的可复用性，这在设计模式中我们通常称之为单一职责。目前，常见的分离式架构设计有读写分离、存算分离。

读写分离在国人的文章中常用于指代MySQL写走主库，而读走从库，这有些狭义了。广义上读写分离的重点是：读路径不关心写，写路径不关心读，两者均关注于自己的功能实现，而毋需为对方的作出任何牺牲或让步。更多的细节我在文章《23.kafka心中的事件溯源》中有更详细的描述，感兴趣的读者可以点击查看。

这里我想强调的是，读写分离是分离式DB（Unbunding Databases）的雏形。我们应该认识到，不存在一种单一的数据模型可以满足所有的访问模式。MySQL在线业务、Redis加速查询、ES全文索引、DW离线分析，每一种衍生数据系统都有各自不可替代作用。

如上图所示，通过统一写端，派生读端，可以形成一种遵循unix传统的架构模型：单一任务做好单一事情，内部通过低级API（pipe）通信，外部通过高级语言（shell）组合。在分离式DB架构中，目前看来最合适的，能起到粘接剂作用的是Event Stream（Event Log）。期望未来有那么一天，我们能像在shell中写ps | grep java一样，写出mysql | elasticsearch这样的代码，届时就是分离式DB摘取王之桂冠的荣耀时刻。

如果说读写分离是拆功能，那么存算分离就是拆资源：把计算资源（CPU、内存）和存储资源（磁盘）拆分开来。早期的云DB，其实是把单体DB搬到云上。人们很快发现云DB与单机DB的不同之处：一是随着企业数字化转型的深入，数量总量飙升，单机存储捉襟见肘；二是在应对双十一这类突发性流量时，计算峰值波动很大，这使得云DB对弹性伸缩能力要求极高。问题一可以通过分库分表这类trick的方式缓解，但问题二对原有单体DB『存算一体』的架构提出了挑战。于是，存算分离的架构应运而生，也就是云原生数据库架构。

存算分离听起来很云端，似乎跟我们平时的工作关系很小。但其实有一类架构它就在我们身边，只是我们可能没有意识到它也是存算分离架构，那就是微服务架构。计算节点无状态，存储节点无计算；计算节点横向扩展，存储节点纵向扩展。

就像Duck Test讲的：如果它看起来像鸭子、游泳像鸭子、叫声像鸭子，那么它可能就是只鸭子。

四、『减』字诀

很多时候我们都讲不要过早优化，因为多数业务的初期，数据量都很少，任何设计都不太可能出现性能问题。反而业务上线后，由于进展不符合预期，导致调整业务逻辑的可能性更大。因此，怎么简单怎么来才是最优选择，更快的实现业务比业务跑得更快优先级更高。再者，你难道不觉得，就凭咱们拿的那万儿八千的工资，在非常合理的情况下，就不应该写出支撑千万并发的系统，嘛？

万一哪天系统开始出现性能瓶颈呢？该怎么办？恭喜哈，这是好事，说明公司赚钱了，更重要是通过你的系统赚钱了。首先，你要做的第一件事就是跟老板要经费，经费到手，万事不愁。然后，想办法把系统恢复到数据量小的时候，这不就又顺理成章的撑住了嘛？接着，经费没地方花了不是？总得找个地方放啊，我私下认为你的钱包就是一个不错的地方。

怎么把数据量再次变小呢？劝退用户是一个办法，但我估计老板可能太不乐意。

一个更可行的选择是优化数据结构和算法。比如给DB建索引就是一个办法，同样的查询，同样是千万级的数据，有索引和无索引的查询速度千差万别，因为索引会极大减少扫描的数据行数。

另一个选择是裁剪数据。就像Java的GC会定期清理垃圾一样，如果你发现DB里的数据大部分都是过期无效的，或者是基本上不会再查询到的数据，把过期数据归档，减少线上数据集的尺寸会是一个非常好的选择。该操作系统改造成本极低，对线上业务无影响，对数据后台则可以看心情逐步改造。所有相关人员都压力不大，但效果却是线上系统从此秒开，绝对骚得一批。其实前面提到的分片、分区、分库、分表，也都是在变相减小单位处理单元上的数据量，只不过它们改造成本高，实施难度大。特别是，在决定采用分表之前，应慎重考虑归档是不是一个更合理的选择。

当年做手游，发现游戏在4k屏的手机上运行极慢，手机的GPU根本带不动，尝试了各种优化手段都不好使。谁曾想，最终解决问题的，竟然是降低游戏的输出分辨率。

算法上缩，物理上减，现在连国家不开始提倡65岁退休了，我们的老系统也一定能才坚持几年。

五、『并』字诀

终于到了并发，一个大部分人都觉得应该有用，同时大部分人觉得用起来发怵的优化手段。

如果说前面的『池』、『序』、『分』、『减』这几条顶多算工程技巧，凭着我们聪明的大脑