双十一事件双十二事件

伏威你好，请简单给我们做一下自我介绍，以及你在这次淘宝双十一事件中所扮演的一个角色。

OK，我是淘宝产品技术部主要负责商品线的Leader。我叫唐勇，花名叫伏威。这一次双十一我在里面主要担当了一个联系人的角色，因为我所在的产品技术部，主要负责的是淘宝主站交易，就是我们的交易系统，像商品线等一些系统全部在这个部门里面。因为我所在的这个部门的职责以及我对他们的了解，这次就承担了这样的一个协调工作。因为我以前做交易线的时候和支付宝也打过交道，跟支付宝之间的交流，去协调，还包括旺旺等其他一些外部和内部的联系都是我在做。

就是整个双十一事件里面所涉及到所有和外围技术团队的沟通都是你来负责？

是的，我是处于一个联系人的角色。

其实刚才我们在采访之前沟通的时候也提到一个名词叫“战地指挥所”，这个组织会来指挥双十一事件那几天所有的技术事件，你能不能简单给我们介绍一下这一个组织的结构组成？

战地指挥所并不是它原有的名称，其实我们就叫做“双十一保障团队”。但是我们的一个经理，他来到我们整个安保的房间里面走过一遍以后，然后发了一篇微博，起了一个“战地指挥所”的名字，就一直就保留下来了。“战地指挥所”本身就是这一次淘宝在外面大规模做广告，而且半价优惠，诱惑力都是很大，为了保证这双十一这一天的交易能够平稳顺畅的进行，那我们的整个技术部的Leader东邪，要求我们成立的一个保障团队。组长就是我们的振飞，全名叫刘振飞，他协调各个部门的人，包括我们部门的三个人，范禹、黄裳和我。范禹和黄裳他们两个是在淘宝土生土长起来的技术专家，对淘宝的整个的系统以及业务是了如指掌，他们是以技术专家的角色参加这个安保小组。然后还有包括振飞下面的其他一些包括网络的团队，运维的团队，都有人参加，还有包括我们的DBA江枫，都参加了这个团队，一起保障整个双十一活动平稳进行。

其实像黄裳在我们做QCon 2009的时候，他也做过演讲，并且非常受欢迎。那我们想了解的就是在业务部门出台双十一这个计划之后，技术部有没有做哪些可行性的分析，或者说叫预案，然后他又是如何去验证这些技术方案的？

很难说我们做了什么技术方案的这种分析，或者说预估。因为我们淘宝每次大的系统结构改造都是要持续半年，在一个活动开始前短短一个月的时间内，你很难去做一个所谓的技术方案。而且我们用户去淘宝上访问的是什么？其实就是淘宝的交易系统，他就是去做交易，做商品，这些功能都是已有的，他其实不存在一个技术方案的分析。那我们只是去做什么？只是去做一些可能出问题的一些系统的预警方案，或者说我们称之为预案。那么可能就是在什么样的一个压力的情况下，我们要做什么样的反应，是否是需要加急，是否是要做特定的系统降级等等。但是就是可行性分析方案几乎就没有，因为在那个时候你很难去做。就好像考试一样，你临时抱佛脚在淘宝是很难抱的，你只能靠在淘宝，就是你在之前的一系列的积累到现在，那这时候发挥作用，就是临时磨枪是不快的，也不光的。

那你所制订的那些预案和最终在10号、11号那两天有没有经过一些验证，或者说发现有那些做得还不是非常好的地方？

这个可能要讲得更全面一点，就是因为那天，我作为联络人，当振飞那天开会的时候，就请了旺旺的团队、支付宝的团队，和我们内部关键应用系统的团队，在一起来开会，我们会对整个活动的开展做了预测。一个是这次活动，预估会带来多大的流量的增量，以及每个系统它有多大的余量，然后到那一天可能会产生什么样的问题，以及这个问题背后，我们如何去做预防，包括刚才说到的服务的降级是否可以去做等。还有就是一些容错措施是否要起作用，我们都做了预估。那么那一天所列出来方案，说实话就是在后期也验证了不足，不足的原因是在哪里呢？一是我们远远低估了全国人民的热情，当面对我们双十一全场半价的这种诱惑力的时候，感觉在淘宝上购物的那帮人都疯狂了，大规模的涌进。造成系统压力持续增高，那么有些方案，包括我们为了应对支付宝的整个系统的一个压力的方案，我们有一些功能上的取舍。

比如说那天，我们大家现在都知道确认收货是被停掉的，大概是下午四点多，五点左右被停掉的，为什么？就是为了应对高峰期的压力，这些预案都基本上起作用了。而之前我们在系统设计的时候，其实这种降级的服务方案，我们都已经放进去了，在那一天就得到了验证。还有些东西是我们没有办法预估的，包括，那天用户疯狂的涌进对我们整个CDN的流量的压力，因为我们平时CDN流量可能是一，但是那天翻到了三，这种200%、300%的增长，对我们整个的体系都是一个很大的冲击。而CDN的布局你是没有办法临时去扩容的，不像我们应用服务器，你可以临时去加机器，它是很难做到的，这时候我们的网络服务团队和应用团队其实是在一起去解决这个问题，不是单方面的努力，而是我们应用和运维团队一起去把整个流量降低下来了。那我们感觉很庆幸，就是那天到晚上，我们之前做过的很多预案都起了作用，到最后才平稳的支撑过了晚上整个的交易高峰期。

那我们现在再简单回顾一下，比如说10号、11号那两天，你在做什么？或者说你对整个事件的一个流程有没有什么把握？

这个其实我觉得就用我心态的变化来做介绍好了，我加入淘宝三年，我参加过很多次大型的项目，从最开始的秒杀活动到双十一等一些大型的项目，都感觉不会有太大问题。当时振飞成立的一个团队，我们在开会的时候都很紧张。然后我还说不用这么紧张吧，这绝对不会有问题的，这个大家不用草木皆兵，当时就觉得我自己是一个安心。但是从10号我们开始值班，到10号那天晚上开始就觉得，有点Crazy，就是我们到凌晨两点的时候，我们整个就是商城的交易额已经突破了六千万了，这在平时是不可想象的。我觉得当时心里就一绷，会不会明天太疯狂？然后到第二天凌晨九点我们上班的时候，就已经开始紧张了。就是因为当时整个商城的交易额都已经突破将近一个亿了。而且我们CDN流量当时已经达到了380多个G了，而我们预估的流量是没有那么大的。

这时候我们就开始紧急设计各种各样的预案，在那天能够生效的预案，包括为了降低CDN的压力，我们在应用上要做得分析。当时我们的一些核心数据库也报出来有些风险，因为200%的增量，这个在平时我们不可想象的。这时候我们要去做哪些服务的降级，要停掉哪些在比如说DBS，数据库操作层面的一些东西，让整个数据库的支撑量会更大。那时候我们都开始做，那到下午三四点的时候，那时候紧张达到了顶点，因为我们不知道下午和晚上会发生什么。当时我们可以做得事情我们全都已经去做了。那到晚上九点、十点的时候，我们发现我们支撑过那个压力以后心情慢慢放松了。当时我们头天还在考虑说，双十一活动对吧，半价，我们要去抢购什么商品，在九点十点之前我们从来没有那个心情去做抢购，然后到十点以后，这时候我们才开始放松下来，可以去采购一些商品，为自己买东西。那时候好东西都被抢光了，真的是没办法。因为最后运营才告诉我，真的是只要有好东西上去就疯抢，好东西上去就疯抢，我们最后意思意思买了一些不打折的商品，以支持淘宝的交易额。

所以说整个心态就从一个很稳定，就是觉得放心、放松、没事情到紧张，然后到紧张到高峰，然后最后再下来，就是好像坐了一个过山车。而那个过山车绝对不是说你能预估到的。这种心态的变化对于我们来说还是蛮有挑战性的。而且我之前接受我们内部的采访的时候告诉他们，我说我们是希望双十一平平静静、安安定定，我们的技术人员是不要出面的，你们不要意识到我们存在。开心的是我们那天我们露面了，我们去，真的是为这次活动做出了很大的贡献。然后不安的地方是呢，希望下次不要这样，我们真的就希望暴风雨在淘宝是无声无息的，你每个会员可以开开心心的采购商品，你不要意识到后台我们技术做了什么，也不希望有任何功能去做了降级，比如说确认收货你不能确实收货，而这种事情发生是我们不希望的，所以说既开心又感觉到有点失落，我们还是没有做到无声无息，其实我觉得最大的成就应该在于无声无息。

其实根据网上一些读者、网友的反馈，淘宝技术团队已经做得非常非常棒。然后我记得有一个网友他就这样提到说，其实对于一个技术人员来讲，他的整个的业生涯里面能够经历一次这样的事情是非常非常难得的。那对于你个人来讲，你认为这件事情给你印象最深得，或者是还有一些就是你比较后怕的事情是什么？

让我印象最深的第一个是执行力，阿里特有的执行力，就是在我们活动当天，虽然出现了那么多问题。但是因为我们的执行力超高，我们所有去做事情的人没有任何懈怠的意识，任何辛苦他们都能承担下来，任何压力他们都能承担下来。这是我觉得我印象最深刻的之一。第二个呢，也是我庆幸，开心也后怕的，如果没有 2010年这一整年，我们花了大力气在系统改造上面，在我们的技术优化上面，那一天就不是森林里面的一点小火了，就是整个森林全都起火，就是火灾，你根本就没有办法应对，就是我们所有预案在那天都不可能起作用，我们就好像一个身患重病的病人，躺在椅子上等死，什么都干不了，也就是因为我们这一年做出了这么大的努力。我也庆幸我们这一年做出了这么多的技术的新的改造和优化，否则的话我们那天肯定撑不过去的。

其实大家只看到说我们那一天，比如说在CDN上做了很多文章，就是为支付宝做了很多事情，但是还有很多更关键的系统，比如说我们的交易详情的页面，商品详情的页面，商品详情页面比平时的压力直接打破了三倍。如果没有我们今年，就是连续三次大型的优化是根本就实现不了的，而我们的优化是什么？我们从直接提升了它的性能的700%，也就是说我们有信心，在双十一高峰期再增长50%到80%的情况下，我们的商品详情页面依然撑得住，还有包括我们的，交易数据库今年做了拆分和读写分离，它直接的系统能力在双十一的基础上还可以再上浮很多。那如果没有这些的话，我们那天根本就支撑不住；还有就是对用户信息访问这种 UIC（User Interface Center），当时我们产生了上百亿的内部的访问请求，就是这种系统的压力，如果不是我们做了整个读写分离的优化，以及就是通过MySQL，让我们的系统可以水平的扩展，我们也是支撑不了的。

所以说我感觉庆幸是，感觉开心的是我们的执行力和我们技术团队的工作，我感觉后怕以及庆幸的是我们做了这些技术改造和优化，让我们双十一可以支撑过去，让我们的那些技术的预案有所作为，否则的话就是做无可做了。

其实双十一事件它之所以技术团队能够保证它的正常运行，还是和整个淘宝这一年来他这个技术改造是完全分不开的？

对，而且不只是这一年。我们遥想将来，就是明年，就是我们要做的事情就是可能更多，我们的步伐需要更大，否则的话明年年底会再来同样的事情出现，我估计全国人民会更疯狂。是吧？

对，今年可能有很多人都没有抢上，或者他根本没有得到这个信息？

对，是的。

其实刚才我们也在聊的过程中也提到一个容灾和一个降级服务，其实这一个是一个很多大型的网站，特别是一些电子商务的网站，都是非常关注的一点。那么给我们简单介绍一下这两个技术，它的关键点在什么地方？

我也看见了。就是在InfoQ在网上搜集信息的时候，有一个朋友在问，就是我们如何支撑这么大的压力？就是我们如何去应付这种高性能并发访问的，简单而言，我们把这张图画出来，它可能就是一个典型的Web上层架构体系，但其他重点还是在细节上面。为什么我会提到这一点呢？其实我们的容灾、包括降级服务也在淘宝整个发展过程中，我们发现的一些细节上的意识点，而最后成功的关键也在这些地方，就是因为我们现在做了很多事情，就是从一个高性能的就是 Oracle，它的稳定性很强。因为我们为了支持它的水平可扩性，我们做了改动。但在一个不稳定的系统上面，你如何去做到容灾，让前端的访问能够顺畅的访问，而后台单点出问题的时候，可以水平上移滑到另外一个点上去，这些都是一些细节；还有包括服务降级，服务降级就更简单了，在系统压力过大的情况下，或者说单点出问题的情况下，能不能通过降级让它的整个系统能支持住更大的流量，而且能够平稳的让用户的购物流程平滑，这就是我们要去做的。

而我们淘宝现在就在这个细节上面已经融入到了我们的设计当中。可能在采访范禹的时候他也会讲到我们淘宝的几个大型系统的一个技术型改造的一个活动，那在这个中间，我们就已经做到了，这种水平的大型改造，我们已做到无声无息，就是我称之为没有新闻就是最好的新闻。就是可能在你上层结构都还不知道情况下，我大型改造都已经完成了，所以说这种细节还是非常关键和至关重要的。所以说降级和容灾只是这些系统中间的一个部分，那只是说，在我们为了应付双十一的这种大流量的并发的情况下，我们在这上面表现的比较关键而已，起的作用会比较大一点，但实际上还有更多的细节。

那我们最后来回顾总结一下双十一事件，它给你带来的一些感想。另外就是对其他的电子商务网站，他的一些技术上的朋友，给他们提一些建议什么的？

如果说我们要去总结经验，那我可以这样说，就是战略上要藐视，战术上要重视，然后工作一定要在平时，就是你要在平时做得扎实，你才可能有信心去支持这么大规模的访问增长，否则的话肯定支撑不下。现在因为我们外部的B2C网站有慢慢的持续增长，就是这种系统压力增长的话，给他们带来很多的问题，那我觉得其实应该去做的事情是在细节上做文章，真的是把单点去做大做强，最后才能打造整个系统的稳定性。这个我自己称之为木桶效应，就是因为决定你木桶容量的永远是最短的一个板，就是你要不断的发现你的短板。

而且在淘宝另外一个经验是什么呢？我们每年的增长是200%，那你的技术的增长也必须在200%以上，你才能保证能支撑住这么大的增长量。它如果出现高峰期，远远会超过200%，所以说建议大家每半年Review一下自己的系统，以保证你将来200% 的量是可以支撑得住的。现在淘宝，我说句不太好听的话，我们每半年如果系统没有经过Review，没有经过大型的改造，它在下一个半年可能就会出问题。就是我们对大型的结构，几乎持续的在改动，才能支撑这个量。另外一个就是双十一的经验，这么大规模的量的增长，不是你开发在做事情，也不是数据库在做事情，是整个全局在做事情，从你的网络，从你的应用所在的系统，包括你的数据库，还有包括你应用本身，是要一起来看这件事情的。

很简单的道理，如果你只是去做应用，你不知道网络，那网络结构之间的流量，如果在一个单点出现瓶颈的话，很可能出问题，数据库它能做什么？它是做数据库的运维，如果没有前端应用对技术上的支持可以做到分布式，可以做到水平扩容的话，数据库也没有办法做好。而数据库他要去做什么呢？他为了应用要去保证单点的可容灾，单点的可并发，还有持续提高它底层的一些系统的稳定性，网络的话也要依靠应用，应用也是可以赚钱的，刚才说过，我们在双十一的三天，我们就是减轻整个CDN的流量。

那些流量都是要钱的，所以说真的是一个整体在工作，你不要说你一个作为个人英雄你就可以做完所有的事情。在这2010年我们所有的系统改造都是应用和 DBA，应用和网络一起在做事情，然后真的才能达到一个很好的效果，否则的话是很难去做事情的。经验咱们说了这么多，这个可能只有当你真的交易量提升以后，你才能去体会的。我也很庆幸我能在淘宝，因为只有淘宝现在的流量给我们带来了这么大的挑战，我也学习了很多，我也成长了很多，好，谢谢。

那我们也相信淘宝的整个的技术改造会越来越顺利，他也可以支撑越来越多的交易量。非常感谢伏威接受我们的采访，谢谢。

谢谢。

我现在在杭州的淘宝研发中心，在对康伯做采访。康伯先跟我们大家介绍一下你自己，包括你的团队。

大家好，我是康伯，这是我花名，我的真名叫高山渊。我的团队是负责整个淘宝的CDN的建设、运维。

我们也知道，这一次淘宝“双十一”事件，其实CDN这一块也面临着非常大的压力。我们想了解一下，在这个事件之前，你做了什么样的预案？在整个的事件发生的过程当中，预案和你整个的一个实际的情况有哪些比较大的差异？

我们第一时间知道这个活动的时候，就对我们的系统做过一些评估。当时，我们预计流量会增长大概30%左右。在预案中认为我们的系统是有30%的余量的。但是我们觉得30%是不太够的，我们临时采取了一些措施，比如说去扩了一些性能不太好的一些点、内存，又去到上海又去临时建了一个点，包括在杭州的一些地方，我们都去临时增取了一些资源，把整个系统这个能力扩大到了50%左右。

但是还没有到这天活动的时候，我们就发现我们的这个预案做得不够，活动开始前的一天，流量就已经冲到了一个新的高峰，在这基础上，双十一这天流量就会达到我们当时整个设计的一个顶峰值。如果这样就意味着我们的服务质量可能会下降，可能会放弃一些用户。针对这些情况我们又临时调整了预案，比如说是否要临时的放弃一些用户，或者说再增加一些节点等。

在双十一的一早，我们就发现了，情况比我们预想的还要复杂。当时那天早上九点的时候，我们就发现流量就已经窜高到了整个设计的极限值。按照我们的经验来说，晚上比早上的早高峰还要高30%的，那等于说我们整个系统缺少30%的能力来支撑。我们马上采取了很多措施，最主要的简单说来就是开源节流，当时第一反应就是调动的所有资源投入到CDN系统去，保证它不出问题。当然前面介绍到说我们可能会放弃一些用户，但那是我们到了不得已的时候才采取的措施。事实证明我们当天做完一些措施之后，就没有去用这种极端的措施。那我现在来说一下当时我们主要做些什么：第一个在杭州，我们可以调动资源的地方，及时的去增加资源，这样在晚上高峰来临之前，我们能多余出20G的流量；我们又跟各地的运营商去沟通，因为有些运营商我们跟他签了一个协议，比如说是我们只能跑到10个G，或者更少。但是应对这个突发流量的时候，我们去跟这些运营商沟通，说把我们的带宽的能量打开。实际上很多节点到当天都是跑过了10个G的，最高跑到了16个G，这是在我们以之前不敢想象的。实际上这个能够支撑这么大能量也依赖于我们之前对于服务器、对于整个架构的优化，后边我们可能会说到。

另外一个在业务方面我们采取了一些节流的措施，来保证这些压力不要一下子冲到我们CDN上来，比如说我们的活动页面是非常大的，上面有非常多的大图，我们发现这个活动页面给我们的流量压力带来非常大的冲击。我们就及时找UED的同学去做优化，把页面尽量优化缩小又不影响用户感受。比如说延迟加载，当用户打开页面的时候，先显示首屏的一些图片，底下还有六七屏的图片只有在用户往下拖动的时候才会显示出来，这样我们节省了很大的流量；包括在我们一些上线详情页，也是采取了同样的优化措施，保证用户访问感受的同时，保证我们的CDN不被压跨。

再之后呢，我们发现流量的增长还是比较猛，我们又采取了一些其他的措施，比如说我们临时把某些页面的大图换成小图来节省流量，因为大图原来在CATCH前端都是存在的，如果把它换成小图，就涉及到这些图片可能要全部重新生成一次，对于源服务器的压力是非常大的，我们就采取了逐步切换的方式，先切换一个流量比较小频道，然后上线，观察这个对后端的压力，在看到这样对我们后端基本没有什么太大冲击的情况下，我们再逐步的把一些页面全部换成小图。但是我们仍然在我们的搜索的页面保留了大图的功能，用户在需要看大图的时候，还可以切换到大图，这样一方面节省了CDN的流量，保证我们的服务能力，另一方面也保证我们用户仍能得到一个高质量的访问。

在采取过措施之后，晚高峰的流量也是被我们做过这些控制，还保持跟早高峰差不多。实际上等于我们一天节省了30%左右的流量。但在这个过程中还会有很多问题，因为我们的用户的分布不均匀，比如说在大的省市，流量的增长非常迅速，那为了保证这些地方的一些用户，我们可能会使这些地方的用户访问慢一点，但是我们保证了图片的正常显示；我们让他去访问周边的地方，比如说上海可能会到浙江来，广东的我们会让他去到广西这样的一些措施，然后保证整个访问质量不受太大影响，而且保证了我们的服务能力。

那经过这么多优化措施之后呢，我们那天是整体上是承载了一个比我们平常多了50%的流量，或者说在我们不做那些降级的优化措施的情况下是的80%增长的流量，在这样一个突发的情况下我们做到了。

其实这个事件的背后也是和其他的团队同力协作最终达到一个的结果，假设当初不和UED部门去协作的话，那你可能没有办法把这一块的流量给降下来。另外一个感触就是谢天谢地，总算双十一事件没有出现宕机等情况。那其实根据我们的了解，这也和整个CDN优化团队在过去一年的技术积累是非常相关的？

对，是这样的，在2010年初，我们CDN的流量还是比较小。那到了今天这个流量已经增长了四倍。双十一那天，与年初相比增长了大概六倍左右，这在我们以前是不可想象的。因为面对这样一个增长，可以说是一个爆发。如果我们不做优化，系统可能今天就会出现各种各样的问题，特别是面对双十一这种高压的情况下。

我给大家分享一下，我们在这一年里都做了一些什么样的优化。实际上对于我们整个系统来说，淘宝的CDN可能跟其他公司它的CDN面临的问题不一样，淘宝面临的是一个我们有巨大的商品数，和随之而来的巨大的图片量。这些图片量的访问热度又不像一般的CDN那样非常集中，因为有很多的商品，只有用户访问了十来次，几十次，这样对于CDN本身效果是不太明显的。

我们年初的时候有一个很大的挑战，我们旧的架构下边 CDN的命中率越来越低，最低的时候都已经降到了85%左右。实际上这样的话，带来的难题就是，我们的源服务器和二机CACHE的服务器能力要求非常高，那投入会非常大；另外就是，我们本身是希望CDN能加速用户的访问，但是一旦命中率比较低的时候，大量的回源反而会拖慢整个页面的访问速度，这样是我们不可接受的。

我们采取了一些优化手段：比如说我们原来对于图片的大小是没有预期的，年初我们的CDN开发团队，加上我们运维，对我们的访问做了一些详细分析，分析出到底现在这些图片它是多大，占多大的流量比例，预估了一下，如果我们要求命中率提高到96%、97%，会需要多大的存储空间。之后我们对架构做了一些改变，我们发现我们做到了命中率基本在96%、97%左右，这对于我们整个前端页面的响应速度是一个非常大的提升。

另外一个就是我们在之前用的是Netscaler或者F5这种硬件的这种负载平衡设备。这些硬件负载平衡设备有一个很明显的瓶颈，就是性能可能一般只跑到六个G或者七个G，那就不会再增长了。如果要再增长，就需要再加一套设备，这是一个非常大的投资。

还有一个问题是它们的一些算法有问题，我刚才介绍说，我们有非常多的图片的，在这种情况下，一台机器存的图片量不可能特别多，比如说我们只能存到三千万张图片。但是对于整个淘宝的图片来说，我们有两百亿张。那三千万张对于两百亿张这是很小的一个基数，而且我们又没有热点，那基本上来说这个命中率就降的非常多。那我们怎么应对这个问题？我们就需要做一些七层的URL 哈希的动作，就是说同一份图片我们只存在一台机器上，这样每个节点有30或者40台机器的话，就等于我们有可能存了有12个亿，那我们就占整体量可能有 10%或者20%的图片来提高命中率。

但在这种情况下，硬件的一些算法又会有一些问题，最常见的比如说原来有30台机器，我现在要加10台机器进去扩容的时候，会发现原来所有的图片都失效了，全部要重新去缓存一遍，这对我们是一个非常大的冲击；另外一个情况正好相反，就是说我坏了一台机器时，也会发现同样的问题，这是我们不可接受的。我们的 CDN开发团队就创新性的用了一个软件来解决这个问题，在整个架构中，把硬件负载平衡减掉，去掉了硬件的性能瓶颈，然后用LVS这一套开源的负载均衡来做这个调度，使我们的整个节点的性能一下子提升了一倍。

就像我刚才前面说到的，某一个节点在活动的时候跑到过16G、17G，在这个流量在以前用硬件负载平衡的时候是我们不敢想象也不可能做到的事情。我们用了 LVS之后，在后端又用了一个叫HAproxy的软件，并上面做开发实现了一套，叫做一致性哈希的算法。在这个算法之下，像我前面提到的机器增减的问题都不会影响已有的内容的波动。比如说我们加了机器，它新的Object会到新的机器上去，但是旧的还是会分配到旧的，如果坏了一台机器也是同样的情况，只是坏了的那台机器所存在的Object需要重新去被存储，这就减轻我们整个运维的压力。

我们又做了很多其他的优化，比如说对于HAproxy我们去做客户端的keep alive，也就说长连接来减少用户建立连接的时间，这样平均每个请求可能会减少几百个毫秒，还有一些优化，就是说我们前面说的我们Object非常多，大家都知道，做Cache的时候，实际上很重要的就是命中率的提升。如果说热点相对集中，我们是可以直接把它放在内存里边的，如果内存放不下，我们就会到硬盘上去找。但是传统的硬盘性能非常差，比如说传统的SAS盘，我只能撑到一百多到两百的IOPS。对于整个节点，一两百的IOPS是不能满足要求的。所以我们就引入了SSD，但是SSD的成本又非常高，我们的开发团队发明了一套算法，把那些访问很集中的一些东西放在那个SSD盘上，因为SSD提供很好的一个读性能，我们就让这些80%左左右的这种读从SSD上产生，剩下的图片我们把它放在传统那种SAS或者更低廉的一些SATA盘上，这样我们整个节点的性能非常好，单机可以支撑三千到四千个IO，这是我们系统没有任何显示出访问慢，或者其他不好的表现。

因为每台机器的成本又降得非常低，如果可以，比如说追求一个大的存储，我可以用全SSD，但是我SSD的成本相对要高很多，我可以用比较廉价的SAS或者 SATA来存一些访问频度不是很高的，用SSD存访问频度高的文件，这样整体上的性能就协调的非常好，成本也非常低。整体上可以这么说，我们通过这样一年的优化，在原来硬件基础上投资50%实现了性能是原来两倍的一个架构。现在我们总体的这种TCO是原来的1/4左右。

这个数据还是比较惊人的，在简单回顾一下，在整个优化过程中，有没有遇到特别困难的地方？

特别困难的话，实际上对我们来说，仍然是在这个我刚才提到的，没有热点，数量是非常多的情况。没有热点，就意味着我们要尽量多的把图片存到前端，我们在做 URL哈希的时候，实际上是面临了很大的问题，我刚才也提到SSD，现在的规格只有160G，但是SAS或者SATA可以做到600G或者1T，我们现在每台机器要存大概三千万到四千万的文件，这个对存储容量的要求至少要有一个1T空间，用SSD的话成本会比较高，这是我们一直在优化的方向。另外就是流量这一块。

在接下来的两三年的时间，对于CDN团队来讲，主要的工作可能是什么？

前面我们说到，就说整个一年除了架构以外，我们还做了很多工作。我们流量在涨到可能有四倍到五倍，这个就不光是去优化软件就能实现了，我们还做了很多部署的工作。

下面第一个，我们还是会大力的推进布点的情况。我们现在在全国有30多个点，基本上都分布在一些省会城市，或者说一线城市，比如北京、天津、上海、广州、杭州和其他省会城市。明年我们希望把这个点数量做到100个，这样我们就会覆盖大部分的二线城市，比如说像温州、嘉兴，或者东莞这种流量比较大的城市，后年规模可能会再扩一倍，到两百个点，这当然只是我们现在的一个期望。到时候我们可能说，每一个市我们至少有一个点，当地用户都去访问他本地，达到一个最快的访问速度。

另外一个方面，实际上我们现在在做很多其他内容的CDN尝试，比如动态的或者说HTTPS加速，或者说视频。因为大家知道静态内容，放到每个CDN节点是比较容易的事情，但是我们淘宝的一个业务，整体上所有走交易的流程都是在杭州本地完成的，一些偏远的地区，它到杭州的网络质量还不是特别好，我们希望把这些动态内容也能通过我们的CDN技术去加速，让这些边远的地区也享受到比较快的访问速度； 对于HTTPS的需求，这块我们更多的一些是跟交易相关的流程，我们是希望既享受速度，又享受安全，所以这要就有HTTPS的请求；另外我们现在虽然大力的推广，让卖家把这些图片都放到淘宝本地来，用我们的CDN给卖家提供优质的服务，但是我相信视频还是一个方向，比如说我们去买一件衣服，我们看到有一段视频的话，用户感受跟我去看一个死板的图片，肯定是不一样感受，这也是我们要努力去做到的一个方向。

是不是可以畅想在未来的两三年，我们广大的包括农村地方的，或者三线城市的那些人民，他们购物的时候也会更快？

对，这是我们CDN团队的使命，我们要让全国所有有购物需求的人，在访问淘宝的时候都要最快。

这是非常美好的一个愿景。最后一个问题，在现在淘宝网，当然它的很多方面都走在了前面，包括我们CDN的一些优化，那其他的可能有一些比较小的团队，也在从事电子商务方面的一些工作，也可能有自己的网站，他们也可能面临非常大的问题，你作为一个比较有经验的CDN团队的负责人，能不能给他们提一些建议？

那我大概说一下，这个建议是我的一面之词，实际上对于每一个网站来说，CDN都是有需求的。做CDN的同行，要更多的去关注业务，因为我们很多做技术的人，会限于这个技术的壁垒里面，他只会去考虑技术，不会考虑业务。通过不管是双十一事件，还是说我们整个一年的CDN优化路程来看，我们了解业务是必要的，包括现在我们对有些业务不清楚的地方，也阻碍着我们CDN的发展。业务非常重要，包括我们双十一的时候做的一些措施，比如图片的延时加载，大图换成小图，又保留大图的功能，这样都是在非常熟悉业务的情况下做出的一个决定。

如果我们不熟悉这些业务，我们当天肯定做不出这些决定来，没法应付这么大的流量；另外你了解了业务，你才能够去做好你的CDN，让你的CDN发挥最大的用途，你知道你的业务需要什么样的CDN；另外一个希望我们淘宝的CDN以后可以为大家服务，我这打个广告，淘宝的CDN现在具备给其他网站提供服务的能力，那我们希望把淘宝的先进技术开源一部分到社区去，我们前面提到的一致性哈希的算法，或者说对于HAproxy的改进，我们都会开源到社区去，希望同行业会用到这些技术。另外一个我们会大力的去建点，我们也希望，到时候我们可以跟这些网站合作，让他们把一些内容放到我们这边来服务。

非常感谢康伯接受我们的采访，我们也希望CDN团队能够再接再厉，给我们广大的网民提供更流畅的服务。

谢谢。