bet356体育在线

查看内容

下定决心将整个2013年在微博上推荐的技术资料整

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

  我们做了一个新的数据库存储引擎X-Engine。目前在sysbench标准化测试下做到了65万的TPS,相同硬件下是InnoDB存储引擎最优性能(11万左右)的6倍左右。当然,离我们的目标:10倍性能,1/10成本还有一定的差距。

  我们做了一个高性能可全球化部署的MySQL数据库集群(基于自研的X-Paxos分布式一致性算法和我们的AliSQL),异地部署下是MySQL官方Group Replication性能的5倍以上,并且在阿里集团内核心业务线真正落地。

  我们基于X-Paxos、X-Engine等核心技术,做了一个真正一体化的分布式关系型数据库X-DB。集水平扩展能力、持续可用能力、高性能、低成本于一体。

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

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

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

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

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

  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上做一个分享,感兴趣的同学届时可以关注。

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

  既然是招聘贴,就要有招聘贴的样子,与其说是我们需要什么样的人,不如说是分享下我所欣赏的技术人的特点:

  1.发自内心的喜欢做技术,有强烈的自我驱动力,永不服输。工作也好,生活也罢,不会一帆风顺,困难是常态。

  2.扎实的技术基本功。我们团队,无论是刚入职的新人,还是工作10年以上的老人,都坚持在一线Coding,未来是想出来的,更是做出来的。基本功包括:C/C++编码基础、Linux系统基础、数据结构和算法基础、并发编程基础等。

  3.扎实的数据库基础理论和数据库内核研发经验是加分项,但不是必须的。必须的是,你必须有至少一项技术特长,在自己的技术领域内证明过自己。我一直坚信的理念是:技术是互通的,优秀的技术人,只要内心愿意去尝试,在绝大部分技术领域都能够获得成功。

  4.强烈的好奇心,不按部就班,持续学习。技术领域一个非常鲜明的特点,就是你所知道的掌握的技术,可能都是过时的。因此技术人员需要保持不断学习,阅读英文论文的能力是必须的。

  3. 有着深厚研发基础,但对数据库内核不是特别熟悉的研发人才。你有意愿(尝试新领域),我有信心(让你在这个新领域内落地,并做出突破)

  2005年第一次进入数据库内核研发领域,没想到不仅在这个领域一干就是12年,而且每年都会从中体会到新的惊喜。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  前几天,发了一条如下的微博 (关于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的第一个特征。

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

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

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

分享: