当前位置:首页 > 经验学习 > 设计思想

建设一个靠谱的火车票网上订购系统

所属栏目:设计思想 时间:2013-12-26 来源: 作者:admin 点击:

昨天,2012年1月11日,网友 @fenng 写了一篇文章,批评铁道部火车票网上订购系统,http://www.12306.cn [1]。同时在新浪发了一条言辞激烈的微博,“去你妈的‘海量事务高速处理系统’”,引起热议 [2]。
春节将到,大家买不着车票,赶不上大年三十与家人团聚,急切心情可以理解。但是拍桌子开骂,只能宣泄情绪,解决不了实际问题。
开发一套订票系统并不难,难在应对春运期间,日均 10 亿级别的洪峰流量。日均 10 亿级别的洪峰请求,在中国这个人口全球第一大国,不算稀罕,不仅火车票订票系统会遇到,而且电子商务在促销时,也会遇到,社交网站遇到新闻热点时,也会遇到。
所以,能够在中国成功运行的云计算系统,推广到全球,一定也能成功。但是在美国成功运行的云计算系统,移植到中国,却不一定成功。



如果我们能够设计建造一套,稳定而高效的铁路订票系统,不仅解决了中国老百姓的实际问题,而且在全球高科技业界,也是一大亮点,而且是贴着中国标签的前沿科技的亮点。
于是软件工程师们献计献策,讨论如何改进 12306 网上购票系统 [3]。其中比较有代表性的,有两篇 [4,5]。
网友的评论中,有观点认为,[4] 利用“虚拟排队”的手段,将过程拉长负载降低,是网游的设计思路。而 [5] 利用缓存技术,一层层地降低系统负荷, 是互联网的设计思路。
个人认为,[4] 和 [5] 并不是相互排斥的两种路线,两者着重解决的问题不同,不妨结合起来使用,取长补短。下面介绍一下我们的设计草案,追求实用,摈弃花哨。抛砖引玉,欢迎拍砖。



图一。12306.cn 网站系统架构设想图。
Courtesy http://alibuybuy-img11.stor.sinaapp.com/2012/01/e990_12306.png
图一是系统架构图,典型的“展现层”/ “业务层”/ “数据层”的三段论。
用户接入有两类,一个是运行在电脑里的浏览器,例如 IE,另一个是手机。
无论用户用电脑浏览器,还是手机访问 http://www.12306.cn 网站,用户请求首先被网站的负载均衡器接收。负载均衡器连接着一群门户服务器,根据各个门户服务器的负载轻重,负载均衡器把用户请求,转发到某一相对清闲的门户服务器。
门户服务器的任务类似于收发室老头儿,它只读每个用户请求的前几个 bytes,目的是确定用户请求的类型,然后把请求投放到相应类型的队列中去。门户服务器的处理逻辑非常简单,这样做的好处,是让它能够快速处理大批量用户请求。
根据 [5] 的分析,12306 处理的用户请求,大致分为三类,
1. 查询。用户订票前,查询车次以及余票。用户下订单后,查询是否已经订上票。
2. 订票,包括确定车次和票数,然后付款。用户付款时,需要在网银等网站上操作。
3. 第一次访问的用户,需要登记,包括姓名和信用卡等信息。
三类请求的业务处理过程,被分为两个阶段,
1. 运行于缓存中的任务队列。设置队列的目的,是防止处理过程耗时太长,导致大量用户请求拥塞于门户服务器,导致系统瘫痪。
2. 业务处理处理器,对于每一类业务,分别有一群业务服务器。不同业务的处理流程,各不相同。




图二。12306.cn 网站查询和订票业务流程设想图。
Courtesy http://alibuybuy-img11.stor.sinaapp.com/2012/01/1e0d_12306-1.png
图二描述了查询和订票,两个业务的处理流程。登记业务流程从略。
查询的业务流程,参见图二上半部,分五步。这里有两个问题需要注意,
1. 用户发出请求后,经过短暂的等待时间,能够迅速看到结果。平均等待时间不能超过 1 秒。
2. 影响整个查询速度的关键,是“查询服务器”的设计。
查询任务可以进一步细化,大致分成三种。
1. 查询车次和时间表,这是静态内容,很少与数据库交互,数据量也不大,可以缓存在内存中。
车次和时间表的数据结构,不妨采用 Key-Value 的方式,开发简单,使用效率高。Key-Value 的具体实现有很多产品,[5] 建议使用 Redis。
这些是技术细节,不妨通过对比实验,针对火车票订票系统的实际流量,以及峰值波动,确定哪一个产品最合适。

请站长喝杯咖啡?

站长一直坚持白天工作、晚上熬夜更新素材,付出了巨大的精力和时间,其中的辛酸难以言述。

坚持免积分、免登录、无任何限制下载!如果本站素材对你有用,不妨考虑请站长喝杯咖啡鼓励一下!

标签:

你应该也喜欢这些吧

共有 0 条评论

给个评价吧

验证码: