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

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