2017阿里巴巴云栖大会数据库内核专场,内容概要

9月 27th, 2017

引言:

个人的上一篇博客,已经是6个月前的事(还是一个招聘贴),而有技术价值的博客文章,更是要回溯到2016年的5月份,这么长时间不维护博客,还是挺惭愧的。但其实这两年来,真不是在偷懒。总结起来,跟团队小伙伴们一起,就干了三件事:

  1. 我们做了一个新的数据库存储引擎X-Engine。目前在sysbench标准化测试下做到了65万的TPS,相同硬件下是InnoDB存储引擎最优性能(11万左右)的6倍左右。当然,离我们的目标:10倍性能,1/10成本还有一定的差距。
  2. 我们做了一个高性能可全球化部署的MySQL数据库集群(基于自研的X-Paxos分布式一致性算法和我们的AliSQL),异地部署下是MySQL官方Group Replication性能的5倍以上,并且在阿里集团内核心业务线真正落地。
  3. 我们基于X-Paxos、X-Engine等核心技术,做了一个真正一体化的分布式关系型数据库X-DB。集水平扩展能力、持续可用能力、高性能、低成本于一体。

在今年的阿里巴巴云栖大会上,我们也申请了一个阿里巴巴数据库内核专场,时间是2017年10月13日下午,详细信息可见云栖大会官网链接:阿里数据库内核专场 通过这个专场,我们准备跟大家交流探讨下我们团队在这三件事上的思考和技术细节,欢迎感兴趣的小伙伴们莅临指导!

本文的以下部分,简单分享了我们近两年所做工作的背景和动机,以及数据库内核专场的5个主题的内容大纲。

阅读全文…

标签:

阿里巴巴数据库内核团队简介&纳新

3月 8th, 2017

我们是谁?

 

阿里巴巴数据库内核研发团队,汇聚国内最顶级的数据库内核研发专家15+人。团队所有成员,无论工作年限长短,均在一线研发岗位,我们的宗旨:能动手绝不动口。(Show me the Fxxxing Code)

 

我们做什么?

 

我们团队负责维护、研发的数据库内核产品,覆盖了阿里巴巴系公司90%以上的在线业务。典型的产品包括:

AliSQL:我们团队维护超过5年以上的开源MySQL分支,支撑了过去5年的双11大促。针对阿里的业务诉求,在性能、成本、稳定性和可运维性等方面有非常多的突破。以库存热点为例,优化后的AliSQL相对于官方MySQL的性能有着200倍的性能提升。对此感兴趣的同学,可以参考我们在2015年中国数据库大会上以及2016年在Percona Live上分别做的分享:

  1. AliSQL_5.6及其应用
  2. What’s new in AliSQL – Alibaba’s branch of MySQL

X-Paxos:我们团队自研的高性能分布式一致性协议(Paxos),经典Paxos的功能、作用毋庸赘述,结合阿里的业务场景,我们在功能上和性能上提出了很多创新和突破。例如,功能上,Online Leader Transfer、策略化多数派和权重化选主、节点角色定制化等等。性能上,结合Batching、Pipelining、异步化和Lock-Free,X-Paxos做到了极高的性能,同城部署下能达到竞品几十倍的性能,异地部署下(网络RTT 30ms+时)的性能指标,相对于同城部署几乎保持不变。

AliSQL X-Cluster:基于AliSQL和X-Paxos,我们团队自研的高性能三副本AliSQL集群。相对于官方的MySQL Group Replication,我们的X-Cluster有着更丰富的功能和更高的性能。同城部署下,X-Cluster三副本性能跟AliSQL单机性能基本持平(X-Paxos协议带来的性能损耗在2%以内)异地部署下(30ms网络RTT),X-Cluster性能是官方MySQL Group Replication的5倍以上,响应延时(RT)是MySQL GR的一半以下。为什么我们关注极致的异地部署性能,因为我们要解决的正是阿里巴巴极致的异地多活诉求。关于X-Paxos、AliSQL X-Cluster的技术细节,我们将在今年4月份的Percona Live上做一个分享,感兴趣的同学届时可以关注。

  1. AliSQL: breakthrough for the future

当然,AliSQL,X-Paxos,AliSQL X-Cluster只是我们团队产品的一部分,基于各种原因,我无法将团队所有工作在此一一展示。但是我们团队的愿景非常简单:打造数据库内核研发世界第一团队,做出世界最好的数据库产品。而支持我们这一愿景的最坚强后盾,则是阿里巴巴拥有的世界上最大的在线交易、支付平台。业务的需求,是技术发展的第一助推力。记得之前我跟一个国外顶级大学的博士同学交流,我提了一个非常高的事务处理指标,该同学听后问我:这么高的性能,你们用得着吗?当时我的回答很简洁:可能其他公司用不上,但是阿里用得着,我们有一个无与伦比的双11场景。借用我们团队同学的一句话:“今年主要的感觉是,数据库又成为一个年轻的领域了,随着新硬件,新技术的不断涌现,传统数据库的软件架构即将被颠覆,而我们所幸在一个对数据库需求极强的公司,有丰富的应用场景,高性能、高可用性、高扩展性的要求对我们提出了巨大的挑战。我们必须解决这些问题,站在这个关键的技术换代的节点上,把握住这次机会!

 

我们需要什么样的人?

 

既然是招聘贴,就要有招聘贴的样子,与其说是我们需要什么样的人,不如说是分享下我所欣赏的技术人的特点:
1. 发自内心的喜欢做技术,有强烈的自我驱动力,永不服输。工作也好,生活也罢,不会一帆风顺,困难是常态。
2. 扎实的技术基本功。我们团队,无论是刚入职的新人,还是工作10年以上的老人,都坚持在一线Coding,未来是想出来的,更是做出来的。基本功包括:C/C++编码基础、Linux系统基础、数据结构和算法基础、并发编程基础等。
3. 扎实的数据库基础理论和数据库内核研发经验是加分项,但不是必须的必须的是,你必须有至少一项技术特长,在自己的技术领域内证明过自己。我一直坚信的理念是:技术是互通的,优秀的技术人,只要内心愿意去尝试,在绝大部分技术领域都能够获得成功。
4. 强烈的好奇心,不按部就班,持续学习。技术领域一个非常鲜明的特点,就是你所知道的掌握的技术,可能都是过时的。因此技术人员需要保持不断学习,阅读英文论文的能力是必须的。

 

此贴面向哪些人群?

 

1. 国内外应届本科生、硕士生、博士生,想来我们团队实习的在校大学生
2. 国内外数据库内核研发人才
3. 有着深厚研发基础,但对数据库内核不是特别熟悉的研发人才。你有意愿(尝试新领域),我有信心(让你在这个新领域内落地,并做出突破)

 

如何联系我们(我)?

 

何登成 资深技术专家 阿里巴巴数据库内核团队负责人

2005年第一次进入数据库内核研发领域,没想到不仅在这个领域一干就是12年,而且每年都会从中体会到新的惊喜。
邮箱:         dengcheng.hedc@gmail.com
Github:     https://github.com/hedengcheng
个人网站:   http://hedengcheng.com/
微博:         何_登成

标签:

生活中的Paxos,原来你我都在使用——对Paxos生活化的解读

5月 15th, 2016

 

目录

引言    1

什么?老婆要在家里搞民主…    2

全民献计第一战,明确分工    2

一波未平一波又起,你不能总是变    4

没想到啊没想到,献计献策变成了处处抢占先机    6

让我们做一个规范总结吧    8

一切并未结束    9

写在最后    11

 

引言

 

前段时间,老婆给家里一岁半的小宝买了一套 克里斯.费利 博士的《宝宝的物理学》丛书,包括 《宝宝的量子物理学》,《宝宝的牛顿力学》,《宝宝的光学》等。小宝爱不释手,天天缠着我们读给他听,在整个过程中我也有很大的收获。在同一时间,由于工作需要,我也一直在啃计算机分布式系统中号称最难理解的协议——Paxos。看PPT、读论文、找相关文章,跟同事讨论,一段时间下来,总的来说也有一定的收获。两件事一结合,当时就萌生了一个想法,我能不能也像 费利 博士这样,用比较通俗易懂的文字(图画做不到,没这个功底…)来描述Paxos,让更多的人能够理解,进而使用。

 

有了这个想法后,一发不可收拾,隔三差五就会从大脑中蹦出来,我也一直在构思应该怎么来写,如何动笔,时至今日,感觉基本上成熟了,也就落笔开始了下面的这篇文章。全文以家庭中的日常生活为背景,以生活中的小例子为引子(故事情节纯属YY…),来逐步揭开Paxos协议的原理,希望阅读的朋友们能够从中获益!

 

阅读全文…

数据一致性-分区可用性-性能——多副本强同步数据库系统实现之我见

3月 27th, 2015

新浪微博:@何_登成

1    背景    1

2    问题一:数据一致性    3

3    问题二:分区可用性    6

4    问题三:性能    8

5    总结    10

6    问题四:一个极端场景的分析    10

 

  1. 背景

 

00

最近,@阿里正祥(阳老师)发了上面的一条微博,谁知一石激起千层浪,国内各路数据库领域的朋友在此条微博上发散出无数新的话题,争吵有之,激辩有之,抨击有之,不一而足。总体来说,大家重点关注其中的一点:

在不使用共享存储的情况下,传统RDBMS(例如:Oracle/MySQL/PostgreSQL等),能否做到在主库出问题时的数据零丢失。

这个话题被引爆之后,我们团队内部也经过了激烈的辩论,多方各执一词。辩论的过程中,差点就重现了乌克兰议会时场景…

02

庆幸的是,在我的铁腕统治之下,同学们还是保持着只关注技术,就事论事的撕逼氛围,没有上升到相互人身攻击的层次。激辩的结果,确实是收获满满,当时我就立即发了一条微博,宣泄一下自己愉悦的心情J

01

微博发出之后,也有一些朋友回复是否可以将激辩的内容写出来,独乐乐不如众乐乐。我一想也对,强数据同步,数据一致性,性能,分区可用性,Paxos,Raft,CAP等一系列知识,我也是第一次能够较好的组织起来,写下来,一来可以加深自己的印象,二来也可以再多混一点虚名,何乐而不为J

这篇博客文章接下来的部分,将跳出任何一种数据库,从原理的角度上来分析下面的几个问题:

  • 问题一:数据一致性。在不使用共享存储的情况下,传统RDBMS(例如:Oracle/MySQL/PostgreSQL等),能否做到在主库出问题时的数据零丢失。
  • 问题二:分区可用性。有多个副本的数据库,怎么在出现各种问题时保证系统的持续可用?
  • 问题三:性能。不使用共享存储的RDBMS,为了保证多个副本间的数据一致性,是否会损失性能?如何将性能的损失降到最低?
  • 问题四:一个极端场景的分析

阅读全文…

一个最不可思议的MySQL死锁分析

1月 24th, 2014

 

1    死锁问题背景    1

1.1    一个不可思议的死锁    1

1.1.1    初步分析    3

1.2    如何阅读死锁日志    3

2    死锁原因深入剖析    4

2.1    Delete操作的加锁逻辑    4

2.2    死锁预防策略    5

2.3    剖析死锁的成因    6

3    总结    7

 

 

  1. 死锁问题背景

 

做MySQL代码的深入分析也有些年头了,再加上自己10年左右的数据库内核研发经验,自认为对于MySQL/InnoDB的加锁实现了如指掌,正因如此,前段时间,还专门写了一篇洋洋洒洒的文章,专门分析MySQL的加锁实现细节:《MySQL加锁处理分析》。

 

但是,昨天”润洁”同学在《MySQL加锁处理分析》这篇博文下咨询的一个MySQL的死锁场景,还是彻底把我给难住了。此死锁,完全违背了本人原有的锁知识体系,让我百思不得其解。本着机器不会骗人,既然报出死锁,那么就一定存在死锁的原则,我又重新深入分析了InnoDB对应的源码实现,进行多次实验,配合恰到好处的灵光一现,还真让我分析出了这个死锁产生的原因。这篇博文的余下部分的内容安排,首先是给出”润洁”同学描述的死锁场景,然后再给出我的剖析。对个人来说,这是一篇十分有必要的总结,对此博文的读者来说,希望以后碰到类似的死锁问题时,能够明确死锁的原因所在。

 

阅读全文…

2013年个人微博推荐技术资料汇总

12月 25th, 2013

2013年,过的很充实,生活上如此,技术上亦是。这一年,看了很多的技术资料,技术上也有了很大的提高。而且,本着分享的精神,很多好的技术资料,也都在个人微博@何_登成 上做了推荐。今天,下定决心将整个2013年在微博上推荐的技术资料整理了一下,说真的,写的不少,看的更多。

 

下面的这些资料,都是精品资料,个人已经看了其中的95%左右,余下未看的,需要找时间看完,已经看过的,也准备找时间多温习几遍,好东西,不怕多看。对于个人来说,这算是一个总结与收藏;对于阅读此博文的朋友来说,也可以各取所需,一起追求技术的进步。

 

注:资料的组织,先按照领域划分,包括:(Concurrent) Programming、Data Structure & Algorithm、Database (综合、MySQL、Oracle)、Performance、Distributed、OS & Hardware、(New) System、其他 等8个大类。然后针对每一个大类,再按照书籍、博客文章、PPT & PDF的形式归类组织。

 

阅读全文…

标签:

并发编程系列之一:锁的意义

12月 23rd, 2013

 

背景

 

C/C++语言的并发程序(Concurrent Programming)设计,一直是一个比较困难的话题。很多朋友都会尝试使用多线程编程,但是却很难保证自己所写的多线程程序的正确性。多线程程序,如果涉及到对共享资源的并发读写,就会产生资源争用(Data Race)。解决资源争用,最直接的想法是引入锁,对并发读写的数据进行保护(更高级的则包括无锁编程—— Lock Free Programming)。但是,锁又有很多种类,例如:自旋锁(Spinlock)、互斥锁(Mutex)、读写锁(Read-Write-Lock)等等。这么多的锁,每种锁有什么特点?对应哪些不同的使用场景?使用过程中需要注意哪些事项?各自分别有哪些不足之处?都是困扰程序员的一个个问题。

 

甚至,一个最基本的问题:为什么锁就能够用来保护共享资源?锁真正蕴含的意义有哪些?我相信很多使用过各种锁的程序员,都不一定能够完全正确的回答出来。

 

有鉴于此,本人希望将自己近10年数据库内核研发,所积累下的并发编程的经验记录下来,形成一个系列的文章,分享给大家。这个系列,个人打算对其命名为 #并发编程系列# ,作为此系列开篇的文章,本文将从一个简单的并发编程的例子出发,引出锁真正蕴含的意义

 

阅读全文…

MySQL 加锁处理分析

12月 13th, 2013

 

1    背景    1

1.1    MVCC:Snapshot Read vs Current Read    2

1.2    Cluster Index:聚簇索引    3

1.3    2PL:Two-Phase Locking    3

1.4    Isolation Level    4

2    一条简单SQL的加锁实现分析    5

2.1    组合一:id主键+RC    6

2.2    组合二:id唯一索引+RC    6

2.3    组合三:id非唯一索引+RC    7

2.4    组合四:id无索引+RC    8

2.5    组合五:id主键+RR    9

2.6    组合六:id唯一索引+RR    9

2.7    组合七:id非唯一索引+RR    9

2.8    组合八:id无索引+RR    11

2.9    组合九:Serializable    12

3    一条复杂的SQL    12

4    死锁原理与分析    14

5    总结    16

 

  1. 背景

 

MySQL/InnoDB的加锁分析,一直是一个比较困难的话题。我在工作过程中,经常会有同事咨询这方面的问题。同时,微博上也经常会收到MySQL锁相关的私信,让我帮助解决一些死锁的问题。本文,准备就MySQL/InnoDB的加锁问题,展开较为深入的分析与讨论,主要是介绍一种思路,运用此思路,拿到任何一条SQL语句,都能完整的分析出这条语句会加什么锁?会有什么样的使用风险?甚至是分析线上的一个死锁场景,了解死锁产生的原因。

 

注:MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍,都是基于InnoDB存储引擎,其他引擎的表现,会有较大的区别。

阅读全文…

C/C++ Volatile关键词深度剖析

12月 2nd, 2013

1    背景    1

2    Volatile:易变的    1

2.1    小结    2

3    Volatile:不可优化的    3

3.1    小结    4

4    Volatile:顺序性    4

4.1    happens-before    6

4.2    小结    7

5    Volatile:Java增强    8

6    Volatile的起源    9

7    参考资料    9

 

  1. 背景

前几天,发了一条如下的微博 (关于C/C++ Volatile关键词的使用建议):


 

此微博,引发了朋友们的大量讨论:赞同者有之;批评者有之;当然,更多的朋友,是希望我能更详细的解读C/C++ Volatile关键词,来佐证我的微博观点。而这,正是我写这篇博文的初衷:本文,将详细分析C/C++ Volatile关键词的功能 (有多种功能)、Volatile关键词在多线程编程中存在的问题、Volatile关键词与编译器/CPU的关系、C/C++ Volatile与Java Volatile的区别,以及Volatile关键词的起源,希望对大家更好的理解、使用C/C++ Volatile,有所帮助。

 

Volatile,词典上的解释为:易失的;易变的;易挥发的。那么用这个关键词修饰的C/C++变量,应该也能够体现出”易变”的特征。大部分人认识Volatile,也是从这个特征出发,而这也是本文揭秘的C/C++ Volatile的第一个特征。

 

阅读全文…

标签: , ,

排队论及其应用浅析

11月 6th, 2013

导读

 

说起【排队论】(Queueing Theory),我的朋友 童家旺 (新浪微博:@jametong)应该是我的启蒙者,在去年的一些交流中,他就多次提到过【排队论】,但是,那时我也是听听就过,也没有深入去了解过究竟什么是【排队论】。

 

今年,在参加数据库大会时,他向我推荐了一篇文章,Cary Millsap写的《Thinking Clearly About Performance》,读过之后,惊为神文。作者原为Oracle Performance组的VP,负责Oracle数据库的性能优化工作。在文中,作者清晰的描述的什么是Performance,以及【排队论】在Performance中的作用,恰好当时我们组正在做自主研发的TNT存储引擎的性能优化工作,因此我就对【排队论】上了心。之后,陆陆续续看了几十篇排队论相关的文章/书籍,对于排队论终于有了基本的认识,个人感觉其非常有用,因此就产生了这篇PPT:《排队论及其应用浅析》。

 

《排队论及其应用浅析》,从【排队论】开始,介绍了【排队论】的起源,解决的问题,经典的排队论系统,排队论中经典的Law(如:Little’s Law)。然后,再进一步展开,介绍了【排队论】在系统设计、性能优化、容量规划等方面的应用。

 

阅读全文…