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

标签: 云/Web app 云计算 春运 火车票 | 发表时间:2012-01-12 22:20 | 作者:林玥煜、邓侃
出处:http://www.ifanr.com

昨天,2012年1月11日,网友 @fenng 写了一篇文章,批评铁道部火车票网上订购系统,http://www.12306.cn [1]。同时在新浪发了一条言辞激烈的微博,“去你妈的‘海量事务高速处理系统’”,引起热议 [2]

春节将到,大家买不着车票,赶不上大年三十与家人团聚,急切心情可以理解。但是拍桌子开骂,只能宣泄情绪,解决不了实际问题。

开发一套订票系统并不难,难在应对春运期间,日均 10 亿级别的洪峰流量。日均 10 亿级别的洪峰请求,在中国这个人口全球第一大国,不算稀罕,不仅火车票订票系统会遇到,而且电子商务在促销时,也会遇到,社交网站遇到新闻热点时,也会遇到。

所以,能够在中国成功运行的云计算系统,推广到全球,一定也能成功。但是在美国成功运行的云计算系统,移植到中国,却不一定成功。

如果我们能够设计建造一套,稳定而高效的铁路订票系统,不仅解决了中国老百姓的实际问题,而且在全球高科技业界,也是一大亮点,而且是贴着中国标签的前沿科技的亮点。

于是软件工程师们献计献策,讨论如何改进 12306 网上购票系统 [3]。其中比较有代表性的,有两篇 [4,5]

网友的评论中,有观点认为,[4] 利用“虚拟排队”的手段,将过程拉长负载降低,是网游的设计思路。而 [5] 利用缓存技术,一层层地降低系统负荷, 是互联网的设计思路。

个人认为,[4] 和 [5] 并不是相互排斥的两种路线,两者着重解决的问题不同,不妨结合起来使用,取长补短。下面介绍一下我们的设计草案,追求实用,摈弃花哨。抛砖引玉,欢迎拍砖。

图一。12306.cn 网站系统架构设想图。

Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/12306.png

图一是系统架构图,典型的“展现层”/ “业务层”/ “数据层”的三段论。

用户接入有两类,一个是运行在电脑里的浏览器,例如 IE,另一个是手机。

无论用户用电脑浏览器,还是手机访问 http://www.12306.cn 网站,用户请求首先被网站的负载均衡器接收。负载均衡器连接着一群门户服务器,根据各个门户服务器的负载轻重,负载均衡器把用户请求,转发到某一相对清闲的门户服务器。

门户服务器的任务类似于收发室老头儿,它只读每个用户请求的前几个 bytes,目的是确定用户请求的类型,然后把请求投放到相应类型的队列中去。门户服务器的处理逻辑非常简单,这样做的好处,是让它能够快速处理大批量用户请求。

根据 [5] 的分析,12306 处理的用户请求,大致分为三类,

1. 查询。用户订票前,查询车次以及余票。用户下订单后,查询是否已经订上票。
2. 订票,包括确定车次和票数,然后付款。用户付款时,需要在网银等网站上操作。
3. 第一次访问的用户,需要登记,包括姓名和信用卡等信息。

三类请求的业务处理过程,被分为两个阶段,

1. 运行于缓存中的任务队列。设置队列的目的,是防止处理过程耗时太长,导致大量用户请求拥塞于门户服务器,导致系统瘫痪。

2. 业务处理处理器,对于每一类业务,分别有一群业务服务器。不同业务的处理流程,各不相同。

图二。12306.cn 网站查询和订票业务流程设想图。
Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/12306-1.png

图二描述了查询和订票,两个业务的处理流程。登记业务流程从略。

查询的业务流程,参见图二上半部,分五步。这里有两个问题需要注意,

1. 用户发出请求后,经过短暂的等待时间,能够迅速看到结果。平均等待时间不能超过 1 秒。

2. 影响整个查询速度的关键,是“查询服务器”的设计。

查询任务可以进一步细化,大致分成三种。

1. 查询车次和时间表,这是静态内容,很少与数据库交互,数据量也不大,可以缓存在内存中。

车次和时间表的数据结构,不妨采用 Key-Value 的方式,开发简单,使用效率高。Key-Value 的具体实现有很多产品,[5] 建议使用 Redis。

这些是技术细节,不妨通过对比实验,针对火车票订票系统的实际流量,以及峰值波动,确定哪一个产品最合适。

2. 查询某一班次的剩余车票,这需要调用数据库中不断更新的数据。

[5] 建议把剩余车票只分为两种,“有”或“无”,这样减少调用访问数据库的次数,降低数据库的压力。但是这样做,不一定能够满足用户的需求,说不定会招致网友的批评讥讽。

[4] 建议在订票队列中,增加测算订票队列长度的功能,根据订票队列长度以及队列中每个请求的购票数量,可以计算出每个车次的剩余座位。如果 12306.cn 网站只有一个后台系统,这个办法行之有效。

但是假如 12306.cn 网站采用分布式结构,每个铁路分局设有子系统,分别管理各个铁路分局辖区内的各个车次。在分布式系统下,这个办法面临任务转发的麻烦。不仅开发工作量大,而且会延长查询流程处理时间,导致用户长久等待。

3. 已经下单的用户,查询是否已经成功地订上票。

每个用户通常只关心自己订的票。如果把每个用户订购的车票的所有内容,都缓存在内存里,不仅非常耗用内存空间,内存空间使用效率低下,更严重的问题是,访问数据库过于频繁,数据量大,增大数据库的压力。

解决上述分布式同步,以及数据库压力的两个问题,不妨从订票的流程设计和数据结构设计入手。

假如有个北京用户在网上订购了一套联票,途经北京铁路局和郑州铁路局辖区的两个车次。用户从北京上网,由北京铁路局的子系统,处理他的请求。北京铁路局的订票服务器把他的请求一分为二,北京铁路局的车次的订票,在北京子系统完成,郑州铁路局的车次在郑州子系统完成。

每个子系统处理四种 Key-Value 数据组。

1. 用户ID:多个 (订单ID)s。
2. 订单ID:多个 (订票结果ID)s。
3. 订票结果ID:  一个 (用户ID,车次ID)。
4. 车次ID:一个(日期),多个 (座位,用户ID)。

北京订票服务器完成订票后,把上述四个数据组,写入北京子系统的数据库,同时缓存进北京的查询服务器,参见图二下半部第6步和第7步。

郑州订票服务器完成订票后,把上述四个数据组,写入郑州子系统的数据库,同时缓存进北京的查询服务器,而不是郑州的服务器。

让订票服务器把订票数据,同时写入数据库和查询服务器的缓存,目的是让数据库永久保留订票记录,而让大多数查询,只访问缓存,降低数据库的压力。

北京用户的订票数据,只缓存在北京的查询服务器,不跨域缓存,从而降低缓存空间的占用,和同步的麻烦。这样做,有个前提假设,查询用户与订票用户,基本上是同一个人,而且从同一个城市上网。

但是这里有个缺陷,某用户在北京上网订了票。过了几天,他在北京上网,输入用户ID和密码后,就会看到他订购的所有车票。可是又过了几天,他去了郑州,从郑州上网,同样输入用户ID和密码,却看不到他订购的所有车票。

解决这个缺陷的办法并不麻烦,在用户查询订票信息时,需要注明订票地点,系统根据订票地点,把查询请求转发到相应区域的子系统。

另外,每次订票的时候,网站会给他的手机发送短信,提供订票信息,参见图二下半部第8步和第9步。

以上是一个初步设计,还有不少细节需要完善,例如防火墙如何布置等等。这个设计不仅适用于单一的集中式部署,而且也适合分布式部署。

或许有读者会问,为什么没有用到云计算?其实上述架构设计,为将来向云计算演变,留下了伏笔。

在上述架构设计中,我们假定每个环节需要用多少服务器,需要多大容量的数据库,预先都已经规划好。但是假如事先的规划,低于实际承受的流量和数据量,那么系统就会崩溃。所以,事先的规划,只能以峰值为基准设立。

但是峰值将会是多少?事先难以确定。即便能够确定峰值,然后以峰值为基准,规划系统的能力,那么春运过后,就会有大量资源冗余,造成资源浪费?

如何既能抗洪,又不造成资源浪费?解决方案是云计算,而且目前看来,除了云计算,没有别的办法。

Reference,

[1] 海量事务高速处理系统。

http://www.douban.com/note/195179318/

[2] 去你妈的‘海量事务高速处理系统’。

http://weibo.com/1577826897/y0jGYcZfW

[3] 火车订票系统的设想。

http://weibo.com/1570303725/y0l9Y2mwE

[4] 铁路订票系统的简单设计。

http://blog.codingnow.com/2012/01/ticket_queue.html

[5] 铁路订票网站个人的设计浅见。

http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html

题图来自 Designyoutrust

爱范儿 · Beats of Bits | 原文链接 · 15 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区!


相关 [建设 火车 系统] 推荐:

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

- - 爱范儿 · Beats of Bits
昨天,2012年1月11日,网友 @fenng 写了一篇文章,批评铁道部火车票网上订购系统,http://www.12306.cn [1]. 同时在新浪发了一条言辞激烈的微博,“去你妈的‘海量事务高速处理系统’”,引起热议 [2]. 春节将到,大家买不着车票,赶不上大年三十与家人团聚,急切心情可以理解.

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

- - 爱范儿 · Beats of Bits
每到春运,买火车票就成为头痛的事情. 今年铁道部开设了网上购票,本来是件惠民的好事儿,但是由于订票网站 http://www.12306.cn,没能快速地处理用户的查询和订单,引起网友的冷嘲热讽. @王津THU 在微博上替 12306 辩解了几句 [1],立刻成为众矢之的. 王津有点冤,首先 12306 系统的确有技术难度,初次亮相,出点洋相,在所难免.

12306火车订票系统漏洞

- - 蓝飞技术部落格
摘要:铁道部旗下在线购票网站12306自诞生起就一直为人所诟病,网站经常崩溃、UI粗糙、漏洞满框,但这都不是什么新闻了,近日网友爆出12306的技术框架及其表结构,大家可以来一览究竟. 应用服务器:WebLogic. 开发框架:Spring\Hibernate\Struts. 这里可以看到完整的SQL语句:.

【图集】世界上最危险的火车系统

- 林子 - 译言-每日精品译文推荐
来源IN PICTURES: The World\'s Most Dangerous Train System. 根据法国新闻社的报道,每年约有25000人死于印度的铁路上. 在这些遇难者中,许多人都死于火车事故,剩下的多数则死于摔出车门或者在轨道上被撞. 在火车高速奔驰的时刻,在火车的第一节车厢或一般得隔间里是一场噩梦,那里的每一寸地方都爬满了上下班的人.

关于火车订票系统瓶颈的分析

- - ITeye博客
1.根据新闻发布的数据,每年春运的运送旅客人次在31亿人次,基本分布在40天时间内. 2.依然提前10天买票,所以这么算每天最多在1亿人次(新闻说最多7kw每天依然做坏打算). 3.假设每个人只自己买票,或者每个票都需要实名认证(最坏的统计). 4.每天会有1亿的业务查询(身份证验证),每天会有1亿的交易(支付).

简单讨论火车票系统后面的架构设计

- - 酷勤网-挖经验 [expanded by feedex.net]
 来源:51CTO技术博客   2012-01-16. 简单说,在线服务scalability有两种方式,scale-up和scale-out. Scale-up追求单机性能,如高级硬件、异步架构等,而scale-out则用加机器的方法. Scale-out也是最简单的方法,在规模不是非常大时很好用,也很容易解决问题,普通工程师就足以胜任.

连锁百货企业数据分析系统建设方案

- - 行业应用 - ITeye博客
连锁百货企业数据分析系统建设方案. FineReport数据系统的总体流程为:整合和获取数据,将数据应用于报表的开发,将开发完的报表进行逻辑展示处理和部署,最后呈现给使用者使用. 开发报表的过程中,必须结合企业流程和企业内部的系统数据,进行统一搭建,最终要求开发出一个结合了各个系统数据的报表决策平台.

【转】亿级Web系统的容错性建设实践

- - 研发管理 - ITeye博客
转载:http://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=402841629&idx=1&sn=f598fec9b370b8a6f2062233b31122e0&scene=4#wechat_redirect. 亿级Web系统的容错性建设实践. 功能介绍 企业架构、系统架构、网站架构、大规模分布式架构、高可用架构等架构讨论,以及结合互联网技术的架构调整.

支付系统的基础设施建设

- - IT瘾-tuicool
基础设施是为了支持支付开发的软件过程. 在进入主题之前,先吐槽下软件过程. 软件过程在这几年都越来越不受人待见了. 在一些互联网公司里面,软件过程的概念往往被等同于拖拉、延期、冗长. 他们为自己的软件过程往往都会贴上敏捷的标签,并为各种混乱的管理提供了一个非常好的借口. 就算是先写代码再补需求,也能够套上敏捷开发借口.

用httpclient开发的在线自动抢订火车票系统(已上传源代码)

- - ITeye论坛最新精华讨论帖
前两天女友要在线订火车在票,一直都没有办法订到票,最后没办法,便给她写了个自动抢票的脚本,可周边的朋友听她说通过软件订到票了,都先后向她要软件,可原来的脚本只是基于控制台输入,这样给别人也没法用,兴趣一起,就花了一天的时间做了个WEB界面,然后分享给朋友用. 这个是登录界面,要使用前先设置一下常用的邮箱和登录密码,自动抢票过程中,如需要再输入登录验证码和订单验证码,或订单成功时,将通过此email通知您,建议使用qq邮箱,这样只要您在电脑时开打QQ,收到邮件时,qq会弹出窗口通知您,您可以即时响应.