2017-阿里技术精选上册

1 .

2 . 扫一扫二维码图案，关注我吧 「阿里技术」微信公众号 「阿里技术」官方微博 

3 .

4 . 序 你好，我是阿里妹，第一次这么正式地写序，有点紧张。 2017 年， 在 技 术 发 展 的 历 史 上， 一 定 是 个 特 别 的 一 年： 柯 洁 与 AlphaGo 的惊世大战，无人咖啡店开放体验，AI 设计师“鲁班”横空出 世、三年投入千亿的达摩院正式成立…… 技术前进的脚步，比我们想象中更快。同样在今年，阿里技术公众号，正 式迎来了第 35 万位关注者，也有幸发布过数篇 10w+ 乃至百万阅读的文章。 PS：本想借此搞个联谊活动，瞅瞅后台性别比例 9:1，又默默放弃了。 有读者留言告诉我们，每天早上坐公交车上班，看阿里技术推送的文 章，已经成为了一种习惯。这让我们倍感不胜荣幸，又更觉肩上责任之重。 我们始终相信，每天一篇干货，效果虽不能立竿见影，但聚沙成塔、 滴水成川，你看过的东西，会成为你的一部分，潜移默化影响更多的人。 阿里技术公众号，看似只有阿里妹一个人运营。但在它身后，其实有 超过 25000 名阿里工程师的力量。这群可爱的作者里，有刚走出校门的 新人，有团队中的中流砥柱资深工程师，有带领数百、上千人的技术管理 者。他们在工作之余，抽出宝贵的休息时间，梳理自己对业务、技术、人 生的思考和理解。 没有华丽的词藻、繁复的修辞，只有朴质的代码、反复推敲的算法。 一篇文章看似只有几千字，但在背后，往往是数十人乃至数百人的团队， 长达数月、数年的摸索、跌倒，终于探得的成果。他们把这一路的所得， 迫不及待地分享给业界同仁，希望帮助大家少踩坑，少加班。 这次，在全年发布的近 300 篇文章中，我们选出 65 篇，集结成这套 《2017 阿里技术年度精选》，分为上、下两册，总计 600 余页。 

5 . 序　<　iii 这套精选集覆盖多个热门技术领域：算法、机器学习、大数据、数据 库、中间件、运维、安全、移动开发等，文章内容涉及技术架构、核心算 法、解决方案等干货。无论你是计算机相关专业的在校学生、科研机构的 研究人员，还是步入社会的 IT 从业人员，相信都能从中受益。 这套书同时收录了十多位阿里技术人的访谈：从工程师到合伙人的多 隆，6 年时间影响数亿用户的靖世，入选 MIT2017 年度 TR35 的王刚 & 吴翰清，免试晋升为研究员的钱磊等，将为你展现不一样的技术人生。 它不是一本系统讲述某个领域的书，更像是一本技术杂文选集，内容 五花八门。翻开书来，一眼望去，皆是散落在各个技术领域的结晶。你可以 把它当作床头书，或是在旅行的路上随手翻翻，充充电。希望这本书，能为 你打开一扇窗，去看更大的世界；成为一个小支点，帮你撬动更大的进步。 因为相信，所以看见。这世界依然浮躁，但庆幸始终有人相信，技术 让生活更美好。 感谢坚持分享、笔耕不辍的阿里工程师， 感谢所有关注阿里技术的小伙伴， 感谢所有的相遇与陪伴。 希望这套书，能陪你一起回味即将逝去的 2017。 2018，我们一起遇见更好的自己。 最后，阿里妹也期待你的回信，聊聊你的感想与建议：lunalin.lpp@ alibaba-inc.com 阿里妹 2017 年 12 月 

6 .目录 存储 / 数据库 1 深度解读 | 阿里云新一代关系型数据库 PolarDB 1 阿里在数据库智能优化路上，做了哪些探索与实践？ 16 如何降低 90%Java 垃圾回收时间？以阿里 HBase 的 GC 优化实践为例 37 如何打造千万级 Feed 流系统？阿里数据库技术解读 49 阿里下一代数据库技术：把数据库装入容器不再是神话 61 接下时序数据存储的挑战书，阿里 HiTSDB 诞生了 77 运维 96 超全总结 | 阿里如何应对电商故障？神秘演练细节曝光 96 如何高效排查系统故障？一分钱引发的系统设计“踩坑”案例 114 阿里毕玄：智能时代，运维工程师在谈什么？ 120 中间件 137 阿里 SRE 体系如何支撑 24 小时峰值压力、220+ 个国家“剁手党”？ 137 史上最复杂业务场景，逼出阿里高可用三大法宝 147 纯干货 | 从淘宝到云端的高可用架构演进 159 破解世界性技术难题！ GTS 让分布式事务简单高效 171 如何打造支撑百万用户的分布式代码托管平台？ 178 大牛观点 187 达摩院：阿里巴巴的科技雄心 187 阿里巴巴 CTO 张建锋：下一波创新机会，重点关注这三个领域 196 王坚博士专访 | 揭开国家 AI 创新平台“城市大脑”的神秘面纱 204 

7 . 目录　<　v 华先胜：视觉智能应用成功的关键因素有哪些？ 218 道哥自述：为什么弹性安全网络将诞生最大的人工智能？ 228 阿里开源 235 重磅！阿里巴巴正式开源全球化 OpenMessaging 和 ApsaraCache 项目 235 史无前例开放！阿里内部集群管理系统 Sigma 混布数据 240 深度分析 | 阿里开源容器技术 Pouch 244 分布式服务框架 Dubbo 疯狂更新 252 技术人生 257 北大博士在阿里：因为期待，你需要更出色！ 257 对着黑屏，背代码编程，他的终极目标是让自己失业 265 免试晋升为研究员，他在阿里十年经历了什么？ 274 多隆：从工程师到合伙人 | 阿里技术人纪录片 281 41 岁阿里工程师：35 岁转管理，真的是必经之路吗？ 291 技术变化那么快，程序员如何做到不被淘汰？ 298 如何成为一名顶尖的阿里架构师？ 309 浙大博士来阿里，为了打造地球最强的安全策略战队！ 316 从清华到阿里，他只用 6 年时间，影响了数亿用户 321 25 岁 Java 工程师如何转型学习人工智能？ 336 阿里科学家王刚、吴翰清同时入选 MIT2017 年度 TR35 开创中国互联网企业先河 341 从来往到钉钉，从技术 Leader 到产品负责人，陶钧到底经历了什么？ 352 

8 .

9 .存储 / 数据库 深度解读 | 阿里云新一代关系型数据库 PolarDB 贺军 阿里妹导读：本文通过描述关系型数据库发展的背景以及云计算的时代特征，分 享了数据库计算力的螺旋式上升的进化理念，另外结合阿里云 RDS 产品的发展路径， 阐述了自主研发的新一代云托管关系型数据库 PolarDB 的产品整体设计思想，对一 些关键技术点进行了解读。 关系型数据库 谈到关系型数据库，在这个知识日新月异的 TMT 时代，听起来有些“古董”， 这个起源于半个世纪以前的 IT 技术，事实上一直处于现代社会科技的核心，支撑着 

10 .2　>　2017 阿里技术年度精选（上） 当今世界绝大多数的商业科技文明。CPU、操作系统、数据库这三大核心领域，基本 上就是 IT 时代的缩影，同时也是一切信息化处理、计算力和智能化的基石。 从 1970 年 E.F.Codd 发表了一篇里程碑论文“A Relational Model of Data for Large Shared Data Banks” ，到 80 年代初期支持 SQL 的商用关系型数据库 DB2，Oracle 的面市，以及 90 年代初 SQL-Server 的诞生，都是关系型数据库成 功的代表。 时至今日，随着全球互联网的发展，大数据技术的广泛应用，涌现出越来越多的 新型数据库，然而关系型数据库仍然占据主导地位。最主要的原因之一就是关系型数 据库采用了 SQL 标准，这种高级的非过程化编程接口语言，将计算机科学和易于人 类理解认知的数据管理方式完美的衔接在了一起，目前还难以超越。 SQL 语言 SQL(Structured Query Language) 语 言 是 1974 年 由 Boyce 和 Cham- berlin 提出的一种介于关系代数与关系演算之间的结构化查询语言，其本质是用一种 类似于自然语言的关键字和语法来定义和操作数据，进行可编程的数据存储、查询以 及管理。 这种抽象编程接口，将具体的数据问题与数据的存放、查询实现的细节解耦开 来，使得商业业务逻辑以及信息管理的计算模式能够被大量复制和应用，解放了生产 力，也极大的促进了商业化关系型数据库自身的发展。 从 SQL 后来不断发展和丰富来看，SQL 已经成为关系型数据库语言的标准和王 者。到今天这种编程语言还没有更加完美的替代品。 OLTP 1976 年，Jim Gray 发 表 了 名 为 ”Granularity of Locks and Degrees of Consistency in a Shared DataBase”的论文，正式定义了数据库事务的概念和数 据一致性的机制。而 OLTP 是关系型数据库涉及事务处理的典型应用，主要是基本 的、日常的事务处理，例如银行交易。 

11 . 存储 / 数据库　<　3 事务处理需要遵循 ACID 四个要素来保证数据的正确性，包括原子性（Atomic- ity）、 一 致 性（Consistency）、 隔 离 性（Isolation）和 持 久 性（Durability）。 而 衡 量 OLTP 处理能力的性能指标主要有响应时间、吞吐率等。 开源数据库生态 在我们简要的回顾了关系型数据库的历史、地位和发展阶段后，我们不难看到 Oracle、SQL-Server、DB2 等关系型数据库仍然占据着全球商业数据库的主导地 位，虽然曾经耳熟能详的 Informix、Sybase 已经淡出大众的视线。 然而，从 20 世纪 90 年代开始，另一股推崇知识分享、自由开放的软件精神成 为趋势和潮流，尤其以 Linux、MySQL、PostgreSQL 等为代表的开源软件，开始 以强大的生命力不断发展壮大，释放出巨大的社会进步力量，这些被自由分享的科技 红利，孕育和促进了全球互联网高科技公司的飞速发展。 这是整个人类社会的进步，我们要感谢那些开源软件的斗士们，Richard Stall- man，Linus Torvalds，Michael Widenius 等。当然，最近几年国内涌现出越来越 多积极参与到开源主流社区的中国公司，也在不断地将技术分享回馈给开源世界。 根据 DB-engines 网站的最新统计，不难发现，当把开源数据库 MySQL 和 PostgreSQL 加在一起，开源数据库就已经超越了商业数据库 Oracle，成为世界上 最流行的关系型数据库。 

12 .4　>　2017 阿里技术年度精选（上） 云计算当前的阶段 如果说关系型数据库是 IT 时代的产物。那么在互联网时代的云计算，关系型数 据库目前正处于一个什么阶段呢？ IT 时代从某种程度上讲，更多是创造了计算力， 那么进入互联网时代的云计算，则是专注于用户和计算力的连接，提供无处不在的计 算力，这个其实是云计算商业模式的成功所在，可以称之为 1.0 版本。而云计算 2.0 版本，需要在云环境下，重新进化和升级计算力，这种进化体现了社会计算力的整合 以及计算资源能效的进步。 为了顺应绿色计算以及共享经济的发展潮流，不仅仅需要云服务器，云数据库， 网络互联，硬件芯片等等各个软硬件系统领域的融合以及演进升级，还需要坚持科技 以需求为本、服务以用户为根的科技普惠大众的理念来进一步促进计算效率和计算智 能的提高。 我们正处在一个蓬勃发展的云计算 2.0 阶段。在这个阶段，关系型数据库在云托 管环境逐渐暴露出一些问题，作为在云计算时代的先行者，Amazon 于 2014 年 11 月 12 日的 AWS re:Invent 2014 大会，发布 Aurora 云托管关系型数据库就是为了 解决这些问题。这个新一代的数据库的发布，也昭示着云计算时代，传统的 IT 技术 核心产品将揭开自我进化的序幕。 而 2017 年 SIGMOD 数 据 大 会，Amazon 发 布 了 论 文 ”Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Data- bases”, 更加开放的解释了基于云环境的 Cloud-Native 设计的关系型数据库是如何 应孕而生的。 为什么阿里云研发 PolarDB? 在我们回顾了关系型数据库以及云计算的背景之后，我们不难发现 , 云计算 1.0 虽然解决了用户和计算的连接的问题，但是还需要进一步解决在一个共享计算的环境 下，传统关系型数据库和公有云服务环境的融合问题。 云计算 1.0 用低廉的成本，灵活快速的部署、弹性和扩展能力，获得了传统 IT 计算上云的转换动力。在低成本享受普惠科技成为常态之后，随着用户业务的增长， 

13 . 存储 / 数据库　<　5 用户新的痛点开始出现，例如，如何从根本上解决用持续低的成本，享受和传统 IT 计算力一样，甚至更好的云服务，成为迫切需要。 这初看起来像伪命题，仔细分析之后，却淋漓尽致的体现了螺旋式上升的哲学思 想。就好像在 PC 服务器涌现的时代，PC 服务器首先用低廉的价格提供了和小型服 务器接近的计算能力，然后在保持成本和性价比优势的基础上，实现了超越小型服务 器的性能优势，直至终结了小型服务器时代，开始了 PC 服务器时代。 所以说云计算时代还远远没有到达鼎盛时期，除非它通过自身进化演变，在不断 保持性价比优势的同时，在具有快速灵活弹性的内在属性基础上，拥有超过传统 IT 计算力的能力之后，云计算才会真正进入它所主宰的时代，这只是个时间问题。 也就是说今天不只是阿里云要做这样一款关系型数据库，而是所有的云计算厂 商都不可避免的要经历这样一个阶段。那就是云计算时代传统 IT 计算力的重建和进 化！只不过 Amazon 走在了最前面，而阿里云紧跟其后，都需要经历这进化到蜕变 的过程。 在这个过程中，新一代关系型数据库是关键的里程碑之一。同理，接下来应该有 更多更加高级的云服务，比如智能云操作系统出现，来融合为云时代设计的硬件芯片 和网络互联等等。 在 IT 时代，传统的计算力（例如用关系型数据库来处理结构化数据等）是服务 于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户 Self-Service 租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决 IT 时代的技术产物和云计算时代应用环境的适配矛盾，正是云计算自我进化的内在推 动力。 例如，在公有云环境下，随着用户的增多，以及用户业务和数据的增长，备份、 性能、迁移、升级、只读实例、磁盘容量、Binlog 延迟等相关问题渐渐显现出来。这 背后大部分原因是由于 I/O 瓶颈（存储和网络）导致，亟须通过技术革新以及新的产 品架构解决这个问题。另一方面，从产品形态来讲，阿里云 RDS 目前的产品形态各 具优势，在下一节会详细介绍。 但是从产品架构的发展来看，除去数据库存储引擎的类型之外，对于关系型数据 

14 .6　>　2017 阿里技术年度精选（上） 库，考虑到工程效率以及运维成本，最好有一种通用的产品技术架构能兼顾不同用户 场景的需求，而不是针对每一个场景都实现一种对应的技术架构。 在接下来的内容，通过讲述阿里云 RDS 的不同产品形态的特点，我们会更加清 晰的了解到，PolarDB 的产品形态正是在吸收了之前几种产品形态的优点而孕育而 生的。 PolarDB 的设计思想用户需求和公有云自身发展的选择 作为云托管的关系 型 数 据， 除 了 关 系 型 数 据 库 的 核 心 特 征 之 外。 PoalrDB 更多的关注于如 何提供满足用户业务需求 的云服务，并且通过技术 革新，不断进化，在提供 更好的数据库计算力的同 时，满足用户以下业务需 求：上云成本、OLTP 性 能、业务连续性、在线业 务扩展、数据安全。 另一方面云计算除了成本优势之外，弹性和可扩展性也是云计算的天然属性。 为了用户业务的扩展，更好的 Scale Up 以及故障恢复，计算和存储分离的架构成为 云资源环境更好的选择。这一点将在下一节 RDS 产品架构的演进中得到进一步的 诠释。 阿里云 RDS 产品架构的演进 如上所述，阿里云 PolarDB 和 Amazon Aurora 数据库进化的方向是一致的， 然而进化的路径各有不同。本身来讲，这是由于各自的数据库云服务实现方式不同所 

15 . 存储 / 数据库　<　7 决定的。阿里云 RDS MySQL 有如下几个版本。这些产品形态满足不同的用户业务 场景，具有不同的特点，可以进行优势互补。 MySQL 基础版 MySQL 基础版采用数据库计算节点和存储节 点分离的方式，利用云盘数据本身的可靠性和多副 本的特性，同时也利用了 ECS 云服务器虚拟化来 提升标准化部署、版本和运维的管理效率，能够满 足低端用户不太注重高可用服务的业务场景。 同时这种架构对于数据库的迁移，数据容量的 扩容，计算节点的 Scale Up，计算节点故障恢复 都有天然的优势，根本原因就是计算和存储的分离。 后面也会讲到，PolarDB 也采用了存储和计算分离 的设计理念。 MySQL 高可用版 

16 .8　>　2017 阿里技术年度精选（上） MySQL 高可用版则是针对企业级用户提供的高可用数据库版本，提供 99.95% 的 SLA 保 障。 采 用 Active-Standby 的 高 可 用 架 构， 主 节 点 和 备 节 点 之 间 通 过 MySQL Binlog 进行数据的 Replication。当主节点发生故障，备节点接管服务。 同时还支持多个只读节点，支持负载均衡的数据读写分离的访问方式。采用 Shared-Nothing 架构，计算和数据位于同一个节点，最大程度保障性能的同时又通 过数据的多副本带来可靠性。 MySQL 金融版 MySQL 金融版可以说是针对金融行业等高端用户设计的高可用、高可靠云服务 产品，采用分布式 Raft 协议来保证数据的强一致性，拥有更加优异的故障恢复时间， 更加满足数据容灾备份等业务场景的需求。 PolarDB 的进化 PolarDB 采用存储与计算分离的技术架构，同时可以支持更多的只读节点。主 节点和只读节点之间是 Active-Active 的 Failover 方式，计算节点资源得到充分利 

17 . 存储 / 数据库　<　9 用，由于使用共享存储，共享同一份数据，进一步降低了用户的使用成本。下一节我 们将进一步从细节上描述 PolarDB 的关键特性。 PolarDB 的设计思想有几个大的革新。一是通过重新设计特定的文件系统来存 取 Redo log 这种特定的 WAL I/O 数据，二是通过高速网络和高效协议将数据库文 件和 Redo log 文件放在共享存储设备上，避免了多次长路径 I/O 的重复操作，相比 较 Binlog 这种方式更加巧妙。 另外在 DB Server 设计上，采用 MySQL 完全兼容的思路，完全拥抱开源生态， 从 SQL 的编译、性能优化器和执行计划等等都保留了传统关系型数据库的特色。并 且针对 Redolog 的 I/O 路径，专门设计了多副本共享存储块设备。 我们知道，分布式数据库一直是数据库领域的热点，具有非常大的实现难度。 不管是遵循 CAP 理论，还是 BASE 思想，通用的分布式关系型数据库基本上很难 做到技术和商用的完美平衡。与 SQL 标准以及主流数据库兼容，OLTP ACID 事 务 100% 支持，99.99% 的高可用，高性能低延迟并发处理能力，弹性 Scale Up， Scale out 可扩展性，备份容灾和低成本迁移等等，能够完美兼顾所有这些特点的商 用关系型数据库还没有出现。 阿里云 PolarDB 和 Amazon Aurora 的一个共同设计哲学就是，放弃了通用分 布式数据库 OLTP 多路并发写的支持，采用一写多读的架构设计，简化了分布式系 

18 .10　>　2017 阿里技术年度精选（上） 统难以兼顾的理论模型，又能满足绝大多数 OLTP 的应用场景和性能要求。 总之，100% MySQL 的兼容性，加上专用的文件系统和共享存储块设备设计， 以及在下文中提到的多项高级技术的应用，使得新一代关系型数据库 PoalrDB 在云 时代必将大放异彩。 PolarDB 产品关键技术点剖析 在讲述了阿里云 RDS 的不同产品形态之后，我们再从整体上看一看 PolarDB 的产品架构。下图勾画了 PolarDB 产品的主要模块，包括数据库服务器，文件系统， 共享块存储等。 PoalrDB 产品架构 

19 . 存储 / 数据库　<　11 如图所示，PolarDB 产品是一个分布式集群架构的设计。它集众多高级的技术 实现于一身，使得数据库 OLTP 处理性能有了质的飞跃。PoalrDB 采用了存储与计 算分离的设计理念，满足公有云计算环境下用户业务弹性扩展的刚性需求。数据库计 算节点和存储节点之间采用高速网络互联，并通过 RDMA 协议进行数据传输，使得 I/O 性能不在成为瓶颈。 数据库节点采用和 MySQL 完全兼容的设计。主节点和只读节点之间采用 Ac- tive-Active 的 Failover 方式，提供 DB 的高可用服务。DB 的数据文件、redolog 等通过 User-Space 用户态文件系统，经过块设备数据管理路由，依靠高速网络和 RDMA 协议传输到远端的 Chunk Server。 同时 DB Server 之间仅需同步 Redo log 相关的元数据信息。Chunk Server 的数据采用多副本确保数据的可靠性，并通过 Parallel-Raft 协议保证数据的一致性。 在描述了 PolarDB 的产品架构之后，我们再分别从分布式架构，数据库高可用， 网络协议，存储块设备，文件系统和虚拟化等方面逐一介绍下 PolarDB 使用的关键 技术点。 Shared Disk 架构 分布式系统的精髓就在于分分合合，有时候为了并发性能进行数据切分，而有时 候为了数据状态的一致性而不得不合，或者由于分布式锁而不得不同步等待。 PolarDB 采用 Shared Disk 架构，其根本原因是上述的计算与存储分离的需 要。逻辑上 DB 数据都放在所有 DB server 都能够共享访问的数据 chunk 存储服务 器上。而在存储服务内部，实际上数据被切块成 chunk 来达到通过多个服务器并发 访问 I/O 的目的。 物理 Replication 我们知道，MySQL Binlog 记录的是 Tuple 行级别的数据变更。而在 InnoDB 引擎层，需要支持事务 ACID，也维持了一份 Redo 日志，存储的是基于文件物理页 面的修改。 这样 MySQL 的一个事务处理默认至少需要调用两次 fsync() 进行日志的持久化 

20 .12　>　2017 阿里技术年度精选（上） 操作，这对事务处理的系统响应时间和吞吐性能造成了直接的影响。尽管 MySQL 采 用了 Group Commit 的机制来提升高并发下的吞吐量，但并不能完全消除 I/O 瓶颈。 此外，由于单个数据库实例的计算和网络带宽有限，一种典型的做法是通过搭 建多个只读实例分担读负载来实现 Scale out。PolarDB 通过将数据库文件以及 Redolog 等存放在共享存储设备上，非常讨巧的解决了只读节点和主节点的数据 Replication 问题。 由于数据共享，只读节点的增加无需再进行数据的完全复制，共用一份全量数据 和 Redo log，只需要同步元数据信息，支持基本的 MVCC，保证数据读取的一致性 即可。这使得系统在主节点发生故障进行 Failover 时候，切换到只读节点的故障恢 复时间能缩短到 30 秒以内。 系统的高可用能力进一步得到增强。而且，只读节点和主节点之间的数据延迟也 可以降低到毫秒级别。 从并发的角度来看，使用 Binlog 复制现在只能按照表级别并行复制，而物理复 制只按照数据页维度，粒度更细，并行效率更加高。 最后一点，引入 Redolog 来实现 Replication 的好处是，Binlog 是可以关闭来 减少对性能的影响，除非需要 Binlog 来用于逻辑上的容灾备份或者数据迁移。 总之，在 I/O 路径中，通常越往底层做，越容易和上层的业务逻辑和状态解耦而 降低系统复杂度。而且这种 WAL Redo log 大文件读写的 I/O 方式也非常适用于分 布式文件系统的并发机制，为 PolarDB 带来并发读性能的提高。 高速网络下的 RDMA 协议 RDMA 之前是在 HPC 领域被使用多年的技术手段，现在开始被使用到云计算 领域，也证实我的一个判断。云计算 2.0 时代，将重建人们对于云计算的认识，云端 也能够创造超越传统 IT 技术的计算力，这将是一个越来越严谨的工业实现。 RDMA 通常是需要有支持高速网络连接的网络设备（如交换机，NIC 等），通过 特定的编程接口，来和 NIC Driver 进行通讯，然后通常以 Zero-Copy 的技术以达 到数据在 NIC 和远端应用内存之间高效率低延迟传递，而不用通过中断 CPU 的方式 来进行数据从内核态到应用态的拷贝，极大的降低了性能的抖动，提高了整体系统的 

21 . 存储 / 数据库　<　13 处理能力。 Snapshot 物理备份 Snapshot 是一种流行的基于存储块设备的备份方案。其本质是采用 Copy- On-Write 的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写 时复制，将写操作内容改动到新复制出的块设备上，来实现恢复到快照时间点的数据 的目的。 Snapshot 是一个典型的基于时间以及写负载模型的后置处理机制。也就是说创 建 Snapshot 时，并没有备份数据，而是把备份数据的负载均分到创建 Snapshot 之 后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。PolarDB 提供 基于 Snapshot 以及 Redo log 的机制，在按时间点恢复用户数据的功能上，比传统 的全量数据结合 Binlog 增量数据的恢复方式更加高效。 Parallel-Raft 算法 谈到分布式数据库的事务一致性，我们很容易想到 2PC（2 Phases Commit）， 3PC（3 Phases Commit）协议。而论数据状态一致性，我们就不得不提到 Leslie Lamport 发明的 Paxos 协议，在 Paxos 为 Google 等互联网厂商所广泛应用到多 个分布式系统实现之后，Paxos 成为了最受关注的数据状态一致性算法之一。可是 由于 Paxos 算法论文的理论和实现过于复杂，导致难以被快速应用到工程技术上。 Paxos 解决的问题之一是，在多个机器的集合中，集合中初始状态相同的任何 机器能否通过相同的命令序列到达同样相同的状态点，形成一个一致的收敛的状态 机。另一个问题是，作为集群中的一员，通过微观的时间串行通讯方式，需要找到一 个始终有效的协议，当一个机器的某个数据状态需要改变时，需要和整个集群（包括 其他机器）靠通讯和协议达成相同的认知，一起认同这个机器上的某个状态的改变。 基于这两点，基本上就解决了分布式集群架构中，不同角色的机器，达成一致性 状态机的问题。也就可以进一步设计出绝大多数分布式系统的框架。 Paxos 可以堪称是 P2P（Peer to Peer）的对等设计，更加抽象和通用，也更 难以理解。而 Raft 则是选举出 Leader，再经由 Leader 发起对其他角色进行状态一 致性更新的实现，更容易理解。而协议本身的实现流程和 Paxos 有相似之处。 

22 .14　>　2017 阿里技术年度精选（上） Parallel-Raft 是在 Raft 协议的基础上，针对 PolarDB chunk Server 的 I/O 模型，进行改良的一致性算法。Raft 协议基于 Log 是连续的，log#n 没有提交的话， 后面的 Log 不允许提交。而 PolarDB 实现的 Parallel-Raft 允许并行的提交，打破 了 Raft 的 log 是连续的假设，提高并发度，通过额外的限制来确保一致性。 Docker 容器虚拟化技术最早的出现是 Linux 内核为了解决进程在操作系统之间，或者在 进程运行过程当中做迁移，通过进程和操作系统之间的解耦，来达到进程运行时的上 下文和状态能够保存，复制和恢复的目的。可是 LXC 的实现，却促成了曾红极一时 的 Docker 的诞生。 从原理上讲，容器虚拟化的实现相对于 KVM 等虚拟化技术而言，更加轻量级。 如果用户不需要感知整个操作系统的功能，那么用容器虚拟化技术理论上应该能够获 得更好的计算能效比。 其实 LXC 加上 Cgroup 这种进程虚拟和资源隔离的方式已经被使用很多年，在 HPC 领域就常被应用到 MPI 超级任务的 checkpoint 和 restart 恢复上。PolarDB 采用 Docker 环境来运行 DB 计算节点，用更轻量的虚拟化方式，解决了资源的隔离 和性能的隔离，也节省了系统资源。 User-Space 文件系统 谈到文件系统，就不得不提一下 IEEE 发明的 POSIX 语义（POSIX.1 已经被 ISO 所接受），就像说到数据库要谈到 SQL 标准。通用分布式文件系统实现的最大挑 战就是在完全兼容 POSIX 标准的基础上提供强劲的并发文件读写性能。 可是 POSIX 的兼容势必会牺牲一部分性能来获得对于标准的完全支持，同时系 统实现的复杂度也极大的增加。说到底是通用设计和专有设计的取舍和区别，也是易 用性和性能之间的平衡，这是个经典问题。 分布式文件系统是 IT 行业最经久不衰的技术，从 HPC 时代，云计算时代，互 联网时代，大数据时代一直在推陈出新，其实更严格的说应该是针对不同应用 I/O 场 景涌现出很多定制化的实现，再说白点，就是不去支持 POSIX 标准。 

23 . 存储 / 数据库　<　15 这一点上，只能说知难而退，不过只服务于专门的 I/O 场景时，不适用 POSIX 也不是什么问题。这一点，和从 SQL 到 NoSQL 的发展如出一辙。支持 POSIX 的文件系统，需要实现兼容标准的文件读写操作的系统调用接口，这样对于用户而 言，就无需修改 POSIX 接口实现的文件操作应用程序。这样一来就要求通过 Linux VFS 层来铆接具体的文件系统内核实现。这也是导致文件系统工程实现难度加大的 原因之一。 对 于 分 布 式 文 件 系 统 而 言， 内 核 模 块 还 必 须 和 用 户 态 的 Daemon 进 行 数 据 交 换， 以达到数据分片以及通过 Daemon 进程传送到其他机器上的目的。而 User-Space 文件系统提供用户使用的专用 API，不用完全兼容 POSIX 标准，也无 需在操作系统内核进行系统调用的 1:1mapping 对接，直接在用户态实现文件系统的 元数据管理和数据读写访问支持即可，实现难度大大降低，并且更加有利于分布式系 统的进程间通讯。 小结：通过以上的介绍，我们不难发现，PolarDB 采用了从计算虚拟化，高速 网络互联，存储块设备，分布式文件系统，数据库物理 Replication 等全方位的技 术手段，可以说是众多热点技术的集大成。正式这些关键技术的整合创新，才使得 PolarDB 的性能有了质的飞跃。 

24 .16　>　2017 阿里技术年度精选（上） 阿里在数据库智能优化路上，做了哪些探索与实践？ 乔红麟 阿里妹导读：近期，2017 中国应用性能管理大会（简称 APMCon 2017）圆满 落幕。阿里巴巴数据库事业部高级技术专家乔红麟发表了题为《数据库智能优化系统 的探索与实践》的演讲，现场解读了过去几年阿里巴巴数据库团队在面对数据库规模 急速增长以及业务变化越来越快的情况下在智能数据库诊断优化方面的一些探索和实 践经验。 以下为演讲实录： 乔红麟：谢谢主持人，大家下午好。今天给大家分享一下我们团队在数据库优化 方面做的一些事情。阿里的数据库场景与其他公司可能会有一些不同，所以今天的分 享更多是基于阿里的场景和规模所做的一些思考和实践。 先简单介绍一下我自己。我在 2015 年加入阿里，目前负责阿里数据库智能优化 产品 CloudDBA 的开发。我今天的分享主要有这几方面： 

25 . 存储 / 数据库　<　17 首先讲一下在阿里对数据库优化服务的诉求。我相信大家在数据库性能优化 方面都有很多的经验教训，不同公司对优化的具体做法也不太一样。在方式上大 部分企业应该还是重人工模式，就是由数据库能力比较强的人，比如 DBA，来解 决数据库性能问题。但阿里今天的数据库规模非常大，不管我们有多少 DBA，我 们的人员增长速度都无法跟上业务发展的速度，单纯依赖 DBA 已经无法满足业务 发展需求。 第二方面讲一下我们的 CloudDBA 是如何做的，里面涉及到哪些技术，希望把 这些技术分享给大家。如果大家所在的公司也在做类似的事情，希望能够提供一些参 考和帮助。 第三方面大概讲一下目前正在探索的一些事情。现在人工智能技术比较火，数据 库相对来说是比较传统的领域。如果我们将机器学习、深度学习这样的技术引入到数 据库领域，它到底能做些什么，具体到数据库优化领域又能做什么，这是我们正在探 索的一些事情。 

26 .18　>　2017 阿里技术年度精选（上） 一、阿里数据库优化服务诉求 第一部分、业务诉求 首先从整个阿里数据库的角度看一下对于数据库优化服务的业务诉求，这也是我 们做这个产品最大的驱动力。 1、服务产品化。阿里业务发展速度远远超过了 DBA 团队发展的速度，单独依 靠 DBA 重人工支持模式变得越来越困难，因此我们在几年前开始尝试通过产品来完 成 DBA 人工做的一些工作。通过产品解决 DBA 人工服务的扩展性问题，是我们最 直接的诉求，希望能把 DBA 人工服务产品化。 2、全局规模优化。站在全局角度来看，数据库规模迅速增大的同时也带来了 巨大的成本压力。成本这块怎么理解呢？只要业务有需求，理论上可以通过增加更多 的机器来满足业务需求。 但是从另外一个角度来讲，这些机器是不是一定要加，是不 是有一些机器可以通过优化节省下来给新的业务服务。当规模非常大的时候，所做 的一小点规模化优化，所节省的成本可能都是很可观的。因此我们需要有全局规模 优化的能力，仅仅一个数据库实例内部做的优化都是一些局部优化，以全局角度来 看是不够的。 3、主动诊断。从运维的角度来看，阿里同其它公司一样，就是要尽量避免故 障的发生。在阿里的业务场景下，大部分业务跟数据库有着非常紧密的关系。数 

27 . 存储 / 数据库　<　19 据库一个微小的抖动，都可能对业务造成非常大的影响，所以如何让数据库更稳 定是非常重要的业务诉求。比如一个最常见的情况，有很多线上 SQL 性能是有问 题的，这些 SQL 会给业务稳定性带来一定的风险。那么我们能不能通过产品主动 对线上有问题的 SQL 进行主动诊断，提前做优化，而不是 SQL 引起故障后才去 优化。 4、智能异常发现。线上业务负载不断地变化，业务行为、用户行为也在不断地 变化。传统基于阈值设置报警的方式无法可靠、及时地发现数据库故障或者异常。如 何可靠地去发现数据库异常，甚至是提前预测到故障的发生并进行及时干预，是有很 强的业务需求的，但同时也有非常大的技术挑战，尤其是在阿里这么大数据库规模场 景下。 5. 容量预估。还有一些业务诉求是容量预估的需求。比如什么时候需要扩容， 如何更精准地对数据库容量做出预估，这些方面后面我会稍微展开一下。 第二部分、用户诉求 另外一部分诉求是使用数据库这些人的诉求，也就是我们的开发人员。每个公司 数据库服务方式有所不同。这里我列了一些开发人员经常会问到的一些问题，这些问 题背后的诉求让我们思考我们的产品站在开发者的角度，要解决什么问题。在业务发 生异常的时候，需要快速定位到整个链路到底哪块出了问题。之前 DB 对于开发者来 

28 .20　>　2017 阿里技术年度精选（上） 说是一个黑盒，不管是信息透明方面，还是大家对数据库领域的知识方面，对于 DB 的了解程度可能都不够，不知道 DB 是什么状态，发生了什么问题。具体来讲用户诉 求主要有： 1、信息透明，自助优化。我们期望用户能够自助发现和解决数据库的性能问题， 并非发现问题先去找 DBA，这样整个流程会比较长，时间成本也比较高。但做到自 助化，首先用户能够全面了解数据库的运行情况。 2、持续优化。只要业务在线上运行就会不断的变化，业务负载不断变化、用户 行为也会不断变化。所以数据库优化是个持续的过程，并不是今天发现一个问题解决 了，以后就不出现问题了。尤其是互联网的应用，持续优化尤其重要。 3、量化跟踪，流程闭环。开发人员经常会问到一个问题，上次帮他做的优化， 结果到底怎么样。我们知道并不是每个优化都是实际有效的，因为很多优化方案是基 于当时的信息和场景做的一个判断，实际优化结果只有当应用之后才能真正去做评 估、做衡量，所以我们要提供量化跟踪和评估的能力。另外，我们期望整个优化流 程，从发现问题到最终解决问题在产品内能够闭环，开发人员能够自己完全自助化走 完整个流程，而不需要 DBA 的参与。流程闭环也是产品必须具备的能力。 4、输出产品，而不是人。不断有新的业务上线，而我们的 DBA 就这么多人， 并且每个人有不同的侧重。对于一些快速发展的业务，在早期我们可能没有 DBA 去 做特别支持的，但这些业务的数据库反而是容易出问题的。开发人员如果能够通过产 品解决问题，而不是凡事都去找 DBA，解决问题的效率会更高。将我们 DBA 的能力 通过产品进行输出，更好去支持我们的业务。 所以今天我们做 CloudDBA 产品 , 是希望我们能够通过产品的方式把 DBA 专家 服务提供给业务开发同学，实现 DBA 人力的扩展。同时我们需要具备全局规模优化 能力，这是在阿里对数据库优化服务的业务诉求和用户诉求，也是我们做 CloudDBA 这个产品的动机。 

29 . 存储 / 数据库　<　21 二、CloudDBA 关键技术 首先简单介绍下 CloudDBA 在阿里的发展历程。早期我们团队有很多非常牛的 DBA，经常是一个人当千军万马的感觉，那个阶段优化更多依赖于 DBA 人工完成。 之后我们开发了一些工具，让工具来完成简单的优化操作。几年前我们的理念转变为 所有数据库服务都应该由产品来做，所以我们在数据库运维，管理，优化等方面都有 相应的产品，开始进入自动化阶段。 未来数据库优化服务会从自动化发展到智能化，这是我的判断。今天仍然有很 多问题是解决不了的，比如精确的容量预估，智能的异常发现，故障提前预警等。现 在我们有非常多的数据，也有数据加工分析的技术，所以我们开始进行一些探索，通 过数据分析和机器学习等技术手段来解决之前解决不了的问题。比如最简单的容量预 估，每年都会做预算，做容量预估。至少我现在还没有看到特别多的公司去用很科学 的方式，完全基于业务目标以及历史数据的分析来做容量预估。很多时候容量预估是 靠拍脑袋决定的，但是今天有了大量的数据和加工数据的技术手段，我们是不是可以 做更精准的容量预估。举这个例子来说明一下，未来很多的优化应该向智能化方向去 思考，去探索。 CloudDBA 在阿里大概是这样的一个发展历程，我们今天还处于自动化阶段， 但同时也有一些智能化的实践。未来我的判断是我们一定向智能化去走，后面会在这 方面尝试更多的探索。 说了这么多，那么 CloudDBA 到底是什么？ PPT 上面有一句话，“CloudDBA 是一个数据库智能优化产品，面向开发人员提供自助化诊断优化服务，致力于成为用