淘宝数据库负责人介绍淘宝数据库设计

眼下主要负责数据库的稳定性这一块。双十一这一天。我主要是负责协调整个数据库团队和保障整个数据库在“双十一”过程中的稳定性不受不论什么影响。

那给我们具体的谈一下淘宝网如今整个数据库总体的一个架构。包含它硬件的组成。?
淘宝的数据库发展到今天。已经是一个非常复杂的系统。

我大概算了一下。淘宝眼下全部的数据库服务器加起来可能已经超过800台。

那在这么一个规模底下，淘宝的数据库团队这么多年也是随着淘宝的业务发展一起成长起来的。但淘宝数据库眼下核心的数据库还在小型机和高端的存储上面，还有非常多的数据库如今是用的是MySQL，我们逐步在从Oracle到MySQL这个方向在转移，所以我们MySQL PC server硬件也是非常多的了。?

我们也了解到。如今淘宝的整个的数据库团队在逐渐的把一些数据库从Oracle迁移到MySQL，然后呢。把一些服务器由小型机转到PC server。那你们整个转变的动机是什么？
主要是由于业务压力给了我们最大的动力。07年我来到淘宝的时候，当时仅仅有三个基本的数据库，全部在小型机和存储上面。以当时的压力来看，它跑起来是非常顺利的，并且大家也知道小型机它从Unix操作系统到硬件，稳定性都会比PC server事实上要高非常多，当时的情况下淘宝用小型机是一个非常自然的选择。

从07年開始淘宝的业务量保持每年自然翻一番的增长，数据库质量感觉到非常大的压力。那么前端业务量增长一倍。在数据库上有可能增长是好几倍，它有一个放大效应在里边。当时我们第一步可以想到非常自然的架构，就是把三个数据库拆成很多其它的数据库，或每个数据库支持一个比較单一的业务。比方用户、商品和交易，都会分成独立的数据库，然后放到独立的小型计算中去，这是我们08年做的非常大的事情就是垂直拆分，然后08年的业务我们就顶住了。
当时我们就预估09年、10年会有更大的压力增长，这个时候我们应该怎么办？当时我们从业界能看到非常多的经验分享，包含eBay、亚马逊这些国外的大公司。他们的经验分享里面，水平拆分是我们数据库涨到一定程度后的架构选择。我们从Oracle到MySQL转移，主要是用水平拆分，这是我们未来的一个弱点。那水平拆分后机器、数据库的数量都会多非常多，那Oracle它本身的成本也是我们考虑的一个重要因素，所以当时从成本考虑的话，那个时候我们自然会选择用MySQL数据库。

给我们再简单总结一下这几年，淘宝整个数据库的演变过程？?
刚才说到08年我们做完垂直拆分以后，09年到今年我们主要做的工作事实上就是水平拆分。今年在十月份之前我们全部完毕了淘宝最核心的三个系统：交易数据库、商品数据库和用户数据库的水平拆分。所以到“双十一”之前，在我们内部採訪中，我一直跟採訪人员说，当时数据库情绪稳定。基本上我们没有做什么事情，仅仅是在不停的看报表，看数据。然后非常开心的看到交易曲线以超过45度的趋势往上涨。

那前期还是做了非常完好的准备。

据我们了解在整个从小型机到PC server的迁移，包含从Oracle到MySQL数据库的迁移，你们在做这个事情的时候。都做过好几个月的压力測试。你讲讲这个背景和故事。
是这样的，今年我们年初决定。我们商品库从小型机迁到PC server上面去，这是淘宝压力最大的一个数据库，当时是用四台小型机加两个高端存储来支撑的。要把这么大一个数据库进行迁移。我们心里面也是没有底的，由于不知道要多少台PC server可以支撑。须要什么样的配置来支撑这个压力？当时我们可以想到一个非常直观的想法就是模拟线上全然一样的压力。甚至加上几倍的压力来測它的极限值。
我们和开发团队、我们的性能測试团队，加上DBA团队和ops团队，成立了一个非常大的项目组，然后做了接近两个月的性能測试，在整个測试过程中发现了非常多的问题，包含我们给Oracle、MySQL等厂商都提交了非常多Bug，有些Bug也得到厂商回应。进行修复。

那总体的转变的过程到如今进行到了什么样的程度？包含你在整个转变的过程中遇到哪些问题？?
我们如今最核心的用户数据库今年已经彻底完毕了从小型机、存储和Oracle切入到PC server加MySQL的架构。
我们内部有一个提法叫做去O、去I、去E。事实上就是我们要从高端硬件Scale up模式到低端硬件的Scal out水平扩展的模式，这是淘宝内部最大最核心的系统。今年已经顺利完毕了全部区的水平扩展。其它几个系统，比方说交易和商品已经完毕了一部分，完毕了水平拆分的一部分，可是没有达到我们希望的进度。这可能是明年我们须要做的事情。

在转型过程中主要遇到哪些问题？?
让我们认为比較大的问题就是我们从可靠的小型机迁移到大规模，大数据量的PC server上来，从架构上就对我们就是一个非常大的挑战。大家都知道。每个PC server的稳定性肯定和单台小型机会有一定的差距。再加上我们一个机群有可能是32台或者64台PC server。

每一台PC server即使有四个9的可用性。但假设我们整个系统合在一起。可能它最后的两个9的可用性都达不到。

这就须要我们从软件层、架构层要做非常多的改进。可以要让单点的一些失效对总体的系统不造成不论什么影响，由于我们和架构部门、开发部门一起做了非常多事情，才干保证我们的集群稳定上线。

事实上“双十一”这个时间应该说是对过去的技术转变的检验，如今回头来看，这个检验的结果怎么样？?
当时是有点提心吊胆的，之后又认为相对来说今年我们做的非常多事情还是非常成功的。可是如今再回头细致想想还是有点后怕，“双十一”那天的凌晨零点不是有一次Ipad的秒杀吗。当天晚上我们都在线上观察数据，在零点的一瞬间，就看到全部数据库指标已经达到了曾经正常时候最高峰的指标，有些甚至还超过了。

当天晚上睡觉的时候心里就有点在打鼓：才零点就这个样子了，明天下午明天晚上最高峰的时候我们应该怎么渡过？所以第二天早上八点多的时候我们一进到指挥部里面就看到全部的指标， 包含CDN的指标、各个业务线的指标、数据库的指标都是噌噌的往上涨，这时心里面事实上是非常忐忑不安的。

可是我们比較放心的是这三大核心系统，商品、用户和交易，在我们今年全部的水平扩展项目做完了以后，比方说商品功能做完了以后。从我们的机械压測里面它是有十倍的流量的，所以当天百分之中的一个百，百分之两百的流量基本上对数据库没有造成太大的影响，所以当时还是非常开心的看到这个指标高速的往上涨，希望交易可以通过10个亿、20个亿，我认为都是可以承受的。

那对于整个数据库架构的演进下一步有什么打算？?
下一步事实上就是刚刚说的我们有几个核心系统还没有全然的做到这个水平扩展，加上“双十一”那天我们还是有一个小惊险：我们有一个数据库，跟交易核心有一点点联系的，但它还是放在小型机上面。当时已经提前为它准备了百分之中的一个百的余量，就是说它可以承担平时最高压力的两倍。
可是那天已经达到平时最高压力的1.8倍左右的时候，把我们吓出了一身冷汗。假设当时淘宝的交易最高峰的流量再增长20%的话，有可能数据库就会到瓶颈了。

所以我们明年是要把很多其它这样的Scale up可以看到天花板的数据库全部要拆分成水平库存这样的数据库。

那你刚才所提到的去Oracle，去小型机。去高端存储，这个“三去”的总体思路给淘宝网带来了哪些经济上的效应？?
当时我们知道小型机和存储的价格是非常昂贵的，还是拿我们刚才说压力最大的商品数据库举个样例，当初我们数据库是用了四台高端的小型机。两套高端的存储，成本加起来起码都是三千万以上。

那眼下我们用的是32台PC server来搭建的一个机群，价格也就是300万~500万的级别。相对来说我们做完这个事情以后。攻克了两三千万的硬件成本。

这样来讲。总体的经济效益还是非常不错的。可是事实上刚才我们在前期沟通的时候也提到，你要从Oracle转到MySQL，包含从小型机转到PC server。事实上里面还是会遇到蛮多问题的，包含它的不稳定性等等。那对于这一方面你有没有什么经验可谈？
在这一方面，我认为有两个非常重要的因素。第一个是我们须要和我们的开发前端应用架构部门可以紧密的合作，可以让我们的应用融入刚才说的整个机群的单点失效和容灾的问题。

都须要我们和架构部门一起来考虑的；第二个比較大的经验就是眼下我们在做的。深入研究MySQL的源码。我们从研究和压力測试的过程中。发现MySQL它本身代码的一些缺陷。可能在高并发大压力下会有非常多隐藏的Bug。
在我们近期的这次測试其中。我们还发现了Facebook公布的FlashCache二级缓存的软件。当时我们是測出它一个非常大的Bug：并发压力非常大的情况下，它会导致MySQL成为一个僵尸进程。

我们发现了以后。非常快反馈给Face book，然后Face book非常快就修复了这个问题，这也是我们对使用开源软件带来更大的一个信心，就是开源可以在全球得到很多其它的支持，大家都可以从原代码层面来解决更深层次的一个问题。

我想这也可能是淘宝技术团队如今那么开放，那么注重开源的动力之中的一个。那假设说想对MySQL的一些核心代码做编译，就须要对人才的储备，包含各方面资源整合的要求还是蛮大的，那你在这方面有没有什么感触？
说到人才这个话题。08年的时候，淘宝当时准备大规模的往MySQL方向上转。我们内部也是有一些置疑的声音。他们说淘宝DDA团队曾经都是在Oracle方面比較专精，在业界来说，淘宝的DDA团队在Oracle方面更加有名气一些。所以我们内部有置疑的声音。就是说你们有MySQL专家吗，MySQL出问题了以后能非常快的解决吗？所以从08年到如今，我们慢慢的一路走过来，内部培养了非常多的MySQL的人才，包含这几年我们的应届生的成长。再加上我们从外部招到一些专家，我们对MySQL的理解已经越来越深。
刚才说到，我们已经可以给MySQL打Patch。已经可以给MySQL report这些Bug。到如今为止。我认为MySQL的成长已经达到了非常高的一个程度。我们对MySQL已经越来越有信心，可是未来淘宝的MySQL肯定是要做得越来越大的，淘宝还有非常多小型机上面扩展不太easy的系统须要迁移到可扩展的机群上面来，但我们也希望业界可以有很多其它的MySQL伙伴增加我们。和我们一起来做这么一件非常有意义的事情。

我想可以增加到淘宝的技术团队，去经历那么多有大交易量的技术实践还是非常宝贵的。另外一个问题就是尽管说如今我们用的越来越多的是MySQL。可是如今大家也知道MySQL已经被Oracle收购了，那对像淘宝这样的团队有什么影响呢？
大家都知道MySQL事实上是基于GPL的协议来开源的软件，那淘宝在使用过程中，前期是已经考虑到一些风险。所以我们全部的MySQL都是自己来做编译做优化的，并且我想MySQL被Oracle收购了以后。如今看起来Oracle应该是给MySQL在开发这方面是提供了更大的帮助，像之前在Sun的时候，MySQL的版本号相对来说是比較混乱的，包含我们如今在用的5.0和5.1的正式版本号，近期还有包含开发方面就还有两个。一个6.0，一个5.4。这些特性会互相交织在一起，让我们选择的时候也有点不知道究竟选哪个版本号会更好一点。

但如今Oracle收购MySQL以后，他把5.4跟6.0这些版本号已经合成了一个比較规范的5.5的版本号，并且为它制订了非常好的一个milestone15：31，未来要怎么发展这个里程碑，M1、M2、M3、M4这样的发展方向。而到如今为止这个5.5已经发展到5.6、5.7的版本号，并且已经是IC版本号了，非常快就要GA了，那我想这对于MySQL来说应该是一个好消息。我们可以用到很多其它更稳定的新特性。 5.5版本号里有几个新的特性是我们非常关注的，比方Google已经达到英文15：57这个pach。所以我们认为对我们未来的这个MySQL这个系统非常实用的一个功能。那我们也等着Oracle的5.5这个版本号可以尽快的GA出来。