淘宝双十一架构优化及应急预案

标签: 淘宝 双十一 架构 | 发表时间:2013-01-10 17:31 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

 每年的双十一,在整体架构上最依仗的是过去几年持续建设的稳定的服务化技术体系和去IOE带来整体的扩展性和成本的控制能力。

今年在架构上做的比较大的优化有三点:

第一是导购系统的静态化改造。今年淘宝和天猫都分别根据自身的业务特性进行了Detail页面的静态化改造,但核心的思路都是通过CDN+nginx+JBoss+缓存的架构,将页面信息进行静态化缓存。这次的优化突破了现有系统在Web服务器和Java处理信息的CPU瓶颈,将访问最密集的Detail集群的性能提升了10多倍,极大程度的缓解了突发流量场景下的性能和成本压力。在今年的阿里技术嘉年华上,淘宝Detail团队的君山分享了淘宝静态化改造的一些经验。后续我们也可以安排天猫Detail团队的同学分享下在不同的业务背景下技术选型的思考。

第二是天猫优惠系统的架构改造,整体上的思路是规则中心化计算本地化。简单来说,将优惠规则的计算推送到所有需要展现价格的上层业务系统进行,而不再集中在后端进行处理。通过这样的方式减少了分布式的调用和计算单点的瓶颈问题。

第三是支付核心路径的异步化。支付环节的系统瓶颈一直在于后端的银行系统吞吐率无法跟上支付宝的处理能力,大量的线程阻塞等待银行系统的返回。今年支付宝的同学们通过一个高可用的队列,异步处理对关键支付路径的调用,这样做的好处一方面让支付系统的处理资源得到了释放,最大化系统处理能力,另一方面也支撑了更加灵活的限流控制。

有了以上的基础,接下来就是对突发情况的应急预案准备了,我们的做法通常有两种:

一是业务降级,即舍弃一些非核心的业务,确保核心业务的系统资源和稳定运行。举个例子,天猫的美妆类目交易流程有个特性,购买部分商家的商品会附赠小样。这部分逻辑是会给核心交易系统增加额外的系统依赖的,如果大促出现紧急情况,我们就会考虑砍掉这部分特殊的逻辑,确保核心交易的稳定。

二是系统限流,关键服务进行限流控制,保护核心集群的系统稳定。

这两点看似简单,却对系统和代码段之间的耦合性要求极高,我们前期也做了大量的工作尽可能将系统之间的强依赖变为弱依赖,避免因为某一系统的性能下降导致反向的雪崩效应。

另一方面,对于限流的阈值评估同样是一个难点,我们首先要从根据历年来的业务变化数据和运营计划估算一个可能达到的交易额以及UV数量。然后计算我们可能达到的交易笔数和访问峰值。

其次,分析出每笔交易需要跟多少个系统进行交互,计算出每笔交易会对后端的商品中心,用户中心,库存中心,优惠,物流等要调用多少次,得出一个支撑一次访问或是一笔交易的合理系统消耗公式。再次,通过线上压测的手段对线上各个集群的极限能力有个准确的认知。

最后再根据业务峰值、系统消耗公式、压测数据,去准备扩容的机器数量和限流的具体阀值。

今年是双十一准备的最为充分的一年,前期的功能测试、容量评估、应急预案都比以往做的更加仔细,一共400多个应急预案,从9月开始就不断的进行系统演练,确保每个应急预案的准确和便捷执行。所以整的来说,当天各个系统表现还是比较淡定的。

突发事件虽然也有发生,还是做到了冷静处理,所有情况都在掌控之中。 当然,无论是限流还是降级,都是以牺牲用户体验作为代价的,我们内部也在反思和讨论,以后可以把流控做的更加有趣些,让大家买的开心,等的不无聊。

贾国清 是InfoQ中文站高级策划编辑,热爱生活,喜欢旅游和体育运动。

您可能也会喜欢

相关 [淘宝 双十一 架构] 推荐:

淘宝双十一架构优化及应急预案

- - InfoQ cn
 每年的双十一,在整体架构上最依仗的是过去几年持续建设的稳定的服务化技术体系和去IOE带来整体的扩展性和成本的控制能力. 今年在架构上做的比较大的优化有三点:. 第一是导购系统的静态化改造. 今年淘宝和天猫都分别根据自身的业务特性进行了Detail页面的静态化改造,但核心的思路都是通过CDN+nginx+JBoss+缓存的架构,将页面信息进行静态化缓存.

逃不掉的双十一 可怕的分布式架构隐患

- - 博客园_知识库
  在刚刚过去的双十一,淘宝怒斩 571 亿交易额,成为年度的最大赢家. 负责本次双十一技术服务的蚂蚁金服集团表示:双十一的交易峰值已经达到 285 万笔/分钟,相比去年双十一期间 79 万笔/分钟的交易峰值,今年系统的支撑能力达到了去年 3 倍以上,用户整体支付体验相比去年也顺畅不了不少. 从网友反馈的实际体验来说,今年双十一相比往年的确有了不小的提升,页面打开的速度更快了,支付等待时间更短了,优惠力度更给力了…… 但是有没有问题?有,而且这些问题从某种意义上讲则是致命的.

淘宝网架构分享总结 - 架构,分布式,淘宝,虚拟化,水平伸缩

- - 互联网 - ITeye博客
关键字:淘宝网架构分享总结 - 架构,分布式,淘宝,虚拟化,水平伸缩. 一场由淘宝的架构师,曾宪杰先生主讲的淘宝网架构分享. 一、为什么stateless比较有利于实现水平伸缩. 关于什么是stateless的扫盲,见这个贴: http://kyfxbl.iteye.com/blog/1831869.

淘宝数据魔方技术架构解析

- 狗尾草 - 淘宝数据平台与产品部官方博客 tbdata.org
(本文首发于《程序员》8月刊,略有调整. 你可通过pengchun#taobao.com联系到作者. 淘宝网拥有国内最具商业价值的海量数据. 截至当前,每天有超过30亿的店铺、商品浏览记录,10亿在线商品数,上千万的成交、收藏和评价数据. 如何从这些数据中挖掘出真正的商业价值,进而帮助淘宝、商家进行企业的数据化运营,帮助消费者进行理性的购物决策,是淘宝数据平台与产品部的使命.

架构师接龙:金山张宴VS.淘宝岑文初

- Alex - 《程序员》杂志官网
主持人:冯大辉,现任丁香园 (http://www.dxy.cn)网站CTO. 曾历任支付宝架构师、数据库团队负责人等职. 张宴:在项目的架构设计中,对于未来可能发生的需求变更,你是如何考虑的. 岑文初:需求变更可以分为业务性和非业务性两类. 对于业务性需求变更,思维方式应当按如下顺序进行:. 第一,是否已经有类似功能,需要做些改进就可以满足需求;.

淘宝的可伸缩高性能互联网架构

- 浪客 - 博客园-首页原创精华区
一 应用无状态(淘宝session框架).          假如在session中保存了大量与客户端的状态信息,保存状态信息的server宕机时.          通常通过集群解决,不仅有负载均衡,更重要的是要有失效恢复failover.          tomcat用集群节点广播复制,jboss用配对复制等session状态复制策略,但严重影响系统的伸缩性,不能通过增加更多的机器达到良好的水平伸缩.

淘宝海量数据产品的技术架构 - Mainz

- - 博客园_Mainz's Blog
淘宝海量数据产品的技术架构是什么,又是如何应对双十一的海量访问的. 按照数据的流向来划分,我们把淘宝数据产品的技术架构分为五层(如图1所示),分别是数据源、计算层、存储层、查询层和产品层. 位于架构顶端的是我们的数据来源层,这里有淘宝主站的用户、店铺、商品和交易等数据库,还有用户的浏览、搜索等行为日志等.

淘宝应对"双11"的技术架构分析

- - 博客园_知识库
  双“11”最热门的话题是TB ,最近正好和阿里的一个朋友聊淘宝的技术架构,发现很多有意思的地方,分享一下他们的解析资料:.   淘宝海量数据产品技术架构.   数据产品的一个最大特点是数据的非实时写入,正因为如此,我们可以认为,在一定的时间段内,整个系统的数据是只读的. 这为我们设计缓存奠定了非常重要的基础.