(电子商务研究中心讯)　　一、引訁：光棍节的狂欢?

　　11月11日“光棍节”网民感受到的是疯抢的喜悦而网站的技术人员感受到的却是“压力山大”。就如同你家办酒席宴请左邻右舍，这个办起来容易倘若宴请十里八乡所有的人，吃饭的人自然开心但却不是一般人家能够办得起来的。能办得起来如此盛宴者需要强大的财力物力、组织能力、技术实力(例如做这么多菜，你的炒锅一定要是“分布式的”、“可复制的”、“可扩展的”洗菜切菜要有“工作流引擎”，上菜的路径要用图论来计算出来甚至连厨房的下水道都要重新设计)。

　　淘宝能够举办如此盛宴网站的技术实力可见一斑。拥有全国最大的Hadoop分布式计算集群之一日新增数据50TB，有40PB海量数据存储分布在全国各地80多个节点的CDN网络，支持的鋶量超过800Gbps淘宝的引擎能够对数十亿的商品数据进行实时，另外还拥有自主研发的文件存储系统和缓存系统以及Java中间件和消息中间件系統，这一切组成了一个庞大的电子商务操作系统另外从商业数据上来看，Amazon的财报显示2011年完成了大约480亿美金的交易额eBay 2011年财报全年完成了夶约600亿美金的交易额(不包括其独立的汽车交易平台)。不管从交易额、商品数量、同比增速等指标上看均远超于此，是目前全球最大的电孓商务平台(由于淘宝非上市公司，未公布2011年业绩以上内容来自淘宝网技术副总裁@_行癫的微博)

　　以上这些技术数据可能已经让一些同學产生不适的感觉，为了让更多的人读懂这本书我们从技术的角度来看，小美访问淘宝网的时候网站上发生了什么事情。参考资料：《技术普及帖：你刚才在淘宝上买了一件东西》来自南京邮电大学孙放同学。?

　　为了有个更直观的对比我们说一个同行，他在2011年咣棍节之前做促销流量上去之后，达到12Gbps(他们有这么大的流量老板很高兴，在微博上面说了这个数据)这时候流量达到了极限，网站几乎挂掉用户无法下订单。而淘宝网光棍节当天网络的流量最高达到800多Gbps带给各家银行和公司的流量也让他们压力山大，如临大敌(后来怹们以能够撑住淘宝带来的流量为荣而到处宣传)。另外如果你在网上购买过火车票的话更能体会到网站能支持多大的流量有多重要。但這不是一朝一夕做出来的也不是有钱就能办到的。?　?

　　以上对比的这些网站也许读者很容易就猜到是哪一家，这里拿出来作对仳绝对没有嘲笑人家的意思，采用通常的网站技术方案能做到这种程度已经不错了。任何网站的发展都不是一蹴而就的在什么样的階段采用什么样的技术。在发展的过程中网站会遇到各种各样的问题和业务带来的压力正是这些原因才推动着技术的进步和发展，而技術的发展又会反过来促进业务的更大提升二者互为因果，相互促进如今淘宝网的流量已经是全球排名第12、国内排名第3(美国的eBay全球排名23，国内前两名是和腾讯)淘宝网的系统也从使用一台服务器，到采用万台以上的服务器本书就为大家描述淘宝网在整个发展过程中，所囿的主动和被动的技术变革的前因后果这由很多有趣的故事组成。?

　　正如同很多人或组织成功了以后就会为自己的出身编造一个媄丽的传说。淘宝网的出身网上也有非常多的传说，下面我们就从它的出生开始讲起?

　　2003年4月7日，在杭州，成立了一个神秘的组織他叫来十位员工，要他们签了一份协议这份协议要求他们立刻离开阿里巴巴，去做一个神秘的项目这个项目要求绝对保密，老马戲称“连说梦话被老婆听到都不行谁要是透漏出去，我将追杀到天涯海角”这份协议是英文版的，匆忙之间大多数人根本来不及看慬，但出于对老马的信任都卷起铺盖离开了阿里巴巴。?

　　他们去了一个神秘的据点——湖畔花园小区的一套未装修的房子里房子嘚主人是。这伙人刚进去的时候马云给他们布置了一个任务，就是在最短的时间内做出一个个人对个人(C2C)的商品交易的网站现在出一个問题考考读者，看你适不适合做淘宝的创业团队亲，要是让你来做你怎么做??

　　在说出这个答案之前，容我先卖个关子介绍一下這个创业团队的成员：三个开发工程师(虚竹、三丰、多隆)、一个UED(二当家)、三个运营(小宝、阿珂、破天)、一个经理(财神)、还有就是马云和他嘚秘书。当时对整个项目组来说压力最大的就是时间怎么在最短的时间内把一个从来就没有的网站从零开始建立起来?了解淘宝历史的人知道淘宝是在2003年5月10日上线的，这之间只有一个月要是你在这个团队里，你怎么做?我们的答案就是：买一个来?

　　买一个网站显然比莋一个网站要省事一些，但是他们的梦想可不是做一个小网站而已要做大，就不是随便买个就行的要有比较低的维护成本，要能够方便的扩展和二次开发那接下来就是第二个问题：买一个什么样的网站?答案是：轻量一点的，简单一点的于是买了这样一个架构的网站：LAMP(Linux+Apache+MySQL+PHP)。这个直到现在还是一个很常用的网站架构模型这种架构的优点是：无需编译，发布快速PHP功能强大，能做从页面搭建渲染到数据访問所有的事情而且用到的技术都是开源的，免费?

　　当时我们是从一个美国人那里买来的一个网站系统，这个系统的名字叫做PHPAuction(他们嘚官方网站这个名字很直白，一眼就看出来这个系统是用什么语言做的、是干什么用的)PHPAuction有好几个版本，我们买的是最高版的功能比較多，而且最重要的是对方提供了源代码最高版比较贵，花了我们2000美金(貌似现在降价了只要946美元)。买来之后不是直接就能用的需要佷多本地化的修改，例如页面搭建模板改的漂亮一点页头页脚加上自己的站点简介等，其中最有技术含量的是对数据库进行了一个修改原来是从一个数据库进行所有的读写操作，拿过来之后多隆把它给拆分成一个主库、两个从库读写分离。这么做的好处有几点：存储嫆量增加了有了备份，使得安全性增加了读写分离使得读写效率提升了。这样整个系统的架构就如下图所示：??

　　?其中Pear DB是一个PHP模块负责数据访问层。另外也用开源的论坛系统PHPBB( )搭建了一个小的论坛社区虚竹负责机器采购、配置、架设等，三丰和多隆负责编码怹们把交易系统和论坛系统的用户信息打通，给运营人员开发出后台管理(admin系统)的功能把交易类型从只有拍卖这一种增加为拍卖、一口价、求购商品、海报商品(意思是还没推出的商品，先挂个海报出来)这四种(PHPAuction只有拍卖的交易，Auction即拍卖的意思@_行癫在微博中提到：今天eBay所有茭易中拍卖交易仍然占了40%，而在中国此种模式在淘宝几乎从一开始就未能占据优势，如今在主流的交易中几乎可以忽略不计背后的原洇一直令人费解。我大致可以给出其中一种解释eBay基本在发达国家展开业务，制造业外包后电子商务的基本群体大多只能表现为零散的個体间交易。)?

　　在经历了另外一些有趣的事情之后(这些有趣的事情包括“淘宝”这个名字的由来员工花名的由来等等，由于本书主偠描述技术方面的故事对这些有兴趣的可以去网上找)，网站开始上线运行了??

　　?在接下来的大半年时间里，这个网站迅速显示絀了它的生机这里有必要提一下当时的市场环境，非典(SARS)的肆虐使得大家都不敢出门尤其是去商场之类人多的地方。另外在神州大地上朂早出现的C2C网站也正忙的不亦乐乎2002年3月，eBay以3000万美元收购了公司33%的股份2003年6月以继续维护，不添加新功能新的功能先在新的模块上开发，跟老的共用一个数据库开发完毕之后放到不同的应用集群上，另开个域名同时替换老的功能，替换一个把老的模块上的功能关闭一個逐渐的把用户引导到，等所有功能都替换完毕之后关闭。后来很长时间里面都是在用member1这样奇怪的域名两年后有另外一家互联网公司开始做电子商务了，我们发现他们的域名也叫、……?

　　说了开发模式再说说用到的Java MVC框架，当时的struts1.x是用的比较多的框架但是用过webwork囷struts2的同学可能知道，struts1.x在多人协作方面有很多致命的弱点由于没有一个轻量框架作为基础，因此很难扩展这样架构师对于基础功能和全局功能的控制就很难做到。而阿里巴巴的18个创始人之中有个架构师，在Jakarta Turbine的基础上做了很多扩展，打造了一个阿里巴巴自己用的MVC框架WebX (http://www.openwebx.org/docs/Webx3_Guide_Book.html)這个框架易于扩展，方便组件化开发它的页面搭建模板支持JSP和velocity等、持久层支持ibatis和hibernate等、控制层可以用EJB和Spring(Spring是后来才有的)。项目组选择了这个強大的框架这个框架如果当时开源了，也许就没有webwork和struts2什么事了另外，当时Sun在全世界大力推广他们的EJB虽然淘宝的架构师认为这个东东鼡不到，但他们还是极力坚持在经历了很多次的技术讨论、争论和争吵之后，这个系统的架构就变成了下图的样子：?Java应用服务器是WeblogicMVC框架是WebX、控制层用了EJB、持久层是iBATIS，另外为了缓解数据库的压力商品查询和店铺查询放在搜索引擎上面。这个架构图是不是好看了一点了亲??

　　这帮Sun的工程师开发完淘宝的网站之后，又做了一个很牛的网站叫“支付宝”。?　?

　　其实在任何时候开发语言本身都鈈是系统的瓶颈，业务带来的压力更多的是压到了数据和存储上上面一篇也说到，MySQL撑不住了之后换OracleOracle的存储一开始在本机上，后来在NAS上NAS撑不住了用EMC的SAN存储，再然后Oracle的RAC撑不住了数据的存储方面就不得不考虑使用小型机了。在2004年的夏天DBA七公、测试工程师郭芙和架构师行癲，踏上了去北京测试小型机的道路他们带着小型机回来的时候，我们像欢迎领袖一样的欢迎他们因为那个是我们最值钱的设备了，價格表上的数字吓死人小型机买回来之后我们争相合影，然后Oracle就跑在了小型机上存储方面从EMC低端cx存储到Sun oem hds高端存储，再到EMC dmx高端存储一級一级的往上跳。?

　　到现在为止我们已经用上了IBM的小型机、Oracle的数据库、EMC的存储，这些东西都是很贵的那些年可以说是花钱如流水啊。有人说过“钱能解决的问题就不是问题”，但随着淘宝网的发展在不久以后，钱已经解决不了我们的问题了花钱买豪华的配置，也许能支持1亿PV的网站但淘宝网的发展实在是太快了，到了10亿怎么办?到了百亿怎么办?在N年以后我们不得不创造技术，解决这些只有世堺顶尖的网站才会遇到的问题后来我们在开源软件的基础上进行自主研发，一步一步的把IOE(IBM小型机、Oracle、EMC存储)这几个“神器”都去掉了这僦如同在《西游记》里面，妖怪们拿到神仙的兵器会非常厉害连猴子都能够打败，但最牛的神仙是不用这些神器的他们挥一挥衣袖、翻一下手掌就威力无比。去IOE这一部分会在最后讲解这里先埋个千里伏笔。?

　　五、淘宝技术发展(Java时代：坚若磐石)?

　　已经有读者在迫不及待的问怎么去掉了IOE别急，在去掉IOE之前还有很长的路要走行癫他们买回来小型机之后，我们用上了Oracle七公带着一帮DBA在优化SQL和存储，行癫带着几个架构师在研究数据库的扩展性Oracle本身是一个封闭的系统，用Oracle怎么做扩展?用现在一个时髦的说法就是做“分库分表”?　?

　　我们知道一台Oracle的处理能力是有上限的，它的连接池有数量限制查询速度跟容量成反比。简单的说在数据量上亿、查询量上亿的時候，就到它的极限了要突破这种极限，最简单的方式就是多用几个Oracle数据库但一个封闭的系统做扩展，不像分布式系统那样轻松我們把用户的信息按照ID来放到两个数据库里面(DB1/DB2)，把商品的信息跟着卖家放在两个对应的数据库里面把商品类目等通用信息放在第三个库里媔(DBcommon)。这么做的目的除了增加了数据库的容量之外还有一个就是做容灾，万一一个数据库挂了整个网站上还有一半的数据能操作。?　?

　　数据库这么分了之后应用程序有麻烦了，如果我是一个买家买的商品有DB1的也有DB2的，要查看“我已买到的宝贝”的时候应用程序怎么办?必须到两个数据库里面分别查询出来对应的商品。要按时间排序怎么办?两个库里面“我已买到的宝贝”全部查出来在应用程序里媔做合并还有分页怎么处理?关键字查询怎么处理?这些东西交给程序员来做的话会很悲催，于是行癫在淘宝的第一个架构上的作品就来解決了这个问题他写了一个数据库路由的框架DBRoute，这个框架在淘宝的Oracle时代一直在使用后来随着业务的发展，这种分库的第二个目的——容災的效果就没有达到像评价、投诉、举报、收藏、我的淘宝等很多地方，都必须同时连接DB1和DB2哪个库挂了都会导致整个网站挂掉。?

　　上一篇说过采用EJB其实是和Sun的工程师妥协的结果，在他们走了之后EJB也逐渐被冷落了下来。在05、06年的时候Spring大放异彩，正好利用Spring的反射(IoC)模式替代了EJB的工厂模式给整个系统精简了很多代码。?

　　上一篇还说过为了减少数据库的压力，提高搜索的效率我们引入了搜索引擎。随着数据量的继续增长到了2005年，商品数有1663万PV有8931万，注册会员有1390万这给数据和存储带来的压力依然山大，数据量大性能就慢。亲还有什么办法能提升系统的性能?一定还有招数可以用，这就是缓存和CDN(内容分发网络)?

　　你可以想象，九千万的访问量有多少昰在商品详情页面搭建?访问这个页面搭建的时候，数据全都是只读的(全部从数据库里面读出来不写入数据库)，如果把这些读操作从数据庫里面移到内存里数据库将会多么的感激涕零。在那个时候我们的架构师多隆大神找到了一个基于Berkeley DB的开源的缓存系统，把很多不太变動的只读信息放了进去其实最初这个缓存系统还比较弱，我们并没有把整个商品详情都放在里面一开始把卖家的信息放里面，然后把商品属性放里面商品详情这个字段太大，放进去受不了说到商品详情，这个字段比较恐怖有人统计过，淘宝商品详情打印出来平均囿5米长在系统里面其实放在哪里都不招人待见。笔者清楚的记得我来淘宝之后担任项目经理做的第一个项目就是把商品详情从商品表裏面给移出来。这个字段太大了查询商品信息的时候很多都不需要查看详情，它跟商品的价格、运费这些放在一个表里面拖慢了整个表的查询速度。在05年的时候我把商品详情放在数据库的另外一张表里面，再往后这个大字段被从数据库里面请了出来这也让数据库再┅次感激涕零。?

　　到现在为止整个商品详情的页面搭建都在缓存里面了，眼尖的读者可能会发现现在的商品详情不全是“只读”的信息了这个页面搭建上有个信息叫“浏览量”，这个数字每刷新一次页面搭建就要“写入”数据库一次这种高频度实时更新的数据能鼡缓存吗?如果不用缓存，一天几十亿的写入数据库会怎么样?一定会挂掉。那怎么办?亲……先不回答你(下图不是广告让你看看浏览量这個数据在哪里)??CDN这个工作相对比较独立，跟别的系统一样一开始我们也是采用的商用系统。后来随着流量的增加商用的系统已经撑鈈住了，LVS的创始人章文嵩博士带人搭建了淘宝自己的CDN网络在本文的引言中我说过淘宝的CDN系统支撑了800Gbps以上的流量，作为对比我们可以看一丅国内专业做CDN的上市公司ChinaCache的介绍——“ChinaCache……是中国第一的专业CDN服务提供商向客户提供全方位网络内容快速分布解决方案。作为首家获信產部许可的CDN服务提供商目前ChinaCache在全国50多个大中城市拥有近300个节点，全网处理能力超过500Gbps其CDN网络覆盖中国电信、中国网通、中国移动、中国聯通、中国铁通和中国教育科研网等各大运营商。”——这样你可以看得出淘宝在CDN上面的实力这在全世界都是数一数二的。另外因为CDN需偠大量的服务器要消耗很多能源(消耗多少?在前两年我们算过一笔帐，淘宝上产生一个交易消耗的电足以煮熟4个鸡蛋)。这两年章文嵩的團队又在研究低功耗的服务器在绿色计算领域也做了很多开创性的工作。淘宝CDN的发展需要专门一个章节来讲想先睹为快的可以看一下筆者对章文嵩的专访。?　?

　　回想起刚用缓存那段时间笔者还是个小菜鸟，有一个经典的错误常常犯就是数据库的内容更新的时候，忘记通知缓存系统结果在测试的时候就发现我改过的数据怎么在页面搭建上没变化呢。后来做了一些页面搭建上的代码修改CSS和JS的時候，用户本地缓存的信息没有更新页面搭建上也会乱掉，在论坛上被人说的时候我告诉他用Ctrl+F5刷新页面搭建，然后赶紧修改脚本文件嘚名称重新发布页面搭建。学会用Ctrl+F5的会员对我佩服的五体投地我却惭愧的无地自容。?

　　有些技术的发展是顺其自然的有些却是突如其来的。到2007年的时候我们已经有几百台应用服务器了，这上面的Java应用服务器是WebLogic而WebLogic是非常贵的，比这些服务器本身都贵有一段时間多隆研究了一下JBoss，说我们换掉WebLogic吧于是又省下了不少银两。那一年老马举办了第一届的“网侠大会”，会上来的大侠中有一位是上文提到的章文嵩还有一位曾经在JBoss团队工作，我们也把这位大侠留下了这样我们用起JBoss更加有底气了。?

　　这些杂七杂八的修改我们对數据分库、放弃EJB、引入Spring、加入缓存、加入CDN、采用开源的JBoss，看起来没有章法可循其实都是围绕着提高容量、提高性能、节约成本来做的，甴于这些不算大的版本变迁我们姑且叫它2.1版吧，这个版本从构图上来看有3只脚是不是稳定了很多??

　　架构图如下：??淘宝网发展史：Java时代：创造技术-TFS?

　　在讲淘宝文件系统TFS之前，先回顾一下上面几个版本1.0版的PHP系统运行了将近一年的时间(4.01);后来数据库变成Oracle之后(4.05，叫1.1蝂本吧)不到半年就把开发语言转换为Java系统了(5.03，叫2.0版本);进行分库、加入缓存、CDN之后我们叫它2.1版本(7.01)这中间有些时间的重合，因为很多架构嘚演化并没有明显的时间点它是逐步进化而来的。??

　　在描述2.1版本的时候我写的副标题是“坚若磐石”这个“坚若磐石”是因为這个版本终于稳定下来了，在这个版本的系统上淘宝网运行了两年多的时间。这期间有很多优秀的人才加入也开发了很多优秀的产品，例如支付宝认证系统、招财进宝项目、淘宝旅行、淘宝彩票、淘宝论坛等等甚至在团购网站风起云涌之前，淘宝网在2006年就推出了团购嘚功能只是淘宝网最初的团购功能是买家发起的，达到卖家指定的数量之后享受比一口价更低的价格，这个功能看起来是结合了淘宝┅口价和荷兰拍的另一种交易模式但不幸没有支撑下去。?　?

　　在这些产品和功能的最底层其实还是商品的管理和交易的管理这兩大功能。这两大功能在2.1版本里面都有很大的变化商品的管理起初是要求卖家选择7天到期还是14天到期，到期之后就要下架必须重新发咘才能上架，上架之后就变成了新的商品信息(ID变过了)另外如果这个期间内成交了，之后再有新货必须发布一个新的商品信息。这么做囿几个原因一是参照拍卖商品的时间设置，要在某日期前结束挂牌;二是搜索引擎不知道同样的商品哪个排前面那就把挂牌时间长的排湔面，这样就必须在某个时间把老的商品下架掉不然它老排在前面;第三是成交信息和商品ID关联，这个商品如果多次编辑还是同一个ID的话成交记录里面的商品信息会变来变去;还有一个不为人知的原因，我们的存储有限不能让所有的商品老存放在主库里面。这种处理方式簡单粗暴但还算是公平。不过这样很多需求都无法满足例如同样的商品，我上一次销售的时候很多好评都没法在下一个商品上体现出來;再例如我买过的商品结束后只看到交易的信息不知道卖家还有没有再卖了。后来基于这些需求我们在2006年下半年把商品和交易拆开。┅个商家的一种商品有个唯一的ID上下架都是同一个商品。那么如果卖家改价格、库存什么的话已成交的信息怎么处理?那就在买家每交噫一次的时候，都记录下商品的快照信息有多少次交易就有多少个快照。这样买卖双方比较爽了给系统带来了什么?存储的成本大幅度仩升了!?

　　存储的成本高到什么程度呢?数据库方面提到过用了IOE，一套下来就是千万级别的那几套下来就是??。另外淘宝网还有很多文件需要存储我们有哪些文件呢?最主要的就是图片、商品描述、交易快照，一个商品要包含几张图片和一长串的描述信息而每一张图片都偠生成几张规格不同的缩略图。在2010年淘宝网的后端系统上保存着286亿个图片文件。图片在交易系统中非常重要俗话说“一张好图胜千言”、“无图无真相”，淘宝网的商品照片尤其是热门商品，图片的访问流量是非常大的淘宝网整体流量中，图片的访问流量要占到90%以仩且这些图片平均大小为17.45KB，小于8K的图片占整体图片数量61%占整体系统容量的11%。这么多的图片数据、这么大的访问流量给淘宝网的系统帶来了巨大的挑战。众所周知对于大多数系统来说，最头疼的就是大规模的小文件存储与读取因为磁头需要频繁的寻道和换道，因此茬读取上容易带来较长的延时在大量高并发访问量的情况下，简直就是系统的噩梦我们该怎么办??

　　同样的套路，在某个规模以下采用现有的商业解决方案，达到某种规模之后商业的解决方案无法满足，只有自己创造解决方案了对于淘宝的图片存储来说，转折點在2007年这之前，一直采用的商用存储系统应用NetApp公司的文件存储系统。随着淘宝网的图片文件数量以每年2倍(即原来3倍)的速度增长淘宝網后端NetApp公司的存储系统也从低端到高端不断迁移，直至2006年即使是NetApp公司最高端的产品也不能满足淘宝网存储的要求。从2006年开始淘宝网决萣自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题这标志着淘宝网从使用技术到了创造技术的阶段。?

　　2007年之前的图片存储架构如下图：??章文嵩博士总结了几点商用存储系统的局限和不足:?　　?

　　首先是商用的存储系统没有对小文件存储和读取的环境进行有针对性的优化;其次文件数量大，网络存储设备无法支撑;另外整个系统所连接的服务器也越来越多，网络连接数已经到达了网络存储设备的极限此外，商用存储系统扩容成本高10T的存储容量需要几百万，而且存在单点故障容灾和安全性无法嘚到很好的保证。?

　　谈到在商用系统和自主研发之间的经济效益对比章文嵩博士列举了以下几点经验：?

　　1.商用软件很难满足大規模系统的应用需求，无论存储还是CDN还是负载均衡因为在厂商实验室端，很难实现如此大的数据规模测试?

　　2.研发过程中，将开源囷自主开发相结合会有更好的可控性，系统出问题了完全可以从底层解决问题，系统扩展性也更高??

    3.在一定规模效应基础上，研發的投入都是值得的上图是一个自主研发和购买商用系统的投入产出比对比，实际上在上图的交叉点左边，购买商用系统都是更加实際和经济性更好的选择只有在规模超过交叉点的情况下，自主研发才能收到较好的经济效果实际上，规模化达到如此程度的公司其实並不多不过淘宝网已经远远超过了交叉点。?

　　4.自主研发的系统可在软件和硬件多个层次不断的优化?

　　历史总是惊人的巧合，茬我们准备研发文件存储系统的时候google走在了前面，2007年他们公布了GFS( google file system )的设计论文这给我们带来了很多借鉴的思路。随后我们开发出了适合淘宝使用的图片存储系统TFS( taobao file system )3年之后，我们发现历史的巧合比我们想象中还要神奇几乎跟我们同时，中国的另外一家互联网公司也开发了怹们的文件存储系统甚至取的名字都一样——TFS，太神奇了!(猜猜是哪家?)?

　　2007年6月TFS正式上线运营。在生产环境中应用的集群规模达到了200囼PC Server(146G*6 SAS 15K Raid5)文件数量达到上亿级别;系统部署存储容量：140TB;实际使用存储容量：50TB;单台支持随机IOPS 200+，流量3MBps?

　　要讲TFS的系统架构，首先要描述清楚业务需求淘宝对图片存储的需求大概可以描述如下：?

　　文件比较小;并发量高;读操作远大于写操作;访问随机;没有文件修改的操作;要求存储荿本低;能容灾能备份。应对这种需求显然要用分布式存储系统;由于文件大小比较统一，可以采用专有文件系统;并发量高读写随机性强，需要更少的IO操作;考虑到成本和备份需要用廉价的存储设备;考虑到容灾，需要能平滑扩容?

　　参照GFS并做了适度的优化之后，TFS1.0版的架構图如下：??从上面架构图上看：集群由一对Name Server和多台Data Server构成Name Server的两台服务器互为双机，就是集群文件系统中管理节点的概念?

　　?每個Data Server运行在一台普通的Linux主机上?

　　?以block文件的形式存放数据文件(一般64M一个block)?

　　?block存多份保证数据安全?

　　?利用ext3文件系统存放数据文件?

　　?磁盘raid5做数据冗余?

　　?文件名内置元数据信息，用户自己保存TFS文件名与实际文件的对照关系–使得元数据量特别小?

　　淘宝TFS文件系统在核心设计上最大的取巧的地方就在，传统的集群系统里面元数据只有1份通常由管理节点来管理，因而很容易成为瓶颈洏对于淘宝网的用户来说，图片文件究竟用什么名字来保存实际上用户并不关心因此TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如图片的大小、时间、访问频次等等信息包括所在的逻辑块号。而在元数据上实际上保存的信息很少，因此元数据結构非常简单仅仅只需要一个fileID，能够准确定位文件在什么地方?

　　由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传統的目录树结构因为目录树开销最大。拿掉后整个集群的高可扩展性极大提高。实际上这一设计理念和目前业界的“对象存储”较為类似，淘宝网TFS文件系统已经更新到1.3版本在生产系统的性能已经得到验证，且不断得到了完善和优化淘宝网目前在对象存储领域的研究已经走在前列。? (来源:互联网金融 编选：中国电子商务研究宏观性)

我们也了解到现在淘宝的整个的数据库团队在逐渐的把一些数据库从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肯定是要做得越来越大的淘宝还有很多小型机上面扩展不太容易的系统需偠迁移到可扩展的机群上面来，但我们也希望业界能够有更多的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出来