《沉淀》是云栖社区品牌栏目,在品味技术人百味人生的同时,也能够帮助你沉淀技术,获得点拨。工作中,如果有不错的大牛让你受益匪浅,也欢迎通过电子邮件(lose.zy@alibaba-inc.com)推荐采访,让更多人受益。我们的想法是:“如果你觉得某个技术挺棒的,不妨品味这些技术人背后的沉淀。”
![8b3d404946005faeaffb62a03de1506b6cab7ec1](https://oss-cn-hangzhou.aliyuncs.com/yqfiles/8b3d404946005faeaffb62a03de1506b6cab7ec1.jpeg?x-oss-process=image/resize,w_1400/format,webp)
丁奇认为,MySQL设计简单,非常适合初创公司使用
丁奇(真实姓名:林晓斌),阿里云关系数据库服务内核开发和运维团队负责人,活跃的MySQL社区贡献者。专注于数据存储系统、MySQL源码研究和改进、MySQL性能优化和功能改进。
近日,云栖社区就MySQL之路、技术上的认识、团队管理心得以及如何学习MySQL等话题,对这位MySQL领域大牛进行了专访。
以下是采访正文:
和MySQL结缘源自“脸皮薄”
云栖社区:本科和硕士所学专业分别是?当初为什么要选择走上计算机这条路道路?
丁奇:本科学的是计算机应用,硕士阶段师从叶东毅教授学习数据挖掘方向。之所以走上计算机这条路,是因为我本质上是一个懒惰的人,程序员是一个鼓励“懒惰”和帮助“懒惰”的工作。
云栖社区:在计算机众多分支中,为什么会选择做数据库?
丁奇:为什么会选择做MySQL,这里有个故事。刚开始我也是MySQL的小白,而且2008年的时候不像现在网上有那么多前人经验分享,当时MySQL的问题上网一搜,很少有现成答案。用的时候会碰到各种“诡异”的现象,又没有资料可参考。比如平时一个更新语句执行响应时间都1毫秒,在线上偶尔会出现100毫秒。在贴吧这种对响应速度要求非常高的应用是能明显感知的,这个是必须弄清楚去解决的。
主管问这是什么原因,觉得是自己负责的模块,脸皮薄不好意思说不知道,就说去查下,结果上网搜不到答案。
所幸MySQL是开源的,于是就自己去看源码,也没人可以请教,就硬看。结果居然把那个问题解清楚了。
然后就在内网分享了一下。结果同部门的其他组,像百度百科、百度知道那时候也开始大量用MySQL,他们又碰到了其他的一些问题,发现内网里我写的文章,以为对源码很熟悉,也拿来一起讨论。当时自己肯定是不懂的,但觉得他们提的问题也挺有趣,就又去翻代码研究,然后把结果跟大家讨论,把结论分享到内网,结果成了一个循环。
其实我自己工作中碰到的问题不多的,但是很多人的问题一汇聚,查多了慢慢觉得做数据库底层还挺有意思的。
云栖社区:在百度贴吧那两年半的时间,你主要负责什么?那段时间,有什么收获?
丁奇:在百度贴吧从事服务端开发的工作,当时负责的贴吧权限管理等,需要比较灵活的关系维护。刚开始是用我们自己设计的文件存储来实现的,随着需求变得灵活,我们当时决定用关系数据库来维护。那时候选择了MySQL,就此开始跟MySQL,算起来也有8年了。
那时候最大的收获是学习了严谨的技术态度吧。同时刚毕业参加工作就接触这种超大容量、高并发请求的服务,对自己的技术视野的帮助还是很大的。
云栖社区:后来为什么入职阿里?面试过程顺利吗?
丁奇:我当时在业务部门,研究数据库源码其实是工作时间外的事情,后来觉得如果有个工作可以专心做数据库源码也挺好的。刚好看到当时淘宝核心系统正在招MySQL源码研发工程师,而且是章文嵩博士带的团队,就过来面试看看。来之前的想法是即使面不上,跟偶像见个面说上话也是开心的。
过程还算比较顺利。一个下午就把初面到HR面试走完了。章博士是技术终面,他让我介绍过去在MySQL上做的一些有意思的事情,然后他提出问题。当他第一个问题问出来以后,我差点怀疑章博士也做过数据库内核开发。
后来才知道这是他的面试方法:探测长板,就让被面试人说最拿手的部分,找到问题去探讨,看候选人的能力到哪里。这其实对面试官的要求很高,要很快的了解候选人陈述的最拿手事情的项目背景、解决方案,并能够从中敏锐发现问题。
所幸我比较属于会就说会,不会就说不会的类型,没有被当场找到什么破绽。相谈还算甚欢,没多久就入职了。
“第一颗糖最甜”:MySQL多线程复制方案最有成就感
云栖社区:在正明(章文嵩)带领的团队,你主要是做哪些方面的MySQL源码开发?主要成就有哪些?
丁奇:现在来看,也算不了什么成就。放在当时的技术环境还算不错,今天就不值一晒了。比如说,给CDN业务做的TPS优化,从300提升到18000,在当时来看,这是一个比较复杂的存储过程优化,但在今天来看就很正常。
另外,比较有意思的一事是:跟褚霸一起设计MySQL+Flashcache方案。那时候SSD刚在市场冒头,大家还不敢拿来当存储,就是作为二级缓存,拿开源的Flashcache来管理机械硬盘和SSD的配合。最开始的时候测试出来效果不行,其他团队准备放弃这个方案。我跟霸爷就分头啃代码,我看innodb,霸爷看Flashcache。结果分析出来,原来Flashcache算刷脏页阈值是按块的,按照两个源码的设计初衷,默认的那种部署方式就是性能有问题。
有个场景记得特清楚:那时候还在创业大厦那边,凌晨三点的时候改进部署,测试出来的效果跟我们分析代码后的预估相同。那种开心真是无法言喻。在那几天的分析中,也有些额外收益:从霸爷那边偷师学了好多好用的工具。
云栖社区:你曾先后设计了MySQL多线程复制方案、秒杀场景解决方案、高并发控制方案、binlog双写方案和切换连接保持方案等,在这些方案中,你对哪个最有成就感?为什么?
丁奇:要说成就感,这些都有。但是要说“最”的话,还是多线程复制。原因可能显得比较微妙,就像人家问100颗糖里面哪个最甜,大概是吃的第一个最甜。并行复制方案现在已经烂大街了,社区已经有4种以上的并行复制方案,但6年前这块却比较空白。
之所以能在6年前做出这样的方案出来,主要还是因为阿里这个平台。当时淘宝的业务发展非常迅速,需要做读写分离,但是有延迟的备库无法提供业务查询。我“潜伏”在各个业务群,发现几个大业务都在讨论这个问题。就自己分析原因,两周写了个版本,拿去DBA团队推销后,发现效果还不错。当自己的方案保证没有延迟的备库提供业务读,进而支持业务发展的时候,那一刻很有满足感。
经验分享:复杂系统改造功能实现不难,难的是如何证明没有引入新的错误
云栖社区:在MySQL源码开发上,有没有遇到什么困难?都是如何解决的?
丁奇:
对于一个复杂系统做改造,相比于实现功能,更大的困难是如何证明没有引入新的错误。这种要求7*24小时服务、管理数据的程序,修正错误的成本是非常高的。
对于这些困难,除了规范研发、代码Reivew流程外,我们还增加了一些额外措施来解决,比如,对于Bug修复和通用功能,我们会将Patch提交到社区。这样一来是回馈社区,二来可以收到一些反馈,最大的好处是如果官方吸收了Patch,我们就减少了维护工作量。
另外,我们也有一整套完善的自动化回归测试、稳定性测试、系能测试、崩溃恢复测试和集成测试系统。主干最新代码更新后1小时内就会部署到这些系统中测试。
云栖社区:在MySQL管理、性能调优和高性能架构部署上,是否有什么好的经验分享?
丁奇:这个问题有点大,我就说一个点吧,关于可诊断性。做数据库运维的同学更多的强调的是可靠性、稳定性、性能等。
其实不论是支持云服务,还是维护内部服务,可诊断性是体现一个运维系统成熟度的指标。
可诊断性包含但不只是我们常说的监控。以MySQL为例,除了binlog记录操作日志外,是否有系统能力记录所有的读写操作、是否有系统能力记录至少半个月内的链路状态随时备查?以及每个语句精确到微秒的起止时间,执行过程中的资源消耗等。
拥有这些数据只是基础,重要的是要有对这些数据做实时分析的能力。一个简单的问题是:作为一个DBA,如果你的业务方问你三个小时前,为什么CPU 100%持续了5分钟,你和你的系统有没有能力在2分钟内给出答案?
云栖社区:后来你开始维护阿里云RDS,能说说维护云上和本地的数据库主要有哪些差别吗?
丁奇:最大的差别是我们已经接触不到业务方。云服务的本质是提供基础服务,用户拿到一个MySQL实例,就可以按照业务需求去使用。
而DBA的同学们都知道,DBA有一个重要的工作是做业务架构讨论、业务评审、容量评估和SQL审核。因为这些都可能影响一个数据库的运行状态和服务质量。
但是在云上面,就没有接触业务方的机会。我们不再知道用户什么时候会上一个新业务,新业务里面包含多少全表扫描语句。这对我们的诊断系统、主动运维系统还有售后服务体系都是一个很大的挑战。
云栖社区:MySQL分支之一的AliSQL有什么特点?
丁奇:AliSQL分支上的特点是安全性和高性能。在安全上,我们有数据加密存储方案。通过修改源码,堵住了通过MySQL提权获取本地文件系统权限的关键通道,在安全性上我们做了很多改进的工作。
高性能一直是AliSQL的标签。从阿里自身业务维护开始,积累的性能优化经验都体现在AliSQL上,我们在执行计划、io优化、压缩优化上做了大量工作。
新增的功能也是AliSQL的一大亮点。我们有内置的支持秒杀场景的方案、有限制导出数据时单线程性能消耗的语法、高效清空线程占用资源减少内存消耗等功能。这些都是在长期服务内外部客户时,从需求中抽象和实现的功能。
团队管理遵循的原则:对他们好、换位思考
云栖社区:你现在负责ApsaraDB for RDS、ApsaraDB for Postgresql 开发和运维;ApsaraDB for SQLServer 运维、基础配置团队,能否分享下你在团队管理上的一些经验?
丁奇:我自己是从一线工程师慢慢开始带团队的(好吧,其实现在也还是一线工程师),没有专门学过管理,我遵循的原则主要是两点:1.对他们好;2.换位思考。
我经常想自己刚工作的时候,希望得到主管什么帮助,然后就知道该怎么做了。
工作的安排是非常重要的。我给同学安排工作的时候的指标有以下几个:
首先是“踮脚尖、能到达”。不能给太难的,尤其新人,否则会有大的挫败感,也影响项目进度。不能给太简单的,程序员最怕的是没成长。要让同学能用现有的知识,再多学一些新东西,最终能完成。
然后是“有领域,成专家”。工作中的安全感来源于自己的专业性。谁都希望完成工作的同时,把自己的厚度作起来。每个同学要有一个能够做深的事情,这个领域不一定要很大,但是在这个领域里,他就是最专业的专家。
还有一点是“可持续,有发展”。这说通俗一点就是,这个工作可以支持有能力、主动学习同学把自己的专业领域做大做深,还能支持他晋升。
由于主管的信息和资源更多,对于应届生或者工作时间较短的新人,上面几点我觉得并不难做到。
我的团队里面还有好多像德歌、彭立勋、印风、玄惭这样的高级专家,管理这样的专家其实也是摸着石头过河。
我觉得最重要一点,是要承认他们有很多比我厉害的地方。主管这个时候的优势只有一个,就是信息更多。多跟他们交流,说明他们的能力与团队目标匹配的地方。这些专家们就会发挥自己的能力,帮助我把团队的能力从各个方向强大起来。
团队跟人一样,是有气质的。在气质改造上,团队比人有优势。一个人要改自己的气质是很难的,而团队的气质是可以由很多人来互补的,由这些专家帮主管补上。
章文嵩博士说过一句话,团队主管不需要证明自己的能力,只要证明团队就可以了。
MySQL设计简单 非常适合初创公司使用
云栖社区:对比其他关系型数据库,能否分析下MySQL的优缺点?
丁奇:先说优点吧。一个是方便上手,一个是现在网上资料多。很多问题,现在上网都能找到现成的答案和经验,这就非常适合创业公司使用。毕竟大家还是看重业务,并且一开始也不会有很资深、很专业的DBA或者内核开发团队的配置。
缺点就是跟其他的数据库相比,能力还是比较简单。MySQL设计之初的出发点就是为了简单。虽然Oracle也在给MySQL发展各种能力,比如全文检索、GIS等功能,但是相比于PostgreSQL,这些功能还是有差距的。
云栖社区:MySQL5.7开始也兼容josn,对数据库的未来怎么看?
丁奇:MySQL有一个很好的引擎插件架构,这个就保持了增加各种能力的机会。官方5.7兼容json,5.6开始兼容NOSQL接口等等,就是为了把MySQL能力发挥出来。
后面几个大的数据库方向基本上还是朝着超大容量、分布式、HTAP的方向走吧。
云栖社区:从事MySQL开发,需要具备什么哪些知识储备?
丁奇:首先数据库的基本原理还是要了解,比如常见的存储数据结构、内存淘汰算法等等。语言方面MySQL是C/C++。
然后是最好有MySQL使用经验。当然如果到我们团队,即使没有经验,问题也不大,对于新人我们一开始就安排一些基本操作的练习,在线上值班过程中也会了解用户的使用方法。
其实最重要的是学习能力,其他都好说。
不建议一开始就看MySQL手册
云栖社区:你认为该如何系统地去学习MySQL?
丁奇:其实这个还是跟每个人的工作有关。如果是一个只有语言基础的新人,除了我上述说的了解基本原理以外,我觉得比较快的思路是参与一些比较简单的功能开发。不论是社区还是所在团队的需求。这样你在完成过程中会对所涉及的这部分会有清晰了解。
之后就顺藤摸瓜把相关的知识点弄清楚。基本上是一条线的感觉。
在有很多线的时候,就差不多是一个网了,这是一个很长的过程。到了网的密度很大的时候,就开始看MySQL手册,这时候会把“网孔”补上。
我个人是不建议一开始就看MySQL手册的,得有实战经验以后,去吸收才有效果,看了不会忘。
云栖社区:MySQL源码有上百万行,在阅读MySQL源码上是否有些属于你的诀窍?
丁奇:可能每个人有自己的学习复杂系统的路径,我自己是按照“带着问题去调研”的心态去看的。
当你处于要从源码中找出答案,来解心中疑惑时,一来有驱动力,二来是解决以后印象会很深刻,也有更多乐趣。
跟数据库源码打交道总体来说是一个很枯燥的过程,如果你试过不稳定复现多线程逻辑错误debug就知道。
所以有时候我开玩笑说什么样的人适合做数据库源码开发,就是没debug出来你很难受,查出原因时那个高兴劲儿能支持你又继续枯燥好久的那些人。
云栖社区:上段时间正明(章文嵩)离开了阿里,你也和正明共事过一段时间,能否从个人角度评价下他?
丁奇:这里引用正明离职时候,我在朋友圈发的内容:
“我的偶像、导师和引路人。有一种人是你远看有光环,靠近更能感受他的魅力。淘宝核心系统是一面旗帜,历经种种变化,但旗帜一直在团队里流转。很庆幸有那一段经历,跟着章博士,做纯粹的技术和技术人。”
相关学习视频: