环信CTO：“过早的性能优化是魔鬼”

　　以此文致敬“ Zen and the Art of Motorcycle Maintenance — An Inquiry into Values ”(中文名：禅与摩托车维修艺术，另译名：万里任禅游)一书。“擦车”一词，纯属戏谑，只因”cache”一词的汉语拼音和“擦车”一毛一样，又意附了原作“摩托车”的主题，实则和擦车没有任何关系，权当是标题党的又一次苦心积虑吧。

　　禅与摩托车维修艺术 – 经典闪回

　　这本书写于上个世纪 70 年代，经历 126 次被各大出版社拒绝后，由一个不抱任何盈利念头的编辑最终付梓出版，成为那个时代最为畅销的书籍：

　　累计销量已经超过 1000 万册，相信这一数据会持续攀升

　　《吉尼斯世界纪录》称它是”世界上被拒稿次数最多的畅销书”

　　《时代》周刊评选 20 世纪十本最有影响力的书之一

　　而最好的名人推介可能就算下面这个了(印在封面上以吸引读者的目光)：

　　我因为写了一部人们把它和 《禅与摩托车维修艺术》相比较的书而感到甚受恭维。我希望拙作(《时间简史》)和本书一样使人们觉得，他们不必自处于伟大的智慧及哲学的问题之外。

　　—- 著名物理学家 史蒂芬•霍金

　　这是一部“哲学小说”，书中内容由交替穿插的两种文体组成，一度让读者莫名其妙不知身在何处：一半是游记，记录了自己和儿子历经 17 天的摩托车之旅，横穿美国大陆从明尼苏达州直到加州海岸的行程;另一半则是哲学讨论，作者从旁观者的角度介绍曾经的自己(Phaedrus，斐德洛，精神分裂患者)不断苦苦思索，最终参透“良质”(不是良知，英文为“quality/good”)才是一切的源头和本质。

　　这绝对不是一本易读的书，书中的某些段落甚至是一句话，都需要我们反复体会其中深意。全书共分为四个部分，由浅入深，从表象到形而上学层层推进，带领读者渐次攀登到思想山峰的最高处。书中的后半部分逐渐趋向于形而上学的讨论，要真正的理解还需要做更多的功课;而前半部分仅涉及表象和实用主义层面的讨论，对于从事技术工作的人们却有着直接的启发。本文的下半部分就以此为参照，谈谈我们应该如何在技术挑战的过程中更加“投入”，达到“心流”的状态。

　　对 Cache 的执念

　　《禅与摩托车维修艺术》通过作者自己亲身的经历，给我们展示了一组“粗鲁”、“轻率”、边听音乐边工作的不合格的摩托车维修技师的形象，他们带给了作者一场真正的噩梦。也是因为这不好的维修体验，让作者痛定思痛，再不将自己心爱的摩托交给别人维修，而是通过不断钻研摩托车的表象构造和运行机理，从摩托车维修手册到各种零配件一应俱全的配齐，在何种恶劣的条件下和突发情况下都能游刃有余的处理事件，都不会“卡住”。

　　作为一个软件工程师，你究竟多“关心”你自己的代码，又投入了多少的“热情”在你日常的设计和编码工作中呢?当你认同“一个人应该关心并全情投入自己热爱的工作”时，又该如何持续的保持这份热情呢?相信每一个和我类似的“码农”读完这本书后，都会情不自禁的问自己这样的问题。即使暂时还搞不懂“良质就是佛陀”这形而上学的终极思辨。

　　如果一个人在工作的时候，能够看到良质，而且感觉到它的存在，那么他就是一个关心工作的人。如果一个人关心自己所看到的和手中所做的，那么他一定有某些良质的特性。

　　P311

　　前些日子做了一些系统本地缓存的优化工作，比起一些新的产品线拓展来说，并不见得有多少创造性，甚至有人会觉得不就是在既有系统上做的一些小小改动，无足轻重。但恰恰从其中让我体会到：如果你“关心”自己的工作，其实无时无刻都会被“良质”驱使，不断去专注的思考和践行，也能达到知微见著的哲学体验。

　　重新让思考进入到计算机的维度

　　缓存是互联网应用中最常见的组件，几乎每一个从业人员都耳熟能详。当大家谈论起缓存时，也大都会提到 Redis，它已经成为缓存领域的通用组件，你几乎可以在绝大多数的互联网产品架构设计中看到它的身影。于是，Cache=Redis 的烙印深深植入了每一个程序员的心里，大家也理所当然的认为Redis是解决缓存问题的终极方案，放一个 Redis 在系统架构中甚至成了一个下意识的动作。

　　当经历过几年的迭代，我们的系统架构中Redis也成为了最重要的信息存储组件，它的价值和系统的成本自然也成比例的与日俱增。可是，当我们把目光转向性能提升的时候，才发现Redis竟然成了性能的瓶颈，不得不要继续深入到缓存的密林深处，继续挖掘我们可以利用的机器资源来实现更高效的数据分布、更快的数据访问，进而提升系统的吞吐量和并发数。在这个过程中，你的思考方式需要逐渐从人的直觉体验转化为计算机的直觉体验，那股“心流”会让你与机器混为一体，你突然发现自己的思考时空尺度进入了一个更微小和高频的世界。

　　先来看下这个 Latency Numbers Every Programmer Should Know，你能够猜到一个 Redis 的跨网络查询调用和本地缓存的延迟差距吗?目前常见云服务商同一个机房中两个虚拟机之间的延迟为 1ms 左右，假设 Redis 内存访问和本地缓存的内存访问时间一致，均在 100ns 数量级，因此两者间的差距主要在于网络延迟，也就是 1ms(这个是理论简化数字，实际上我们观测到的 Redis缓存访问时延在5ms左右)，因此两者之间的数量级差异=1ms/100ns=1*1000*1000ns/100ns=10000。如果你以人自身的绝对体验尺度来衡量这1ms，也许它短的不值一提，毕竟人的一次眨眼都要花掉100ms+的时间。

　　但当我们将两者的相对差异放大到人的体验时间尺度后，就不显得那么不值一提了：

　　4分钟：11 天!这意味着如果你把机器的每次执行逻辑当成人的一秒，那通过本地缓存访问只需要4分钟完成的事情，通过 Redis 缓存访问需要 10 个工作日!要注意的是，这只是一次缓存访问带来的时间差异，如果你的缓存访问代码不断的被调用，那产生的时间差异真的会变成天壤之别(以人的时空尺度体验为参考)：假设连续调用 1000 次，那相当于 2 个月：30 年的差异。

　　缓存技术的本质

　　除了时间尺度上的比较，缓存技术真正的挑战在于如何在时间、空间、成本之间进行仔细的规划，达成全局最优化的目标。“事难两全”：在计算机架构中，越是高速的数据存储介质(如 CPU L1、L2 Cache)，单位成本越是高;而计算设备一定要在总经济成本的约束下来进行设计，因此整个计算机硬件配置中高速存储都是稀缺的，而海量数据的存储介质一定是访问速度最慢的。

　　如果把缓存的合理使用当成一个动态规划的问题，系统应该存在一定限制约束条件和特定计算问题前提下的最优解。如何让缓存系统动态的适应不同计算问题，使得数据能够在不同层级缓存中(L1，L2，Memory，Network，Disk，etc.)根据优化目标的要求进行自由的流动、重新部署是缓存架构的终极挑战。

　　特别的，数据在不同缓存介质中的这种流动，是应该基于数据本身的大小、被使用的频度、利用价值的存在周期等参数/反馈来进行动态计算的。理想中的(动态)缓存管理系统应该能够自适应，根据起始输入参数/数据集不断进行反馈调整，最终达到动态的最优分布。

　　近年来开始有更多的关于Dynamic Cache Management1，2的讨论，后续我们也将持续关注相关理论和技术的进展。

　　在机器思维和人类思维间切换

　　软件工程师始终是在以计算机思维考虑问题。但是由于我们开发的系统基本是为人服务的，随着你工作经验的积累，越来越多的业务、产品层面的思考会不自觉的将你重新拉回到客户/用户的思考维度，这会让你的架构设计、代码实现不自觉的又回升到人普遍感知的时空尺度。回看过去几十年软件设计的发展过程，面向对象(Object Oriented Design)、软件重用(Software Reuse)、领域规范语言(Domain Specific Language)、微服务设计(Micro-service Design)等等，都是在用业务、场景来引导我们的编码，我们早已习惯了用人类可读(Human Readable)的逻辑、语言来指导软件的设计和开发工作。

　　这一切都无可厚非，软件、互联网行业多年以来的蓬勃发展也证明了它的方向大致正确。软件行业会继续沿着“机器计算为人类服务”的方向不断演进变化。近年来风头正劲的“低代码”平台、AI Code to Coding等技术也在试图抹平人类和机器思维之间的鸿沟，让普通人也可以通过最善于流畅表达的人类思维模式来指导计算机满足自己的需求。另外，“过早的性能优化是魔鬼”这句业内格言也告诉我们，优先采用人类的思维，基于业务的结构来指导软件的编写是大的原则。

　　当我们为了提升软件系统的性能时，或靠着“良质”的驱使去不断调整软件系统以使所有的计算资源都不断逼近它们的极致状态时，不要忘了重新回到机器思维。在这个特有的机器时空维度上，我们会“锱铢必较”，算计每一个字节的存储、访问优化，每一类资源的合理利用和全局最优，以达到单位资源上更大规模的业务负载或者在指定业务负载前提下不断降低对资源的消耗，实现“绿色计算”的目的。

　　结语

　　《禅和摩托车维修艺术》是一本好书，却不是一本容易读懂的书。大道至简，但是作者通过了经年的冥思苦想才悟到了这一真谛，却是费尽了周折，读此书就如同跟作者一起回忆了整个思想形成的过程，虽辛苦但也算是小有收获。如果有机会能进一步研读，随着作者的行文脉络一并了解古今、东西方众多哲学先贤的著作及思想精髓，幸甚!