透过12306五大焦点看高性能高并发系统
幽云十八 发表于:12年02月20日 09:46 [转载] IT168
焦点二:类似12306的海量高并发系统与新浪、淘宝有何不同?
2011年在IT业内是一个很热火的一年,云计算、大数据以及Hadoop等概念铺天盖地袭来,并有诸如淘宝、人人网、即刻搜索以及 Facebook等许多率先实践Hadoop的技术人员来分享应用经验。从表面看来,类似12306的高性能高并发系统与Facebook、微博以及淘宝 节假日抢购活动非常类似,并且,淘宝、新浪以及Facebook等都在这一块做得非常的好。那么他们的经验是否可以借鉴呢?
这一问题刚一抛出,就引起诸多的网友的关注,很多人认为,12306完全可以借鉴这些先进公司的经验。但也有网友认为,这其间还是存在本质的区别。在2011年的“掘宝Hadoop—— 中国云计算大会”上的“大数据”分论坛中,在Facebook公司专注于大数据的邵铮曾就Facebook的数据处理分享了相关的经验。Facebook 的瞬间并发最大的特点就是写操作非常频繁,而Facebook的解决之道则在于通过利用HBase写速度快的特点来构建数据库(据邵铮的说法是HBase 在读取上并不尽如人意),并对整个架构进行优化来达到缩短时间的目的,微博跟Facebook在本质上差不太多。而对于12306而言,在前面已经说到,其实质上应当属于频繁的混合读写操作,而且是小随机频繁读写,这在业内是公认的难题。
那么Facebook等新兴SNS社区的经验无法借鉴,那么淘宝的经验可应用于12306之上吗?比较看起来,他们都逃脱不出电商的范畴。Amazon Global Selling 高级研发经理陈皓在其博客中说,与网游或QQ的后端负载相比,12306购票系统的压力显然要大得多。因为网游和QQ在线或是登录时访问的更多的是用户自己的数据,而订票系统访问的是中心的票量数据,这是不一样的。
并且,这与淘宝的秒杀活动在本质上也是有所不同,12306购票系统包含了很多查询操作,查时间,查座位,查铺位,一个车次不行,又查另一个车次, 其伴随着大量的查询操作,下单的时候需要对数据库操作。而秒杀完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只要把各个服务器的时间精确同步了就可以了,无需在当时操作任何数据库。
陈皓认为,订票系统应该和电子商务的订单系统很相似,都是需要对库存进行:1)占住库存,2)支付(可选),3)扣除库存的操作。这个是需要有一致 性的检查的,也就是在并发时需要对数据加锁的。相比于12306,B2C的电商基本上都会把这个事干成异步的,也就是说,你下的订单并不是马上处理的,而 是延时处理的,只有成功处理了,系统才会给你一封确认邮件说是订单成功。数据一致性是高并发下的一大难题。
而12306购票系统的难题在于其采用的是突然放票,而有的票又远远不够大家分,所以,大家才会有抢票这种有做法。于是当票放出来的时候,就会有几 百万人甚至上千万人杀上去,查询,下单。几十分钟内,一个网站能接受几千万的访问量,这个是很恐怖的事情。据说12306的高峰访问是10亿PV,集中在 早8点到10点,每秒PV在高峰时上千万。
通过上述分析可以看出,12306购票系统所面对的几乎是前所未有的难题,与号称最高同时在线人数1亿的QQ客户端在本质上有明显的不同,与微博、 Facebook等新兴SNS社区亦不同,单纯的并发写远远没有频繁的随机混合读写那么难。而与12306业务模式有些许类似的B2C电商却远远没有 12306面对的那么大规模人群,可以说12306购票系统的出现是目前IT界的一大难题,其不仅是硬件,还包括软件层面、架构层面以及整体优化都带来了 极大的挑战,面对如此大规模的并发,任何一个小细节都极有可能造成规模效应,而12306的仓促上线使得这些问题“并发”,最终导致“爆机”,而反观淘 宝、亚马逊以及 Facebook等,无一不是经过多年的技术积淀后才勉强能够应付,而12306正式上线运营至今不过短短半年多时间而已。