透过12306五大焦点看高性能高并发系统
幽云十八 发表于:12年02月20日 09:46 [转载] IT168
焦点一:实现高性能高并发系统到底有多难?
据铁道部副部长胡亚东介绍,网络售票和电话订票每天已经达到了200万张,网络售票的注册用户已经超过了1000万人。从1月1日到1月7 日,“12306”网站日均点击次数已经超过了10亿次……这确实是12306所面临的难题之一,但有网友认为,看似高达10亿的PV量,一旦经过分解之 后,其均摊到每分钟的并发并不算高。但实际上并不能这样算,12306网站在晚上是不售票的,另外,大部分的并发就集中在开始售票的一段时间。由于瞬间的 海量并发造成了12306“爆机”。高并发、高性能、瞬间并发一下子成为互联网上的热点话题。
清华大学Web与软件技术研究中心电子商务研究室主任王津在某微博上发表看法认为,“海量事务高速处理系统”是一种非常特别的系统,应用的场合很 少,中国目前研究这种系统的人不多,有真正的实践经验的人更少。多年前末学本人在接触这种系统之前也无法想象“到了某个时刻”系统的性能下降之剧烈乃至崩 溃。恳请大家不臆测不轻视类似12306系统的难度。
这一微博一经发布刻遭到了诸多网友的反对,但同时也有支持这一观点的网友。面对海量的并发,之所以引发12306“爆机”的重要因素之一在于,在开 始售票前后一段时间内,不断的查询数据库和刷新操作使得12306难以应付。基于这一点,有网友提出,可利用SSD的高速读取优势来充当缓存层,当数据库 有变化时,再通知更新缓存更新,这样就可极大地解决频繁的库查询引发的系统“爆机”。并且该网友还举例:在某次大型体育盛事期间的直播项目之中,就是利用 上述的缓存设计从而避免了系统“爆机”。这其中谁对谁错,我们无法评判,但值得注意的是,视频流跟类似12306的高性能高并发系统还是有一定的差别,在 开始售票后,多人的并发操作必然会引发数据库的频繁读写,几乎是每秒都有变化,而缓存层的数据跟数据库一旦不一致,必然就会出现之前12306曾出现的现 象 ——查询有票,却买不到票。
对于售票时的高并发,网名为“云风”的网友则认为可以在售票环节中加入排队系统,这就如之前的网络游戏“魔兽争霸”一样,当服务器达到饱和之后,采 取排队的形式来购票。更有“前卫”的网友认为,“春运”期间之所以买票难,除了一年一度的春节因素之外,另一个重要的因素在于,买票的人过多,已经超出了 铁道部的运输能力。所以根据这一点,提出延长订票时间,在截止售票后,进行随机抽取。
如果采用排队系统的话,有人就质疑万一有插队的呢?这个问题基本上是任何人都说不清的问题,而买票这等严肃的事情如果要“抽签”这种方式的话,就未 免太过儿戏。对于类似12306的高性能高并发系统并没有一个标准的答案,同时也有一种说不清道不明的感觉,虽然诸多IT技术大牛都真相提出了很多的建 议,但总有些地方会遭到质疑,并引发另一场讨论。既然谁也没有一个“服众”的解决方法,那么是否可以借助新浪、淘宝等已有的成熟架构呢?由此又引发了关于 高性能高并发系统的另一个争议。