12306网络订票系统分析

12306网络订票系统

分

析

报

告

班 级 2011211306

学 号 **********

姓 名 门鑫

摘要

由于市场客运的刚性需求和互联网的普及以及信息化时

代的到来，12306网络订票系统在铁路客运系统中扮演着越

来越重要的角，成为了越来越多的人的订票方式，该系

统的稳定运行也是人们能够方便出行的保障。而由于铁路

运力的限制，越来越多的人不得不“抢票”。据统计，

12306网站最高有 日均14亿的点击量 ，这“12306”迅速

也使得12306成长为网界上最繁忙的网站之一，14亿次的

点击大军，直接导致了12306系统的崩溃。

对12306系统的分析和研究，有助于我们吸取其经验教

训，总结成功经验。对网络订票系统进行优化，构建一个

可靠的网络订票系统满足市场的需求，为用户提供一个方

便可靠的订票平台。

目录

摘要

……………………………………

1 12306系统概述………………………………

2用户特点分析……………………………………

3 系统架构分析………………………………

4常见问题及解决方案分析………………………………

5 经验及教训…………………………………………

6 总结…………………………………………

1.12306系统概述

中国铁路客户服务中心（英语：Sinorail Customer Service Center），

俗称12306网站，是中国铁路总公司下属的信息服务网站，基于中国铁道科学

研究院所设计的“铁路客票发售及预订系统”创建。客户通过登录本网站，可

以查询旅客列车时刻表、票价、列车正晚点、车票余票、售票代售点、货物运

价、车辆技术参数以及有关客货运规章。铁路货运大客户可以通过本网站办理

业务。

该网站于2010年1月30日（2010年春运首日）开通进行试运行。用户在

该网站可查询列车时刻、票价、余票、代售点、正晚点等信息 。售票系统在

[2]

北京时间每天23:00至次日7:00进入维护，期间不提供服务。

2011年1月19日（2011年春运首日），中华人民共和国18个铁路局（公

司）所在地也分别成立了铁路客户服务中心，并公布了。

2013年11月20日，12306新增支付宝支付通道。

[3]

2013年12月6日，改版后的12306网站上线。新版网站增加了自动查询、

自动提交订单、有票提醒等功能，但是并未增加之前流传的自主选座等功能。

2013年12月8日，12306手机客户端正式开放下载。

2014年7月10日，昆明铁路局试行网购车票快递服务。旅客使用二代居民

身份证在网站购票且不晚于列车开车前36小时的，可自愿选择办理车票快递服

务。 服务区域内暂定每件收费17元，在网购车票时与票款一并支付，每件不

超过5张车票，且限一个地址。车票送达时，收件人凭乘车人的二代居民身份

证原件（可自动识读）接收车票

该系统在高度信息化的今天也成了越来越多的人主要的订票方式，越来越

多的人选择了网络订票，而飞速增长的用户数量也使得12306成为世界上最繁

忙的网站之一，甚至访问量远远超过了淘宝京东等国内知名电商平台，而这也

在某种意义上意味着12306要面临更大的挑战.

首先整个售票系统是一个非常庞大而复杂的系统，是一个高负荷、高并发

的云平台，其规模甚至比淘宝大2至3倍，而且对于数据的实时性要求非常

高。光是12306网站系统的日访问量达到了15亿次，如果加上各个代售点和车

站售票系统，则高峰时段数据访问层的并发量在千万级别。如此大的访问和并

发量，必然要求系统具有非常高的稳定性和健壮性。

2用户特点分析

按照铁道部公开的数据，12306注册用户大约在5000万，日访问PV大约在

10亿，每日网上订购票大约在500万

由于铁路购票的特殊性，该系统不同于普通的电国商平台，其用户数量在

不断增长，而且用户需求为刚性需求具体有以下两个特征：

1.用户查询的需求远远大于订票的需求（用户总是先查询再购买）

2．定时发票可能催生秒杀，访问量瞬时上升（如春运抢票之类的客运高

峰）

正是这几点特点将12306系统同其他电商平台区别开来，首先铁路购票的

性质就和购物不太一样。虽然从表面上看都是一种购买请求与金额交易的过

程。事实上，人们对于火车票的需求要比对于网上购物的需求更加强烈，而且

根据铁总放票的时间来看，访问的高峰基本就在放票的前后十几分钟。这对于

整个购票系统的承载能来来说无疑是一个非常巨大的挑战，我们可以假设，双

十一当天所有的买家都在前后十分钟涌入进行购买付款的操作请求，那么阿里

巴巴的系统不免也要经历一次大 的考验。

系统架构分析………………………………

12306网络订票系统是在铁道部原有的联网售票系统基础上开发的，所以其

原有的数据架构很关键，它直接影响到整个系统的扩展性和稳定性。如果整个

系统全部进行重构那将是非常庞大的工程，这不仅涉及到整个架构的重新设

计、服务系统开发，还有一个更繁重的工作就是所有火车站的售票系统和代售

点系统都将全部升级，正是因为12306是在原有的架构上增加和扩展的，所以

才有了目前的种种问题。

总体架构

首先此应用是一个云平台的典型应用，系统按云平台的思想分层设计，从

上而下分为三层，即：应用层、数据访问层、数据层。每一层之间是松散耦

合。合得每一层具有很强的扩展性和伸缩性。每一层内部都是基于集技术，

分组部署，每一组处理单元都是即插即用，可根据计算压力动态扩充，其大致

的结构如下图：

应用层：主要是指各种售票和订票系统，主要有三种，如车站售票系

统、代售点系统及12306网络订票系统。其中前两个是C/S结构的应用，后一

个是B/S应用模式。其客户端应用服务器之间增加一个负载均衡服务，这有利

于系统的并发，可以有效地根据当前用户量和访问情况自动地分配相对压力较

小的服务器。

数据访问层：主要是将业务应用与底层数据库之间的操作接口专门独立

出来，业务应用访问数据不是直接访问数据库，而是通过数据访问层进行间接

地访问和操作。这样的好处是可以解决数据访问的并发瓶颈，可以根据系统的

压力情况动态地调整和部署访问层。

数据层：根据车次和地域将车次的余票信息分别存储在很多个数据中心

上，每一个数据中心是一组服务器。这样将众多的并发用户根据查询车次分散

到多个数据中心上去。从而降低单点压力，提高整体的并发性能。如果数据访

问是一个大瓶颈则可增加数据中心的节点而减小数据中心的粒度（也就是每个

数据中心减少车次数量），可提高数据访问的速度。

详细架构

系统整体按分层架构处理，每一层都是可注册、可插拔的体系，这种架构

的好处是每一层都可以分层优化，而互不影响。并能根据实际运行的情况对并

发和访问量过大的实体层进行动态扩容，很容易提高系统的并发和稳定性。

此架构很好地解决了应用服务器和数据访问的瓶颈问题，如果应用服务器

压力大则可以通过注册表对应用服务器扩容，并通过负载均衡均衡地访问各个

应用服务器。如果数据访问是一个瓶颈则可增加数据加心的方式来解决数据访

问拥挤情况。

对于数据层系统按车次对所有的车次车票信息进行分组，每一组是一个数

据中心，数据中心的大小可随时调整。这样可以把用户对数据的访问分散到多

个节点上去，从而降低数据中心的压力。每一个数据中心由若干台机器组成，

一台主数据服务器，若干从数据服务器。主数据是用于给用户出票，每一个接

口调用都需要加锁，保证票数数据修改的原子性，其所管理的车次和车票数据

在内存中高速缓存。同时每隔一定的时间周期同步到从数据服务器上，从数据

是用来提供查询的数据副本，它把大量的查询操作分散到从数据服务器上。其

数据访问的流程如下：

常见问题及崩溃案例分析………………………………

总结网上订票系统常见的问题如下：

1、 高峰时段无法登陆，提示在线用户过多

2、 订单提交成功之后，支付环节出了问题，浏览器意外退出，

后再登陆，发现登陆不上，无法在规定时间内完成支付，购票失败

3、 订单提交反馈时间过长，热门线路需要等待20分钟甚至更长

时间，才能得到反馈

4、 验证码输入总是错误，无法完成验证码验证环节，无法登陆

5、 逢用户高峰，网站反应速度较慢

6、 对多浏览器支持不好。

以上问题多数都是用户体验的问题，用户体验的问题即有票源稀少

的原因，更多的是对订票系统使用过程中系统登陆困难，反应迟钝，订

单结果反馈太慢，意外退出等问题难以忍受。

常见问题原因分析：

问题1，高峰时段无法登陆，提示在线用户过多；

问题4，验证码输入总是错误，无法完成验证码验证环节，无法登陆

无法登陆的问题，其原因显然是前端用于处理WEB连接服务器太少或网络

带宽不足所至，为了不让更多的用户一起连接服务器导致服务器较慢，只好拒

绝一些用户的登陆请求。使同时在线人数保持在一个上限以内。验证码输入总

是错误的问题，原因也是用于处理WEB连接服务器太少所至，为了防止一些客

户端使用“恶意”软件，不断自动登陆的情况，验证码需求由客户端向服务器

提交一个验证请求，可以由于服务器响应实在太慢，以至于整个响应速度居然

超过了验证码的有效时间。

问题2：订单提交成功之后，支付环节出了问题，浏览器意外退出，后

再登陆，发现登陆不上，无法在规定时间内完成支付，购票失败

问题3：订单提交反馈时间过长，热门线路需要等待20分钟甚至更长

时间，才能得到反馈

问题5：逢用户高峰，网站反应速度较慢

问题3，问题5，可能是由于WEB服务器与逻辑处理服务器在同一台机

器上，而导致服务器CPU分配了过多的时间与资源在处理用户请求，在执

行逻辑时执行缓慢。

总结以上问题，其解决方案建议如下：

1、 准备更多前端WEB服务器，解决WEB前端的问题没有别的办法，只能

加服务器，或者每个省市放一单独的服务器，根据用户量进行增加，直到

响应流畅为止。

2、 可以考虑把逻辑服务器单独分离出来，与WEB服务器分开，WEB服务

器只处理WEB请求，逻辑服务器单独运行

3、 把数据库服务器单独分离，并且把火车票票量数据库与用户订票信息

数据库放到不同的机器上，由于大量的订票请求会访问火车票票量数据库，

并且会有大量订票数据添加到用户订票信息数据库中，在处理添加的逻辑占

用了大量的数据库资源，会导致整个系统变慢。如果放到同一台机器上，必

然导致响应变慢。把不同性质的数据，放到不同机器、不同的数据系统中，

可以合理的分流系统访问量，使系统响应加快，横向扩展更具有弹性。

4、 把支付订票费用放到一个单独的网站进行，订单提交成功后锁票，之

后根据订单号可以在另外一个单独的网站上进行单独支付，支付时只要提供

订票号就可以，这样做有很多好处：

1. 避免了由于支付失败而导致退出浏览器，却由于在线人数过多无法登陆

导致订票失败的情况，

2. 电话订票也可以在此支付，在火车站机自动售票机器上取票，这样支付

方便，也解决了异地付款取票的问题

3. 单独支付会在一定程度上给订票网站减轻访问与处理压力