如果你是来12306系架，你如何实现？ ——关于构建安全、稳定、高吞吐量的火车票网络售票系统几个方面（2）结束及总结
上节，对12306。cn有了一个很好的铺垫，这节我们来讨论，架构的具体问题
署接上文
于是，在网上纷纷对本系统产生了各种各样的讨论，有的说是系统设计问题、有的说是系统带宽不足、有的说明系统设计时有失公平（竞标）、有的说付了款却没了票、有的说是需要用“云计算{技术}”才能解决等等。不管怎么样，重新架构或进行重大调整是必然的。个人觉得云计算只不过是一种资源或信息服务方式，它也需要更好的系统的架构和稳健的系统才能提供这种服务方式，所以通过“云计算”并不能解决本系统的超大规模的访问的承载，相反更应该从系统架构方面来重拾系统的稳健和可扩展性。
目前12306.cn最高日访问量达14.09亿次，最高日订票量为166万笔。显示出本系统的高访问量和事务密集。个人认为14亿次访问量与系统几乎处于瘫痪状态有关，因为用户一旦进行操作失败并会重复访问，因此如果系统运行稳定和可以正常服务后日访问量将大幅减少（据Aleax不完全统计7天访问本系统的用户是全球互联网用户的0.902%，按全球用户为22亿计算，大约为：0.1984亿，所以每日的访问独立人数平均为0.1984亿/7=285万人，因此日访问量14亿更多的是来源于操作不成功的用户重复访问所至）。
初步分析可以肯定，12306.cn之所以无法正常提供服务和进行实时处理，其最可能的影响因素主要有：系统架构不合理、余票查询处理不当（此项业务访问量是本系统最大的访问量）、火车时刻查询处理系统、订票/支付系统集中（这是导致付款不成功的主要因素）、互联网与铁路网接入等问题。
本文将从系统业务流程、系统架构、高并发量分流方案、余票驳借、孤岛计算模式等方面提出一种全新的火车票订票系统解决方案。
本方案假设与目标
假设：
系统域名为：hcpxxxxxx.cn；
原有客票系统已经稳定，可向网络订票提供正常的服务；
不考虑柜台与电话订票。
目标：
日最高订票量500万张（按目前网络订票系统工作18小时算，每秒处理订单量为78张）；
高锋时每秒处理订票：5000张；
日PV（页面点击量）：20亿次；
系统的基本业务流程
系统余票信息查询
火车时刻查询
火车票基本订票流程
其中“输入乘客信息，订票数量进行订票”的过程如下：向客票系统查询实时余票——>若有余票——>锁订所订票数——>出票，否则不成功。
系统总体架构
为了实现超大访问和实时处理系统，系统基本架构如下图所示：
DNS分流
DNS分流是建立高吞吐量系统的第一步，特别是在中国，由于南北互通问题，通过DNS分流可以把南北用户自动分配到南北各自的网络中。DNS分流已经有成熟的技术和软件，因此这里不再详细描述。
DNS分流主要目的是把客流引入到不同的WEB前端服务器，通过DNS分流可以实现客流的一级分流，比如分别在电信和网通放置5台前端WEB转发（消息路由）服务器，则南北用户将自动由DNS分流引入到这些服务器中。一般大型的WEB系统不会在前端WEB服务器中部署应用，因为这样是不可能达到高并发请求的，而是把前端WEB服务器作为消息路由服务器，把用户请求按业务类型或是其它算法把客户分流引入更多的服务器机群中，大概结构如图所示：
前端WEB转发（消息路由）服务器
前端WEB服务器在高访问量的系统中显然不能作为应用服务器，因此前端WEB应该作为高速穿透性请求转发器，由这些转发器把用户的请求高速地分流到后端不同的应用和服务器集群中。WEB服务器不仅为请求分发系统，同时也是负载分发系统、业务分发系统，但均不需要进行软件开发、只是部署而已。
前端WEB服务器与DNS分流共同组成整个系统的分流、负载均衡入口。
把好动静态数据关、采用孤岛计算模式
大型内容发布系统、商品系统无不把信息生成静态HTML或静态数据，这样可以极大地缓解后端应用服务器和数据库的压力。
可以这样设想，有多少人访问系统就有多少计算机参与到整个系统的计算。显然服务器端占了计算的主要部分，那么是否可以让这些使用者的计算机也参与到整个系统中来，而并非仅仅是浏览呢？答案是肯定的。同时对于大访问量的系统来说更应该让访问者的计算机参与进来。采用访问者的计算机参与计算的模式，我把它叫“孤岛计算模式”，它只负责当前访问者相关的计算，这样就不会与服务器和其它访问者构成相互影响的关系。因此把一些互不相关、计算量频繁，而数据量又不大的系统安排给访问者的计算机来计算是设计超大型访问量的系统的一个必然选择，这样可以充分利用访问者计算机的闲置资源。
那么在本系统中有哪些资源可以由访问者的计算机来计算呢？显然有很多，比如时刻表查询、站名查询、转程查询、余票查询的站名处理等信息。那么有人会问这不就需要把这些数据都下载到客户端吗？答案是否定的，系统应该采用按需计算模式，把用户需要的数据下载到客户端即可。比如用要查询K112次列车的信息，那么就不需要下载T88次列车的信息。
为了适应客户端高速计算，处理掉服务器中的信息从数据库中直接查询也是必然的，大量信息可以生成XML数据或是HTML静态数据，比如时刻表、车站、车次等信息均可以生成静态的XML数据，这样可以把服务器的CPU时间安排给更需要的业务系统或是分拆给不同的业务系统。
同时，通过大量资源的静态化处理和分离式计算，可以提高CDN的效率。
业务系统分流
除了系统整体部署和硬件架构外，系统的业务分开处理，也是一个大型系统必须进行的。基于火车票订票系统的几个基本流程，大概可以分以下几个子业务系统：
用户注册
使用独立的服务器和通道提交注册信息和资料（比如：user.hcpxxxxxx.cn）。
用户登录验证
登录验证是用户进入系统的第一道关，因此它的访问量也相对较大，应该使用独立的通道（同时需要采用负载均衡），比如使用：login.hcpxxxxxx.cn 专门处理用户登录。
余票信息查询（比如使用：q.hcpxxxxxx.cn）
余票信息查询应该是整个系统请求量最大的一个业务系统，目前系统采用30分钟更新余票信息，这样做不仅不合理（不具有实时性），更增加了系统的压力。
建议采用余票驳借措施来处理系统，所谓余票驳借，即从总的客票系统中一次性借入一定比例（比如20%）的票量到网络订票系统中，并建立具有负载均衡的高速动态缓存服务器来查询余票。采用余票驳借可以提供订票的速度。
比如某日票量为500万张，由系统驳借20%即100万张进入网络售票系统，那么这100万张在客票系统看来已经被订出。因此在网络售票系统中产生的订单和出票不需要再与客票系统进行交互，而是由后端的处理系统定时或是实时地把成功出票的订单更新到客票系统，这样可以大大提供系统的订单处理吞吐量，同时也可以排除与客票系统高并发请求的压力风险。
在经过一定的时间或是客票系统售完后可以把驳借出来的票回收到客票系统中，或是网络票售完后再从客票系统中驳借票。这样与客票系统的交互请求量将不再存在压力。所以客票驳借是双向的。可以由专门的服务器来完成操作。以达到网络系统是真正的实时系统。
驳借方式可以由专门的系统来管理策略并监控各系统的售票情况，以便可以相互驳借。
订票系统(book.hcpxxxxxx.cn)
在采用余票驳借的情况下，订票系统显示格外轻松，它的购票过程更加简便，不需要在购票提交时进入原有客票系统锁定余票，而是仅需要驳借的这一部分中出票即可。
那么所有网络出票的信息如何返回到铁路系统中去呢？这变得很简单，只需要更新驳借的票的身份信息即可（即由谁订了驳借的票），并且可由一两台服务器在后端进行处理。
由于订票量大，所以订票系统需要采用分布式架构和车次分流架构（车次分流可参考相关章节）。分布式架构可采用形式较多，比如按车次分流后各自独立数据库，在订票产生后由后端的服务器来归并计算订票情况。
支付回馈系统(payback.hcpxxxxxx.cn)
支付系统本应该是一个最简单的系统，但是由于支付后银行的系统需要回馈订票系统某订单支付是否成功，这也给订票系统产生了压力。那么对回馈系统构建独立架构也是必不可少的，否则回馈不成功，则系统认为没有支付，就产生了目前付了款，但没了票的情况。支付流程大概如下图所示，显然现有系统在支付回馈中出了问题，归根到底还是订票系统崩溃或是无法响应所至。但相对于整个系统来说支付回馈的请求量远少于余票查询系统的访问
短信确认系统
短信确认系统由订票系统使用，因此不存在请求上太大的压力，但是构建短信队列是必要的。并且实时性要求并不高。
以下信息并非高访问量的系统可以构建完全的静态和客户端计算模式的系统。
火车时刻查询
正晚点查询
客票代售点查询
铁路转程查询
火车车次分流
由于火车车次间相对独立性，因此使用基于车次进行分流是一种可行的措施。比如：T1~T1000采用A服务器、D1~D100采用B服务器，这样来进行分流。由客户端（用户计算机）来决定使用哪一个服务器提供服务。这样在订票时对服务器的压力可以大大减少，同时可以无限制的扩展服务器以实现无限的分流。
比如可以这样安排服务器：
T1~T1000订票自动转发到：t1_t1000.hcpxxxxxx.cn。
D1~D100订票自动转发到：d1_d100.hcpxxxxxx.cn。
这样的决定并不需要服务器来计算，而是由访问者的计算机在网页中就可以决定。即在什么服务器上进行出票。
仅增加带宽并不能解决本系统的高吞吐量
总结 个人觉得带宽绝对不是本系统访问缓慢的原因，而是后端的数据库、应用服务器响应缓慢所至（因出错后有比如系统忙的提示或是由CDN返回的超时错误）。
但具有较高的带宽也是建立高吞吐量系统的重要因素之一。
应用高速缓存快速响应
