赵 光 上海铁路局信息技术所
2012年春运,是铁路首次大规模实行互联网售票,12306互联网售票系统的初衷是通过在线购票方式以免除旅客半夜早起,在瑟瑟寒风中排队挨冻购票的痛苦,让普通民众享受互联网技术所带来的方便,同时加大打击票贩子,促进社会和谐,改善铁路形象。从其实际运行效果来看,该网站在平时的运行的确比较成功,但在应对春运期间瞬间海量的并发访问时,一度出现许多问题。海量事物处理的高并发访问本身就是国内公认的难题。因此,亟需对12306网站进行优化,提前谋划,精心布局,未雨绸缪,以便应对2013年春运可能面临的更大网上流量。
根据公开的资料显示,12306购票系统在春运期间的高峰已超过14亿PV。目前在12306互联网售票系统中注册的用户数为1400万,单日互联网交易量高峰达188万笔 (全路日均售票量近500万张,高峰期售票量达700万张)。
12306 互联网售票系统在春运期间暴露的问题主要是:在票额分发的瞬间,大量的用户秒杀,造成网站出奇的慢、很难登陆、支付不容易成功、用户因焦虑而不停地刷屏等。
同时12306还存在一个潜在的问题,根据相关的统计数据,中国的流动人口为2个亿,这些流动人口是春运期间通过互联网售票系统享受所带来便利的最大人群,现在这部分人中很多人还没有成为12306的注册用户,如果12306互联网售票系统做得非常强劲的话,其注册的用户数将会非常快速地增长,翻几番地增长是非常有可能的,如此大规模的事物高速处理是件非常棘手的事情。
实现海量事物的高速处理,目前仍是IT业界公认的一个难题,国内的权威机构负责人-清华大学Web与软件技术研究中心主任王津曾发表看法认为:“海量事务高速处理系统是一种非常特别的系统,应用的场合很少,无法想象在峰值时系统的性能下降之剧烈乃至崩溃。恳请不臆测、不轻视类似12306系统的难度”。
与12306类似的有着高并发访问的国内大型网站还包括淘宝、新浪微博、京东商城、腾讯QQ等。与春运相似度最高的大概就是淘宝的双11秒杀活动了,虽然两者都是实名制,但还是有很大的区别:第一,销售的行为不同:虽然淘宝活动期间瞬间的量也很大,但是它不会造成用户如果没完成购买行为,就不高兴,后期还会买到想要的东西。但是车票在春运期间蕴涵着年味与亲情,是特殊性的和唯一性的,票被人买走了,就不会再有了;第二,在访问的地域性方面,购物网站里面可以依照你所在的城市很快看到这个城市可以买到的东西,而车票的概念就没有地域性了;第三,在业务流程方面,在做实名制跟金流的时候,每一阶段的动作都必须要基于前一个行为,比如说确认用户的身份后,还要确认他的银行卡和其存款是否足额,甚至要完成转帐以后,才能确定出票。而在淘宝网上,则可以先把东西买好,事后再做转帐,所以他的流程不见得是单一项的。
而与新浪相比,由于新浪不是一定要做到实名制,它就不需要很大的数据库来支持整合金流、物流等等这些东西,且对于回应的结果并不要求那么及时。
因此可以说,在目前国内的电子商务网站中,对于海量事物的高速处理,12306遇到前所未有的挑战,无出其右者。难怪王津曾感叹到“中国的铁路电商系统,将是全世界规模最大的电商系统之一,也是全世界最海量最高速的事务处理系统之一,运行峰值时没有任何已知的系统可以比肩,是难度最高最容易失败的系统之一”。
12306 互联网售票系统要让旅客在春运时方便快速地使用,应该具有以下几个特点:
(1)必须让12306互联网售票系统承担更多火车票销售的任务,降低传统渠道(例如车站和代售点)的压力。根据统计数据显示,12306互联网售票系统的售票比例只有11%,如果能够提高到40%以上,那对旅客和铁路售票员来说都是一大好事,两全其美。
(2)系统应该具有良好的用户体验,用户界面友善、操作方便。
(3)要支持智能手机,让用户能够通过智能手机很方便地使用。
(4)最重要的一点,该系统应该是一个高性能、高可靠性、可伸缩性的系统,在春运高峰期增加机器能够应对高峰期的峰值用户群,在非高峰期减少机器,降低相应的消耗及运维成本。
针对12306的高性能和高并发访问要求,如何搭建相关的系统架构,其实,早有相关技术人员给出建议:开放相关的互联网接口,让相关的大型网站接入,分担12306高峰时的压力。笔者以为,从技术上不失为一种方案。具体来说就是:把12306互联网售票系统与淘宝、腾讯、新浪微博等这些公司平台提供的互联网应用进行对接,采用消息队列为核心的异步机制方式进行。这样当在票额上网的瞬间,有大量用户进行秒杀的时候,就可以在几分钟之内甚至1分钟之内压到新浪微博、淘宝、腾讯这些公司平台提供的互联网售票WEB应用中,所产生的压力由相应的网络、均衡负载器、互联网售票WEB应用的服务器给分别地承销掉,并且转换成相应的消息异步传送到12306互联网售票数据服务系统进行处理,12306互联网售票数据服务系统可以根据相应的需求按需配置所需要的资源,同时由于采用了消息队列为核心的异步机制,可以对登录实现一次处理多条消息的批量处理,而且还可以利用支付宝、财富通等进行支付,丰富支付方式,从而大大地降低对后台系统的压力。高峰时并发的压力将会下降几个数量级。但是在这种架构方式中存在的缺点就是如何与这些网站进行协商以及利益如何分成等,且消息队列的异步处理要求较高。
据悉,12306互联网售票系统要在铁路局网上开分店,个人以为其实质上与跟大的网站合作类似,且这样处理可能更方便些,避免了合作过程中可能出现的问题,而且可以把后台票额的数据分布做得更加灵活,只是支付系统可能需要下一番功夫做好。这种方式的最大的缺点是需要投入大量的成本。
对于常用的使用CDN、使用缓存、后端的数据分区、数据镜像等优化措施,相信12306都已经付诸实施。这里笔者只是介绍一下前端展现和后端架构的优化方面。
前端优化:在网站的页面设计中,把CSS样式嵌入到页面中,加大了页面的大小,消耗了带宽。如果每个页面大小70 K,其中CSS嵌入假设是1 K。因为每次访问,都要去下载这多余的1 k的css样式,那么上千万的pv去访问的时候,产生的流量就是1 k×上千万次。也就是说要多消耗服务器的这么多网络带宽,这是很致命的,任何一个小细节在高并发下都会被放大。网站上如果有大量的嵌套CSS,可以考虑与页面框架分离,缓解网站前端访问压力。
后台架构方面:12306售票系统的关键在于秒杀票额时后台频繁的读写数据记录操作,这也是海量事物高速处理的难点。我们知道:数据库的事物处理必须保证事物的一致性、原子性、隔离性与持久性,因此数据库都必须使用一定的锁机制来保证数据的一致性,因此并不是说只要有足够的带宽、服务器够快、够多就可以解决“海量事物高速处理”的问题,2008年奥运会的定票系统也遇到过类似的情况。
在12306网站架构中推荐引入中间件,把事物的协调处理交给中间件,而不是仅仅依靠数据库本身的锁机制。把这个自行开发的中间件部署到分布式系统中,可以按照实际需求最大程度的优化,目前,“海量事物高速处理”中自行开发分布式事物处理大多基于Paxos算法,该算法提供了一个为分布式系统如何就某个值(决议)达成一致的模型。Paxos算法证明了一个符合Paxos模型的实现必然能保证分布式一致性,不需要针对于每次的具体实现再次证明,是目前解决分布式系统一致性算法中最有效的算法。放在实际的应用环境中也就意味着,数据库被绑定在自己做的中间件上,其他的应用和消息的异步处理等都从相关中间件上获取数据,而不是直接访问数据库。这样一来,对数据库的访问达到最大程度的优化。
目前,铁道部已启动了新一代客票系统的规划和设计。新一代客票系统将在既有客票系统的基础上,在技术架构方面,引入云计算技术,构建支撑超大规模并发交易、海量数据存储、灵活扩展、安全可靠高效的综合信息系统。
但是,至少在目前来看,采用云计算可能还不现实。首先云计算比较适合于小型的网站,而对于大型的电子商务以及12306这种实名制的定票系统来说,将核心的应用以及重要的数据放到云平台上,可能并不划算,因为带宽、CPU等都要计费,利用率提高了,成本不一定节省,且不可控。而且从数据的安全性上还不太现实,目前国内并没有什么成熟的云平台能提供高可靠性、高性能的解决方案,比较成熟的云服务商大部分在国外,国内掌握云计算核心技术的人才匮乏,12306实名制的特点决定其数据不能随便乱放,“云里雾里”的云计算虽然愿望很好,但在用户负荷变化剧烈的情况下,技术和管理都不成熟的云计算资源都可能出现问题,而这对于商用来说甚至是灾难性的。除非12306搭建一个属于自己的私有云环境。7网站的管理与商务操作建议
再好的电子商务网站也需要业务管理与技术维护相配合,12306原是为高铁与动车定票服务的,而在主观部门的行政要求下,要在春运推广到全路所有的车次,因此网站压力骤至,而留给相关技术人员的时间又太短,只能是勉强度过了这个春运。因此,相关部门的行政决定必须听取技术人员的意见。
造成12306春运瞬间负荷过重的直接原因是每天的固定时间点票额集中上网,票额的管理是否可以考虑把票额上网的时间点分开(例如票额按车次的开点自动上网等等),分散一下目前并发访问的额度,从而缓解12306并发访问峰值的压力,达到削峰填谷的效果。
12306 网站作为铁路售票的专有电子商务网站,到目前为止,还没有相应的广告投放等其它商务操作。以目前春运拥有如此高的访问量,相关的商务前景相当广泛,有业内人士指出12306的潜在价值可达到100个亿。这方面可考虑与专门的公司合作,充实团队的相关人员,参考国内大型的电子商务网站的运做模式。
总之,12306互联网售票系统的建设必须以用户的体验为中心,通过互动式运营不断改进,这是任何一个大型网站建设必须遵循的思路。淘宝和新浪等许多大型的成功网站都是经过多年的沉淀与积累,而12306还毕竟是第一次投入春运,对于后面的改进与完善,我们充满期待。