焦点二：类似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正式上线运营至今不过短短半年多时间而已。