建筑一个靠谱的火车票网上订购系统.pdfVIP

建设一个靠谱的火车票网上订购系统 昨天 ，2012年1月11日 ，网友 @f enng 写了一篇文章 ，批评铁 部火车票网上订购 系统 ，ht t p:// [1]。同时在新浪发了一条言辞激烈的微博 ，“去你妈的‘海量事务高速处 理系统’” ，引起热议 [2]。 春节将到 ，大家买不着车票 ，赶不上大年三十与家人团聚 ，急切心情可以理解。但是拍桌子开骂 ， 只能宣泄情绪 ，解决不了实际问题。 开发一套订票系统并不难 ，难在应对春运期间 ，日均 10 亿级别的洪峰流量。日均 10 亿级别的洪峰 请求 ，在中国这个人口全球第一大国 ，不算稀罕 ，不仅火车票订票系统会遇到 ，而且电子商务在促 销时 ，也会遇到 ，社交网站遇到新闻热点时 ，也会遇到。 所以 ，能够在中国成功运行的云计算系统 ，推广到全球 ，一定也能成功。但是在美国成功运行的云 计算系统 ，移植到中国 ，却不一定成功。 如果我们能够设计建造一套 ，稳定而高效的铁路订票系统 ，不仅解决了中国老百姓的实际问题 ，而 且在全球高科技业界 ，也是一大亮点 ，而且是贴着中国标签的前沿科技的亮点。 于是软件工程师们献计献策 ，讨论如何改进 12306 网上购票系统 [3]。其中比较有代表性的 ，有两 篇 [4 ,5]。 网友的评论中 ，有观点认为 ，[4] 利用“虚拟排队”的手段 ，将过程拉长负载降低 ，是网游的设计思路 。而 [5] 利用缓存技术 ，一层层地降低系统负荷, 是互联网的设计思路。 个人认为 ，[4] 和 [5] 并不是相互排斥的两种路线 ，两者着重解决的问题不同 ，不妨结合起来使用 ， 取长补短。下面介绍一下我们的设计草案 ，追求实用 ，摈弃花哨。抛砖引玉 ，欢迎拍砖。 图一。12306.cn 网站系统架构设想图。 Co u t esy ht t p://alibuybuy-img11.st o .sinaapp.co m/2012/01/e990_ 12306.png 图一是系统架构图 ，典型的“展现层”/ “业务层”/ “数据层”的三段论。 用户接入有两类 ，一个是运行在电脑里的浏览器 ，例如 IE ，另一个是手机。 无论用户用电脑浏览器 ，还是手机访问 ht t p:// 网站 ，用户请求首先被网站的负载均 衡器接收。负载均衡器连接着一群门户服务器 ，根据各个门户服务器的负载轻重 ，负载均衡器把用 户请求 ，转发到某一相对清闲的门户服务器。 门户服务器的任务类似于收发室老头儿 ，它只读每个用户请求的前几个 byt es ，目的是确定用户请 求的类型 ，然后把请求投放到相应类型的队列中去。门户服务器的处理逻辑非常简单 ，这样做的 好处 ，是让它能够快速处理大批量用户请求。 根据 [5] 的分析 ，12306 处理的用户请求 ，大致分为三类 ， 1. 查询。用户订票前 ，查询车次以及余票。用户下订单后 ，查询是否已经订上票。 2. 订票 ，包括确定车次和票数 ，然后付款。用户付款时 ，需要在网银等网站上操作。 3. 第一次访问的用户 ，需要登记 ，包括姓名和信用卡等信息。 三类请求的业务处理过程 ，被分为两个阶段 ， 1. 运行于缓存中的任务队列。设置队列的目的 ，是防止处理过程耗时太长 ，导致大量用户请求拥塞 于门户服务器 ，导致系统瘫痪。 2. 业务处理处理器 ，对于每一类业务 ，分别有一群业务服务器。不同业务的处理流程 ，各不相同。 图二。12306.cn 网站查询和订票业务流程设想图。 Co u t esy ht t p://alibuybuy-img11.st o .sinaapp.co m/2012/01/1e0d_ 12306- 1.png 图二描述了查询和订票 ，两个业务的处理流程。登记业务流程从略。 查询的业务流程 ，参见图二上半部 ，分五步。这里有两个问题需要注意 ， 1. 用户发出请求后 ，经过短暂的等待时间 ，能够迅速看到结果。平均等待时间不能超过 1 秒。 2. 影响整个查询速度的关键 ，是“查询服务器”的设计。 查询任务可以进一步细化 ，大致分成三种。 1. 查询车次和时间表 ，这是静态内容 ，很少与数据库交互 ，数据量也不大 ，可以缓存在内存中。 车次和时间表的数据结构 ，不妨采用 Key-Value 的方式 ，开发简单 ，使用效率高。Key-Value 的具 体实现有很多产品 ，[5] 建议使用 Redis。 这些是技术细节 ，不妨通过对比实验 ，针对火车票订票系统的实际流量 ，以及峰值波动 ，确定哪一 个产品最合适。 2. 查询某一班次的剩余