双十一事件双十二事件
比如说那天,我们大家现在都知道确认收货是被停掉的,大概是下午四点多,五点左右被停掉的,为什么?就是为了应对高峰期的压力,这些预案都基本上起作用了。而之前我们在系统设计的时候,其实这种降级的服务方案,我们都已经放进去了,在那一天就得到了验证。还有些东西是我们没有办法预估的,包括,那天用户疯狂的涌进对我们整个CDN的流量的压力,因为我们平时CDN流量可能是一,但是那天翻到了三,这种200%、300%的增长,对我们整个的体系都是一个很大的冲击。而CDN的布局你是没有办法临时去扩容的,不像我们应用服务器,你可以临时去加机器,它是很难做到的,这时候我们的网络服务团队和应用团队其实是在一起去解决这个问题,不是单方面的努力,而是我们应用和运维团队一起去把整个流量降低下来了。那我们感觉很庆幸,就是那天到晚上,我们之前做过的很多预案都起了作用,到最后才平稳的支撑过了晚上整个的交易高峰期。
这时候我们就开始紧急设计各种各样的预案,在那天能够生效的预案,包括为了降低CDN的压力,我们在应用上要做得分析。当时我们的一些核心数据库也报出来有些风险,因为200%的增量,这个在平时我们不可想象的。这时候我们要去做哪些服务的降级,要停掉哪些在比如说DBS,数据库操作层面的一些东西,让整个数据库的支撑量会更大。那时候我们都开始做,那到下午三四点的时候,那时候紧张达到了顶点,因为我们不知道下午和晚上会发生什么。当时我们可以做得事情我们全都已经去做了。那到晚上九点、十点的时候,我们发现我们支撑过那个压力以后心情慢慢放松了。当时我们头天还在考虑说,双十一活动对吧,半价,我们要去抢购什么商品,在九点十点之前我们从来没有那个心情去做抢购,然后到十点以后,这时候我们才开始放松下来,可以去采购一些商品,为自己买东西。那时候好东西都被抢光了,真的是没办法。因为最后运营才告诉我,真的是只要有好东西上去就疯抢,好东西上去就疯抢,我们最后意思意思买了一些不打折的商品,以支持淘宝的交易额。
所以说整个心态就从一个很稳定,就是觉得放心、放松、没事情到紧张,然后到紧张到高峰,然后最后再下来,就是好像坐了一个过山车。而那个过山车绝对不是说你能预估到的。这种心态的变化对于我们来说还是蛮有挑战性的。而且我之前接受我们内部的采访的时候告诉他们,我说我们是希望双十一平平静静、安安定定,我们的技术人员是不要出面的,你们不要意识到我们存在。开心的是我们那天我们露面了,我们去,真的是为这次活动做出了很大的贡献。然后不安的地方是呢,希望下次不要这样,我们真的就希望暴风雨在淘宝是无声无息的,你每个会员可以开开心心的采购商品,你不要意识到后台我们技术做了什么,也不希望有任何功能去做了降级,比如说确认收货你不能确实收货,而这种事情发生是我们不希望的,所以说既开心又感觉到有点失落,我们还是没有做到无声无息,其实我觉得最大的成就应该在于无声无息。
其实大家只看到说我们那一天,比如说在CDN上做了很多文章,就是为支付宝做了很多事情,但是还有很多更关键的系统,比如说我们的交易详情的页面,商品详情的页面,商品详情页面比平时的压力直接打破了三倍。如果没有我们今年,就是连续三次大型的优化是根本就实现不了的,而我们的优化是什么?我们从直接提升了它的性能的700%,也就是说我们有信心,在双十一高峰期再增长50%到80%的情况下,我们的商品详情页面依然撑得住,还有包括我们的,交易数据库今年做了拆分和读写分离,它直接的系统能力在双十一的基础上还可以再上浮很多。那如果没有这些的话,我们那天根本就支撑不住;还有就是对用户信息访问这种 UIC(User Interface Center),当时我们产生了上百亿的内部的访问请求,就是这种系统的压力,如果不是我们做了整个读写分离的优化,以及就是通过MySQL,让我们的系统可以水平的扩展,我们也是支撑不了的。
所以说我感觉庆幸是,感觉开心的是我们的执行力和我们技术团队的工作,我感觉后怕以及庆幸的是我们做了这些技术改造和优化,让我们双十一可以支撑过去,让我们的那些技术的预案有所作为,否则的话就是做无可做了。
而我们淘宝现在就在这个细节上面已经融入到了我们的设计当中。可能在采访范禹的时候他也会讲到我们淘宝的几个大型系统的一个技术型改造的一个活动,那在这个中间,我们就已经做到了,这种水平的大型改造,我们已做到无声无息,就是我称之为没有新闻就是最好的新闻。就是可能在你上层结构都还不知道情况下,我大型改造都已经完成了,所以说这种细节还是非常关键和至关重要的。所以说降级和容灾只是这些系统中间的一个部分,那只是说,在我们为了应付双十一的这种大流量的并发的情况下,我们在这上面表现的比较关键而已,起的作用会比较大一点,但实际上还有更多的细节。
而且在淘宝另外一个经验是什么呢?我们每年的增长是200%,那你的技术的增长也必须在200%以上,你才能保证能支撑住这么大的增长量。它如果出现高峰期,远远会超过200%,所以说建议大家每半年Review一下自己的系统,以保证你将来200% 的量是可以支撑得住的。现在淘宝,我说句不太好听的话,我们每半年如果系统没有经过Review,没有经过大型的改造,它在下一个半年可能就会出问题。就是我们对大型的结构,几乎持续的在改动,才能支撑这个量。另外一个就是双十一的经验,这么大规模的量的增长,不是你开发在做事情,也不是数据库在做事情,是整个全局在做事情,从你的网络,从你的应用所在的系统,包括你的数据库,还有包括你应用本身,是要一起来看这件事情的。
很简单的道理,如果你只是去做应用,你不知道网络,那网络结构之间的流量,如果在一个单点出现瓶颈的话,很可能出问题,数据库它能做什么?它是做数据库的运维,如果没有前端应用对技术上的支持可以做到分布式,可以做到水平扩容的话,数据库也没有办法做好。而数据库他要去做什么呢?他为了应用要去保证单点的可容灾,单点的可并发,还有持续提高它底层的一些系统的稳定性,网络的话也要依靠应用,应用也是可以赚钱的,刚才说过,我们在双十一的三天,我们就是减轻整个CDN的流量。
那些流量都是要钱的,所以说真的是一个整体在工作,你不要说你一个作为个人英雄你就可以做完所有的事情。在这2010年我们所有的系统改造都是应用和 DBA,应用和网络一起在做事情,然后真的才能达到一个很好的效果,否则的话是很难去做事情的。经验咱们说了这么多,这个可能只有当你真的交易量提升以后,你才能去体会的。我也很庆幸我能在淘宝,因为只有淘宝现在的流量给我们带来了这么大的挑战,我也学习了很多,我也成长了很多,好,谢谢。
但是还没有到这天活动的时候,我们就发现我们的这个预案做得不够,活动开始前的一天,流量就已经冲到了一个新的高峰,在这基础上,双十一这天流量就会达到我们当时整个设计的一个顶峰值。如果这样就意味着我们的服务质量可能会下降,可能会放弃一些用户。针对这些情况我们又临时调整了预案,比如说是否要临时的放弃一些用户,或者说再增加一些节点等。
在双十一的一早,我们就发现了,情况比我们预想的还要复杂。当时那天早上九点的时候,我们就发现流量就已经窜高到了整个设计的极限值。按照我们的经验来说,晚上比早上的早高峰还要高30%的,那等于说我们整个系统缺少30%的能力来支撑。我们马上采取了很多措施,最主要的简单说来就是开源节流,当时第一反应就是调动的所有资源投入到CDN系统去,保证它不出问题。当然前面介绍到说我们可能会放弃一些用户,但那是我们到了不得已的时候才采取的措施。事实证明我们当天做完一些措施之后,就没有去用这种极端的措施。那我现在来说一下当时我们主要做些什么:第一个在杭州,我们可以调动资源的地方,及时的去增加资源,这样在晚上高峰来临之前,我们能多余出20G的流量;我们又跟各地的运营商去沟通,因为有些运营商我们跟他签了一个协议,比如说是我们只能跑到10个G,或者更少。但是应对这个突发流量的时候,我们去跟这些运营商沟通,说把我们的带宽的能量打开。实际上很多节点到当天都是跑过了10个G的,最高跑到了16个G,这是在我们以之前不敢想象的。实际上这个能够支撑这么大能量也依赖于我们之前对于服务器、对于整个架构的优化,后边我们可能会说到。
另外一个在业务方面我们采取了一些节流的措施,来保证这些压力不要一下子冲到我们CDN上来,比如说我们的活动页面是非常大的,上面有非常多的大图,我们发现这个活动页面给我们的流量压力带来非常大的冲击。我们就及时找UED的同学去做优化,把页面尽量优化缩小又不影响用户感受。比如说延迟加载,当用户打开页面的时候,先显示首屏的一些图片,底下还有六七屏的图片只有在用户往下拖动的时候才会显示出来,这样我们节省了很大的流量;包括在我们一些上线详情页,也是采取了同样的优化措施,保证用户访问感受的同时,保证我们的CDN不被压跨。
再之后呢,我们发现流量的增长还是比较猛,我们又采取了一些其他的措施,比如说我们临时把某些页面的大图换成小图来节省流量,因为大图原来在CATCH前端都是存在的,如果把它换成小图,就涉及到这些图片可能要全部重新生成一次,对于源服务器的压力是非常大的,我们就采取了逐步切换的方式,先切换一个流量比较小频道,然后上线,观察这个对后端的压力,在看到这样对我们后端基本没有什么太大冲击的情况下,我们再逐步的把一些页面全部换成小图。但是我们仍然在我们的搜索的页面保留了大图的功能,用户在需要看大图的时候,还可以切换到大图,这样一方面节省了CDN的流量,保证我们的服务能力,另一方面也保证我们用户仍能得到一个高质量的访问。
在采取过措施之后,晚高峰的流量也是被我们做过这些控制,还保持跟早高峰差不多。实际上等于我们一天节省了30%左右的流量。但在这个过程中还会有很多问题,因为我们的用户的分布不均匀,比如说在大的省市,流量的增长非常迅速,那为了保证这些地方的一些用户,我们可能会使这些地方的用户访问慢一点,但是我们保证了图片的正常显示;我们让他去访问周边的地方,比如说上海可能会到浙江来,广东的我们会让他去到广西这样的一些措施,然后保证整个访问质量不受太大影响,而且保证了我们的服务能力。
那经过这么多优化措施之后呢,我们那天是整体上是承载了一个比我们平常多了50%的流量,或者说在我们不做那些降级的优化措施的情况下是的80%增长的流量,在这样一个突发的情况下我们做到了。
我给大家分享一下,我们在这一年里都做了一些什么样的优化。实际上对于我们整个系统来说,淘宝的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左右。
下面第一个,我们还是会大力的推进布点的情况。我们现在在全国有30多个点,基本上都分布在一些省会城市,或者说一线城市,比如北京、天津、上海、广州、杭州和其他省会城市。明年我们希望把这个点数量做到100个,这样我们就会覆盖大部分的二线城市,比如说像温州、嘉兴,或者东莞这种流量比较大的城市,后年规模可能会再扩一倍,到两百个点,这当然只是我们现在的一个期望。到时候我们可能说,每一个市我们至少有一个点,当地用户都去访问他本地,达到一个最快的访问速度。
另外一个方面,实际上我们现在在做很多其他内容的CDN尝试,比如动态的或者说HTTPS加速,或者说视频。因为大家知道静态内容,放到每个CDN节点是比较容易的事情,但是我们淘宝的一个业务,整体上所有走交易的流程都是在杭州本地完成的,一些偏远的地区,它到杭州的网络质量还不是特别好,我们希望把这些动态内容也能通过我们的CDN技术去加速,让这些边远的地区也享受到比较快的访问速度; 对于HTTPS的需求,这块我们更多的一些是跟交易相关的流程,我们是希望既享受速度,又享受安全,所以这要就有HTTPS的请求;另外我们现在虽然大力的推广,让卖家把这些图片都放到淘宝本地来,用我们的CDN给卖家提供优质的服务,但是我相信视频还是一个方向,比如说我们去买一件衣服,我们看到有一段视频的话,用户感受跟我去看一个死板的图片,肯定是不一样感受,这也是我们要努力去做到的一个方向。
如果我们不熟悉这些业务,我们当天肯定做不出这些决定来,没法应付这么大的流量;另外你了解了业务,你才能够去做好你的CDN,让你的CDN发挥最大的用途,你知道你的业务需要什么样的CDN;另外一个希望我们淘宝的CDN以后可以为大家服务,我这打个广告,淘宝的CDN现在具备给其他网站提供服务的能力,那我们希望把淘宝的先进技术开源一部分到社区去,我们前面提到的一致性哈希的算法,或者说对于HAproxy的改进,我们都会开源到社区去,希望同行业会用到这些技术。另外一个我们会大力的去建点,我们也希望,到时候我们可以跟这些网站合作,让他们把一些内容放到我们这边来服务。
转载于:https://www.cnblogs.com/jackssy/archive/2012/01/20/2327958.html
双十一事件双十二事件相关推荐
- C#事件-使用事件需要的步骤
事件是C#中另一高级概念,使用方法和委托相关.奥运会参加百米的田径运动员听到枪声,比赛立即进行.其中枪声是事件,而运动员比赛就是这个事件发生后的动作.不参加该项比赛的人对枪声没有反应. 从程序员的角度 ...
- 事件流--事件冒泡现象及阻止
事件冒泡现象 <!DOCTYPE html> <html lang="en"> <head><meta charset="UTF ...
- 用户表单事件(focus事件)
以前做用户系统的时候经常用到表单验证,正则表达式事件来处理和绑定事件和进行事件,这里说的其实只是一小部分,也不是很值得写,但是今天遇到了还是写一下,毕竟基础还是蛮重要的,就算懂的童鞋,巩固一下也是好的 ...
- 探索.NET中事件机制(续)——虚事件和事件重写问题,微软的Bug?!
上一篇写到了微软经典的事件处理机制是通过EventHandlerList方式进行事件保存并且处理的.本节讲一个奇怪的问题--虚事件和事件重写问题(具体提问在:http://social.msdn.mi ...
- 从零开始学习jQuery (五) 事件与事件对象【转】
一.摘要 事件是脚本编程的灵魂. 所以本章内容也是jQuery学习的重点. 本文将对jQuery中的事件处理以及事件对象进行详细的讲解. 二.前言 本篇文章是至今为止本系列内容最多的一篇, 足以可见其 ...
- 事件——事件绑定||事件函数传参||事件修饰符||按键修饰符||自定义按键修饰符
事件绑定 <!DOCTYPE html> <html lang="en"><head><meta charset="UTF-8& ...
- 从零开始学习jQuery (五) 事件与事件对象
本系列文章导航 从零开始学习jQuery (一) 开天辟地入门篇 从零开始学习jQuery (二) 万能的选择器 从零开始学习jQuery (三) 管理jQuery包装集 从零开始学习jQuery ( ...
- C#中怎样跨窗体调用事件-从事件订阅实例入手
场景 C#中委托与事件的使用-以Winform中跨窗体传值为例: https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/100150700 ...
- 手写简版spring --10--容器事件和事件监听器
一.降低耦合 解耦场景在互联网开发的设计中使用的也是非常频繁,如:这里需要一个注册完成事件推送消息.用户下单我会发送一个MQ.收到我的支付消息就可以发货了等等,都是依靠事件订阅和发布以及MQ消息这样的 ...
最新文章
- 【收藏】推荐系列:2008年第08期 总10期
- Python 实现斐波那契数列
- Java ==和Equals方法的比较
- 常用数据库优化方案(五)
- PowerBuilder GRID美化
- 从本科到研究生,看大疆工程师给你定制的机器人学习计划
- 微信开发之百度地图API学习(一)
- java 背单词系统_基于JAVA模拟背单词系统(含源文件)
- AMS1117稳压芯片介绍
- 多校9 HDU-6164 Dying Light 几何数学
- leach协议c++代码_leach和leach-c协议仿真
- 美通企业日报 | 广州塔开业至今迎游客近1557万人次;居然之家成功借壳上市
- 剑侠世界职业优缺点简介
- 智慧城市产业热点板块及产业图谱
- redis常用命令 (查询出所有的商品,并返回json给客户端)redis之路(八)
- 如何进行滤波器设计软件选择
- java小游戏贪吃蛇
- 万马爱充工商变更:李刚任法定代表人、总经理,曾为特来电副总裁
- 第十五期】Monica:单身滴美女程序员 多图!
- python 高斯白噪声-python高斯白噪声
热门文章
- python爬虫-模拟登陆新浪微+博爬取感兴趣人的所有信息
- 建表原则——参照完整性
- 影驰H610MK主板在MBR硬盘上安装系统(可用于安装WIN7)
- python的linux电脑上图标不见了怎么办_桌面的图标不见了怎么恢复 桌面图标消失回复方法【图文】...
- linux 查看 管道文件,linux 查看文件和管道命令
- 数码管显示实验(一)(初步明白片选、段选)
- C语言变量的分类(C语言六)
- 3DMAX在2K显示器字体小的解决办法
- 微信 ipad sdk分享
- 平板电脑安装鸿蒙OS,预装鸿蒙OS!华为MatePad Pro2入网:搭载麒麟9000