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

TOP

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

2015-07-24 10:27:28 来源: 作者: 【大中小】浏览:5次

Tags：数据库负责人介绍设计

江枫先给我们介绍一下自己，和你在这次淘宝“双十一”事件中所扮演的角色？

大家好，我是淘宝技术保障部的江枫。目前主要负责数据库的稳定性这一块。双十一这一天，我主要是负责协调整个数据库团队和保障整个数据库在“双十一”过程中的稳定性不受任何影响。

那给我们详细的谈一下淘宝网现在整个数据库整体的一个架构，包括它硬件的组成。

淘宝的数据库发展到今天，已经是一个非常复杂的系统。我大概算了一下，淘宝目前所有的数据库服务器加起来可能已经超过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能够看到天花板的数据库全部要拆分成水平库存这种数据库。

那你刚才所提到的去Or

首页上一页 1 2 下一页尾页 1/2/2
【大中小】【打印】【繁体】【投稿】【收藏】【推荐】【举报】【评论】【关闭】【返回顶部】
分享到:
上一篇：【MongoDB】InstallationofMongoDB	下一篇：dblink访问ORA-00997:非法使用LON..

帐　　号:

密码: (新用户注册)

验证码:

表　　情:

内　　容: