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

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