软件产品|从12306看海量并发网站架构

TUP第19期综述:从12306看海量并发网站架构(含PPT下载) 发表于 2012-02-20 20:27|19643次阅读| 来源 CSDN专稿| 28 条评论| 作者 付江 高并发 产品设计 新浪微博 tup 大数据 摘要:2月18日CSDN和《程序员》杂志举办了 CSDN TUP技术沙龙 第19期:大数据系列研讨会之从12306谈起。本次活动分上下午两部分组成,上午是小规模专家研讨会,下午是开放式的主题演讲。 [CSDN.NET 付江/文] 2月18日CSDN和《程序员》杂志举办了CSDN TUP技术沙龙第19期:大数据系列研讨会之“从12306谈起”。本次活动邀请到了以下嘉宾,请他们分享对大数据处理和高并发互联网架构设计的理解。

  • 百度(移动?云计算)首席架构师 林仕鼎
  • 淘宝产品技术交易平台部/双11技术保障负责人 伏威(唐勇)
  • 新浪网首席DBA 杨海朝
  • 土豆网技术副总裁 黄冬
  • 美团网联合创始人/技术总监 穆荣均
  • 凡客诚品无线事业部副总经理 栾义来
  • 搜狗搜索事业部总经理 茹立云
  • 美国卡内基梅隆计算机机器人专业博士/云计算创业人 邓侃
  • 百度分布式高级研发工程师 杨栋
  • 腾讯SOSO资深架构师 陈明
  • 友友系统CEO 姚宏宇、COO/副总经理 张矩
  • Sybase亚太区市场总监 陶欣、市场经理 张策
【软件产品|从12306看海量并发网站架构】之所以组织这次活动,还是缘起于技术界在春运期间铁道部订票网站12306.cn出现的诸多问题的热议。(CSDN当时上线的两个专题 【从铁路订票系统看高并发网站技术解决之道】、【如果由我来设计12306.cn】也都收到了大量的反馈和回复)。
大数据、海量用户的互联网服务能力、大型网站面对高负载和并发的解决之道,一直以来都是全世界公认的技术难题。有时候,在某些特别时期,即使是一些看似业务逻辑简单的应用在面对突发起来的高负载和高增长的情况下,如何承载住巨大访问量也是一种巨大的挑战。12306.cn就是最好的例证。

活动分上下午两部分举行,上午是专家圆桌研讨会,下午是开放式主题演讲。本文简单总结了当天活动内容并提供了演讲资料下载:架构设计的一些思考、企业私有云及其系统架构、实践、实战 从双11说起更多图文报道请查看【大数据系列研讨会之“从12306谈起”专题】。
在上午的专家圆桌研讨会上,围绕着铁路购票系统的历史包袱、互联网版本化后的问题、12306.cn在遭遇海量并发访问时如何“维持次序”、在遇到请求尖峰时、普通模型达到性能瓶颈引起雪崩效应后的紧急处理措施和建议,来自于国内顶级互联网公司的实战专家和12306相关方的代表在现场进行了激烈的讨论(没错!是激烈的讨论!),并给出了务实的建议。

专家圆桌研讨会(专家激烈讨论内容稍后单独呈现 敬请关注)
林仕鼎:架构设计的一些思考
林仕鼎在演讲中就系统架构中基本的存储、分布式技术、服务架构以及计算模型进行了分析,并分享了当架构师的经验。林仕鼎谈到的内容点包括:
  • 高并发网站存储、分布式、服务架构、模型实例
  • 存储架构设计的四大注意事项:结构、数据特点、访问模式、接口性质
  • 不同访问模式对系统带来的影响和应对方法
  • 存储模型B + tree和Log-based structure的选择
  • 分布式设计中扩容和容错的处理(Partition和Replication)
  • 给定系统资源情况下最大请求数的设计技巧
  • 计算模型(数据密集型、计算密集型、通讯密集型)的选择
  • 架构师三板斧
林仕鼎认为,在给定系统资源情况下,所能提供的最大请求数,需要做一个特别设计,以防请求数突破极限值。如果没有做特别设计,在极端情况下,吞吐量超过一个点,整个系统将崩溃。而服务架构的目标包括系统高吞吐能力和在极限压力下的稳定输出。为了保证整个系统的稳定性,在设计时需要注意:减小资源分配粒度、主动调度、Flow Control(负载反馈,Throttling、延迟截断)。
与会的美团网联合创始人、技术总监穆荣均在现场听过林仕鼎的演讲后甚至感言:这是我见过的对基础架构设计最系统、也最精炼的阐述。
伏威:实践、实战 从双11说起
第二个演讲者伏威供职于淘宝产品技术-交易平台,负责行业市场的开发,加入淘宝4年,负责过交易、用户、商品等等核心系统的开发工作。在2009、2010、2011年 三年负责淘宝双11以及2011年双12活动的技术保障工作。他在演讲中重点谈到了:
  • 淘宝对双11的技术准备
  • 淘宝双11的经验
  • 淘宝技术团队的积累和磨练历程
  • 针对大数据、高并发网站的注意事项
  • 对12306.cn的解决方案建议
伏威认为双11项目给淘宝技术团队的经验包括:享受简单 拥抱粗暴、避免过度设计、绝不为半年后做设计、先解决问题、容灾报警数据监控要在设计时考虑、魔鬼都在细节里、系统做的好就是:死的比别人晚、恢复比别人快、开源软件可掌控。对于每一项经验,伏威都列举了实战中的经历做解释。此外,对铁路订票系统12306.cn 伏威给出了自己设计的解决方案【查看框架图】
邓侃:企业私有云及其系统架构
邓侃从云计算的角度解析了12306.cn的问题。他在演讲中重点分享了:
  • 模块 vs. 服务:SOA系统架构
  • 云计算与系统三段论
  • 如何从传统 IT 系统向私有云迁移
  • 向云计算平台搬家的四大步骤
  • 云迁移的三种搬家模式
  • 渐进式部分搬家模式

从左到右分别为:林仕鼎、伏威、邓侃、刘江
互动环节,主持人刘江其中一个问题问到嘉宾对非关系型数据库NoSQL的看法。
伏威:淘宝用NoSQL做过项目,那是一个大坑,幸好当时是一个小系统在尝试。
林仕鼎:目前在百度内部来说,除了商业的交易,用SQL的地方不多。就算用SQL查询,用户的关键操作其实还是用别的方式解决。从整个公司在存储方面的技术投入来看,SQL的比例不大。 百度有好几个存储系统,未来希望这些能够统一发展。
伏威:对大规模数据存储,我们特别强调能轻易的水平扩展,加机器能够解决问题。因为要解决两个问题,第一个是查询,第二个是计算。计算可能非实时,那查询非常强调实时。还是要看业务特征是什么,解决什么问题。
邓侃:NoSQL是一种反动,是一种倒退,是一种复辟。为什么?两个原因,第一个原因说SQL为什么不是2.5,它是描述用户需求,而不用描述操作过程。Java也好,它是描述过程的语言。所以拿到SQL语言,第一件事做解析,第二件事做深层执行的过程,就是把你的目标描述翻译成执行的过程。

新浪首席DBA 杨海朝
现场的新浪首席DBA杨海朝【备注:新浪网包括新浪微博在内的大量产品应用了Redis技术(全球最大规模的应用案例)】也发表了看法:两者之间是互相补充关系,新浪有很多业务在逐步弱化关系型(数据库)。包括设计大应用的时候,也是优先考虑NoSQL。不能用的时候再去用关系型。新浪这样用是有历史原因的,互联网产品开发比较快速,功能需要快速上线。用完以后发现有很多坑,现在基本上踩完了。
更多的时候其实都是在把NoSQL跟SQL合在一起,减少应用复杂度。到底用NoSQL还是SQL,还是要看应用场景,只能选择合适的,不是说哪个更好。我们一部分存进去是关系型,取的时候可能会用RDS做后面。就是关系数据库里面最终转化结果储存。业务对数据不同渲染,加快业务体验。

活动现场 付江/摄
互动环节过程中,与会者还问到了Hadoop在中小企业的应用及趋势、Hadoop之外海量处理开源技术的选择、虚拟化技术的比较、架构师如何应对架构决策在受到公司业务的冲击、12306.cn架构设计缺陷等一系列热点话题。
本次活动原计划人数200人,结果有超过500多人报名,由于场地限制,只能电话确认300人左右到场。在现场,我们还看到了来自于CNTV的高级软件架构师刘亮、京东商城高级软件架构师商雨、Yahoo!北京研发中心高级软件工程师杨军、公安部第一研究所部门经理张涛、中国电力科学研究院高级软件工程师张晓博、Masamaso高级软件架构师左远、航天信息股份有限公司贺易、中国人民银行软件开发中心数据库资深DBA刘胜涛.....大数据依然是今年的热点话题!
演讲PPT下载:架构设计的一些思考、企业私有云及其系统架构
实践、实战 从双11说起

什么是TUP?
Technology 技术
User Experience 用户体验
Product 产品
分享产品背后的技术和用户体验故事
TUP是由全球最大的中文IT技术社区CSDN和最具影响力的IT技术期刊《程序员》发起组织的线下活动,以业界知名专家讲座和论坛形式在北京、上海等主要城市定期举行,主要针对IT产品研发相关的技术、设计、运营、运维、管理专业人士,目的是与技术界人士共同关注IT产品研发背后的成败经验,关注技术、用户体验和产品设计,信仰开放、创新、交流和社区。

    推荐阅读