【IT168 评论】作为国内数据库与大数据领域最大规模的技术盛宴，2015第六届中国数据库技术大会(DTCC)即将于2015年4月16日-18日在北京新云南皇冠假日酒店闪亮登场。大会以“大数据技术交流和价值发现”为主题，云集了国内外顶尖专家，共同探讨MySQL、NoSQL、Oracle、缓存技术、闪存技术、国产数据库、Hadoop、数据挖掘、推荐系统、机器学习等领域的前瞻性热点技术。

　　大会届时将吸引2500多名IT人士参会，举办120多场精彩演讲，致力于为数据库人群、大数据从业人员、广大互联网人士提供最具价值的交流平台。

　　在本次大会召开之前，IT168专访了本次大会“云数据库专场”的演讲嘉宾阿里分布式数据库DRDS负责人沈询(王晶昱)，他表示将会在大会上分享主题为《云上的分布式数据库DRDS》，点击报名！

沈询(王晶昱)

　　王晶昱(沈询)2008年加入阿里巴巴，是阿里分布式数据库TDDL/DRDS负责人，也是阿里分布式消息服务ONS(Notify,MetaQ)负责人。之前一直从事阿里分布式数据层方面的研发与业务架构梳理工作，TDDL作者，具备丰富实战经验。

　　演讲主题：云上的分布式数据库DRDS

　　内容简介：DRDS是新一代的阿里分布式数据库云服务，前身是淘宝分布式数据库(TDDL)，它承载了淘宝六年的高速增长，经历过多次双十一的严酷考验，在阿里内有几千个应用正在使用，是阿里最为成熟的分布式数据库服务体系。现在，TDDL已经换了个新名字DRDS来到了云上，在云端的DRDS，面对新的用户，新的需求，我们碰到了哪些问题?又是如何利用我们的产品来解决这些问题的?欢迎来听听我的讲述。

　　以下为采访原文：

　　IT168(Q1)：您从08年进入阿里已经有6年了，这六年里，您也见证了阿里的成长，回顾下过往的经历，6年前的自己和6年后的自己有什么不同?6年后的阿里是否更加Open?能否介绍下自己，谈谈自己的感悟。

　　沈询(A1)：要说感悟的话，两个字概括一下： “感恩”。 08年的我，只是刚刚本科毕业的菜鸟，能进入阿里的淘宝，真的只能说是幸运。更有幸的是，刚进入到淘宝，正好赶上了他的高速发展期。最有幸的是我来到了阿里技术氛围非常浓厚的淘宝平台架构组(现在的阿里中间件和稳定性平台)。

　　六年的时间，我基本上在坚持做好一件事：努力地把淘宝的分布式数据库DRDS(TDDL)做到最好，最完善。六年的时间 DRDS(TDDL)从无到有，从最初的一个应用在小牛试刀，到现在几乎全部阿里的应用都在使用，这是一件非常不容易的事儿。

　　现在回头看看，这中间我们也走过不少弯路，付出过不少代价。但分布式数据库这条道路，我想应该是没有走错的。而在这蜿蜒曲折的探索之路上，我也从一个只会用SQL写点简单逻辑的数据库菜鸟，逐渐成长为一名分布式数据库领域的老鸟。时至今日，我也分享出了不少有质量的文章和分享了呢~

　　分布式数据库相关的理论，大部分在上世纪60~70年代就已经被研究得非常透彻了。然而，计算机科学是一门实践科学，我们永远在面对着各种各样的选择和权衡，如何取舍，如何权衡，哪些功能应该改进，哪些应该废弃。这些只能依靠场景与实践来考验了。

　　感恩这个时代，让我们有机会能够依托于淘宝这个复杂的，高增长的实际场景来实践我们的理论，并且真的用我们DRDS(TDDL)产品解决了这些问题。

　　也感恩我们的客户，愿意选择DRDS(TDDL)来完成他们的系统与业务，对于程序员来说，这世界上最爽的事，不就是用户主动选择你写的程序来实现业务价值么?：)

　　IT168(Q2)：我了解到，您最早是阿里分布式数据库TDDL/DRDS负责人，时至今日，DRDS已经在阿里云上正式对外公测了。而谈到DRDS，大家会想到它与阿里云RDS的千丝万缕的关系，很少有人会想到它是Cobar和TDDL的化身，能否聊聊阿里的分布式RDS的前世今生?

　　沈询(A2)：阿里的中间件在之前的六年里，主要服务于阿里集团内部，而随着云时代的到来，中间件迁移到云端，TDDL服务的对象也就必然发生了变化，原来我们的服务对象主要是公司内部的用户，而现在，我们的服务对象扩展到了云上的广大客户。云计算，在给我们提供新机遇的同时，也给我们带来了新的挑战。

　　这其中最为明显的变化，我想应该就是用户对于我们运维体系上的新要求，在此之前，我们主要是一个内部团队，更多地关注在产品的低成本、高性能、稳定可靠等因素，在淘宝高速增长的这些年，我们做得很不错。在历年的双11中，我们的系统几乎从未出现过任何故障，成功的满足了用户对性能和稳定性上面的需要。

　　然而，在云时代，用户不再满足于现有的特性，开始追求简单易用、用户体验良好的产品，这就对我们提出了新的要求，我们需要把我们之前在支持内部用户时所学到的整套运维体系，全部否定掉，然后根据大家的真实需求来重新定义我们的运维模型，说成是一次全新的革命也不为过。

　　这就是我们全新的阿里分布式数据库DRDS的前世了，它继承了cobar最稳定的网络协议和SQL解析层，也继承了整个TDDL的优化器与成熟的运维模型，又通过内测和公测的方式，基于真实客户的需求上重塑了整套运维流程。

　　现在，在内部和外部，它已经拥有了几百个正式上线的用户，正以非常好的的状态，服务于我们的客户。

　　IT168(Q3)：相比于单机数据库，分布式数据库有哪些优势呢?分布式数据库有哪些应用场景?

　　沈询(A3)：分布式数据库，顾名思义，就是利用网络将多台计算机连接在一起，提供数据库服务的计算机体系。

　　这样做，能给我们的业务带来最大的好处，就是理论上无限的扩展能力，当然，处理能力可以通过水平加机器的方式无限增加，但我们兜儿里的钱毕竟还是有限的，所以是理论无限哦~

　　其次，分布式数据库还能够给我们带来更高的数据安全级别，如果需要，我们可以将数据存储在多个异地的数据中心中，这样可以极大的提升数据的安全级别。

　　最后，分布式数据库还能给我们带来更高的可用性，因为一台机器只存储了数据的一小部分，所以，单台机器故障，对整个系统的影响就会变小。

　　从分布式数据库的优势来分析，可以看到，它最主要的优势在于，近乎无限的数据扩展能力，让我们的系统不再有“成长的烦恼”，同时，又能够很好地提升数据库的数据安全和可用性。

　　再让我们来分析一下，云中应用中最为需要的一些场景，面向互联网的云应用的最主要特征，就是数据量非常大，数据库的读写可能随着用户数的快速增长而突然增长，而每个用户又都是非常重要的，都需要享受到最可靠的服务，无法忍受不可用等非正常情况。

　　这些恰好就是分布式数据库用武之地，换而言之，它是为了互联网应用，为了云计算而定制出来的系统。

　　IT168(Q4)：阿里分布式数据库RDS到底是一个什么样子的神器?它与各类型的NoSQL相比功能有哪些不同呢?能否结合双十一的具体场景和我们谈谈DRDS能给业务开发带来什么好处?

　　沈询(A4)：一谈到双十一，我脑子里会立刻蹦出一个不错的例子。离双11还差5天的时候，突然有个外部的DRDS用户告诉我们，他们很担心双11数据库撑不住，想在双11前扩容一下。通过几步简单的配置操作，他们的系统成功实现了快速扩容，应用非常平稳的度过了双11。

　　我想，这就是DRDS能够带来的最大价值之一，让我们的客户无需担心成长性问题，可以按需实现伸缩扩展。

　　与传统的数据库相比，分布式数据库在扩展性和性能上具备压倒性的优势。为此，很多人可能会想到，NoSQL不是也能在扩展性和性能的提升方面发挥得灵活自如吗?相比之下，DRDS又有什么不同呢?

　　这就需要结合我们的理念来做一个阐述了，DRDS的目标是，在保证扩展性和性能的前提下，尽可能的保留原有数据库的一切方便性功能。这就与NoSQL激进的强调扩展性，不强调易用性有了本质的区别。

　　比如，我们会帮用户保持单机事务，单机Join，分布式Join，跨机统计分析查询等多种方便而易用的功能，让用户在从单机数据库迁移到分布式数据库的时候，尽可能地减少代价，从而降低系统的构建成本。

　　IT168(Q5)：淘宝上有成千上万的卖家，有些卖家在双11大促的时候商品库的数据被海量查询，而促销过后热数据变成冷数据了，这是否意味着淘宝商家商品库的数据会有冷热隔离?商品数据库表是如何保证用户快速查询到热点商品信息的?

　　沈询(A5)：针对热点查询，秒杀类等问题，在阿里内部已经有非常成熟的一整套解决方案了。像这次双十一的秒杀活动，我们的系统成功收官，再次赢得了客户对我们的信任。

　　由于我们的数据库本身在好几年前就已经使用DRDS(TDDL)分布式数据库了，所以，整套系统本身是没有扩展性瓶颈的，需要多少请求量，只需要加够机器即可达到，剩下最主要的问题是，如何能够准确的评估出为了承载对应的流量，我们所需要的机器数。这样，只要机器足够，系统本身就可以承载，不用担心挂掉了。

　　不过，我们也经常碰到计划赶不上变化的时候，评估不准确也是有可能的，因为客户的热情经常超出期望...这时候就要考虑自我保护啦，从应用层、到数据层，都会有工具能够保证系统以最大能力服务，超出则安全拒绝。

　　利用这两种方式，我们的系统就可以比较成功的满足我们业务大促的各类需求了。

　　是的，数据都会变冷，我们也拥有很多套的冷数据处理方式，比如针对商品，可能直接就移动到我们的ODPS大数据存储平台去了，而针对交易类场景，我们也会考虑使用成本更低的文件存储引擎来存储这些冷数据。

　　IT168(Q6)：阿里的核心在中间件上，很多中间件的核心都可以迅速变成云服务，演变成“多点开花”的盛世。能不能给我们讲讲阿里最核心的中间件产品有哪些?

　　沈询(A6)：基本上，阿里所有的中间件都在下面的这张图中了。

　　HSF

　　High Speed Framework(HSF)能够让您更方便的进行远程调用，在使用Java作为主要语言时，HSF可以让您可以像使用普通java 接口一样进行远程方法调用，让代码看起来更清晰，简洁。

　　服务化的主要目标是为了代码逻辑的复用和专业分工，在公司员工超过一定规模以后，如果还依托于一个大的web工程来进行我们的项目，那么就会碰到各类的开发效率问题，比如代码提交冲突，项目过于庞大以至于学习成本提高等问题，这时候进行专业分工就非常的有必要，这就是服务化的主要作用。

　　目前，HSF在云上的名字，叫EDAS。

　　Name Server

　　在内部的名字是Config server，用来进行服务发现，主要做的事情就是在某个机器承担了某种角色以后，能够快速的广播给需要这个角色提供服务的人说：“我目前可以做这个活儿啦，你们有需要我做事儿的人，可以来找我。”，在目前，您只要使用了EDAS(HSF)，就会使用到他，但您不需要自己去使用他。

　　ONS(RocketQ)

　　Open Notification Service(ONS)一套分布式消息组件，经历过3次双11线上实际的交易场景的考验，无单点，无瓶颈，可自由扩展。

　　主要的作用是异步并行和解耦，同时也是利用分布式最终一致性提升系统性能的关键组件之一

　　使用消息系统，能够让您将业务的主流程与分支流程分开，让分支流程可以并行执行，从而极大的降低延迟，提升系统的整体性能。同时，因为将主流程与分支流程进行了分离，因此分支流程出现故障，不会影响到主流程的正常运行，从而可以让系统更为稳定可靠。

　　DRDS(TDDL)

　　Distributed Relation-Database Service(DRDS)是一款协助您进行数据库水平切分的工具，能够允许您将原来只能在单机运行的SQL查询，尽可能的分布到多个数据库上进行查询。与市面上的各类数据库相比，我们更加强调可扩展性和易用性。在我们认为，作为一个可持续发展的云计算系统，系统应当具备可自由伸缩的能力。否则，您的系统可能在某个关键的业务爆发期开始时，就无法为全部的用户提供可靠的服务，会直接对系统的可用性造成致命的影响。

　　与传统的NoSQL、RDBMS相比，一个最突出的不同，就是能够让您在获得分布式可扩展能力的前提下，最大程度地保留原有SQL的使用习惯。

　　IT168(Q7)：说起消息中间件，有一个词叫“心塞”，指的是消息堆积的问题，而对于淘宝的用户，从注册到下单购买商品的整个过程，可能会遇到各种消息提示，能否和我们讲解下阿里消息中间件的应用场景?

　　沈询(A7)：消息中间件要做的事情其实都是类似的： 解耦消息发送者与消息接收者，提高系统的并行度，从而降低系统延迟，提升用户体验。

　　我举个简单的交易流程的例子，来帮助大家理解阿里的分布式消息中间件在整个业务中起到的作用吧。

　　我们假设一笔电话充值交易需要按照上面的流程进行，先创建交易，然后写交易日志，然后通知直冲系统给客户充值，然后再顺序的做几百个系统调用后完成。

　　如果每个流程需要10个毫秒，那么整个系统就需要2秒才能完成一次系统调用。这明显是太慢了，那么，有没有方法能够减少单次调用的延迟呢?

　　通过分析，我们发现，创建交易后，日志，直冲和其他200个系统都可以并行的进行，不需要全部使用顺序流程。

　　这样做了以后，开始看起来，系统运行的效率有了非常明显的提升，但只要这200个系统内有一个系统慢，比如上图中的直冲系统，一下变成10秒了，那么我们的交易系统也就变成了10秒才能返回，这明显是不符合预期的。

　　要解决上面的问题，我们就要引入一个新的系统，消息服务器。

　　利用这个模式，交易系统只需要跟消息中间件来打交道，只要消息中间件是高效可靠稳定的，那么整个交易就是可靠稳定高效的。

　　这个消息中间件，直接隔离了后端的系统和交易系统。这样带来的好处是，后端任何一个系统挂掉，或者运行缓慢，都不会影响交易的正常创建过程。并且，消息中间件也协助业务做到了下游业务的并行处理。

　　这，就是消息中间件能够带给业务的好处。

　　IT168(Q8)：今年的双十一中，淘宝的消息中间件表现如何?那么淘宝的消息中间件MetaQ与Notify又是如何来保驾护航的?

　　沈询(A8)：相比于往年，今年的双11，我们的消息量有了五倍的提升，达到了每天1000多亿条，变化非常巨大。但今年却是我们感到最为淡定的一次，经过了这么多年的积累，我对我们系统的能力已经非常有把握了，而且自动化程度很高，所以今年我们基本上什么预案都没做，很平稳的就度过了双十一。

　　IT168(Q9)：我了解到，阿里的消息系统特别看重消息的堆积能力，而就我所了解到的一些开源的实现，似乎不是很强调这个，不知道阿里的消息系统为什么会这样设计?

　　沈询(A9)：消息堆积问题是个很重要的难题，也是我们与外部系统在设计上一个比较大的不同，我们的消息系统里面一个最核心的假定是消息一定会堆积。

　　原因很简单，因为我们的下游系统有几百个，这里面有比较重要的，但也有一些不重要的系统，在面对突发的流量高峰时，一定会有系统处理不过来，造成消息堆积。

　　假如每秒8w笔交易，就意味着我们可能需要有5~6倍的交易消息量发送。

　　堆积一小时后的消息量是非常夸张的。

　　而如果消息堆积就会导致消息系统发消息响应慢，或者造成消息丢失。那么对于整个系统来说就是不可接受的。

　　因此，我们认为，消息大量堆积情况是个非常常见的业务场景，这是消息系统的责任。

　　了解DTCC2015更多演讲主题与嘉宾请访问会议官网： DTCC 2015官网，大会门票正在火热发售中，本周报名可享受6.8折优惠！预购从速！！！