如何构建安全、稳定、高吞吐量的火车票网上售票系统

如果是你来构建火车票订票系统，你如何实现？——关于构建安全、稳定、高吞吐量的火车票网络售票系统几个方面引：客票系统客票系统客票服务系统/数据库/余票/订票等柜台订票系统网络订票系统电话订票系统火车票客票系统基本框图 火车出行是人们常用、便捷的一种出行方式，基于中国的人口多的情况，中国的火车出行人数非常庞大。中国铁道部为了解决火车票订票难、抵制“黄牛”、提高火车出行的安全性、提高订票公平性等火车出行问题，先后推出了火车票实名制、网络售票等业务，以方便旅客更便捷地使用火车作为交通工具出行。但目前所推出的网络客票系统存在经常性崩溃、无法正常提供服务的情况，究其根源，主要是因为使用本系统的人过多，超过系统的承载力所至，为了改善这些问题，从系统架构方面着手是解决本系统的关键，构建安全、稳定、高吞吐量的火车票订购系统也是迫在眉睫的事情。 客票系统看起来如图所示，它包括柜台订票、电话订票、网络订票以及客票系统核心数据库等部分组成。本方案主要着眼于网络订票系统的架构方案的讨论，以期通过本方案可以实现一个超级、超大规模、可灵活扩展的实时订票交易系统。现状 目前12306.cn为铁路网络售票系统，周围朋友均已经纷纷注册了信息在网上进行订票体验，最坏的情况是一个朋友连续订了两天最终没有订票成功，系统不是提示忙就是提示超时（CDN缓存提示），系统几乎处于瘫痪状态。这不仅仅是带宽不足，更是系统在架构设计上的存在严重的不足。 于是，在网上纷纷对本系统产生了各种各样的讨论，有的说是系统设计问题、有的说是系统带宽不足、有的说明系统设计时有失公平（竞标）、有的说付了款却没了票、有的说是需要用“云计算{技术}”才能解决等等。不管怎么样，重新架构或进行重大调整是必然的。个人觉得云计算只不过是一种资源或信息服务方式，它也需要更好的系统的架构和稳健的系统才能提供这种服务方式，所以通过“云计算”并不能解决本系统的超大规模的访问的承载，相反更应该从系统架构方面来重拾系统的稳健和可扩展性。 目前12306.cn最高日访问量达14.09亿次，最高日订票量为166万笔。显示出本系统的高访问量和事务密集。个人认为14亿次访问量与系统几乎处于瘫痪状态有关，因为用户一旦进行操作失败并会重复访问，因此如果系统运行稳定和可以正常服务后日访问量将大幅减少（据Aleax不完全统计7天访问本系统的用户是全球互联网用户的0.902%，按全球用户为22亿计算，大约为：0.1984亿，所以每日的访问独立人数平均为0.1984亿/7=285万人，因此日访问量14亿更多的是来源于操作不成功的用户重复访问所至）。 初步分析可以肯定，12306.cn之所以无法正常提供服务和进行实时处理，其最可能的影响因素主要有：系统架构不合理、余票查询处理不当（此项业务访问量是本系统最大的访问量）、火车时刻查询处理系统、订票/支付系统集中（这是导致付款不成功的主要因素）、互联网与铁路网接入等问题。 本文将从系统业务流程、系统架构、高并发量分流方案、余票驳借、孤岛计算模式等方面提出一种全新的火车票订票系统解决方案。本方案假设与目标 假设： 系统域名为：； 原有客票系统已经稳定，可向网络订票提供正常的服务； 不考虑柜台与电话订票。 目标： 日最高订票量500万张（按目前网络订票系统工作18小时算，每秒处理订单量为78张）； 高锋时每秒处理订票：5000张； 日PV（页面点击量）：20亿次；系统的基本业务流程系统余票信息查询 visitorvisitor输入车次、始终站、时间等信息查询火车时刻查询 visitorvisitor输入车次、始终站、时间等信息查询火车票基本订票流程 支付回馈系统() 支付系统本应该是一个最简单的系统，但是由于支付后银行的系统需要回馈订票系统某订单支付是否成功，这也给订票系统产生了压力。那么对回馈系统构建独立架构也是必不可少的，否则回馈不成功，则系统认为没有支付，就产生了目前付了款，但没了票的情况。支付流程大概如下图所示，显然现有系统在支付回馈中出了问题，归根到底还是订票系统崩溃或是无法响应所至。但相对于整个系统来说支付回馈的请求量远少于余票查询系统的访问量。visitorsvisitors订票系统银行系统支付支付回馈 短信确认系统 短信确认系统由订票系统使用，因此不存在请求上太大的压力，但是构建短信队列是必要的。并且实时性要求并不高。 以下信息并非高访问量的系统可以构建完全的静态和客户端计算模式的系统。 火车时刻查询 正晚点查询 客票代售点查询 铁路转程查询 火车车次分流 由于火车车次间相对独立性，因此使用基于车次进行分流是一种可行的措施。比如：T1~T1000采用A服务器、D1~D100采用B服务器，这样来进行分流。由客户端（用户计算机）来决定使用哪一个服务器提供服务。这样在订票时对服务器的压力可以大大减少，同时可以无限制的扩展服务器以实现无限的分流。 比如可以这样安排服务器：T1~T1000订票自动转发到：t1_。D1~D100订票自动转发到：d1_。 这样的决定并不需要服务器来计算，而是由访问者的计算机在网页中就可以决定。即在什么服务器上进行出票。仅增加带宽并不能解决本系统的高吞吐量 个人觉得带宽绝