12306网络订票系统分析

12306网络订票系统

分

析

报

告

班 级 2011211306

学 号 2011211261

姓 名 门鑫

摘要

由于市场客运的刚性需求和互联网的普及以及信息化时代的到来，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. 单独支付会在一定程度上给订票网站减轻访问与处理压力

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

回顾总结12306网络订票系统的不足之处和先进的技术及理念，12306在系统架构设计经验不足的情况下完成了网络订票系统的构建，其付出的财力物力人力是不可否认的，

克服的困难也是有目共睹的，就当下来看，虽然系统几度瘫痪但是都能在短时间内恢复，而且考虑其客户的特殊性和访问特点，系统能够满足基本的订票需求已经实属不易，由于客户特点所以与其他电商平台没有对比意义。该系统的成长过程也给了我们很多成功的经验同时也让我们吸取了很多的教训：

1：开发初期应当 给系统留出足够的升级空间，12306后期屡次升级未能从根本上

解决问题就是因为早期的数据结构和系统架构限制，如果早期能够考虑到系统升级的话，采用比较好的数据结构或者架构，或者留有升级空间的话，后来升级就可以大展拳脚，大刀阔斧的去解决相应问题。

2.系统开发应当充分考虑主要用途和主要矛盾，根据主要矛盾有针对性的设计系统，应当考虑到12306和普通电商平台的不同，从而设计出适应12306特色的架构系统，而不是随主流，利用已有的技术和概念（但不适合自己的平台）构建一个大众化的没有针对自己特色的平台。

3.运行维护阶段应当充分考虑每个细节，比如12306曾经因为空调的问题崩溃过一次，除此类物理方面的细节之外还应当做好数据方面的维护工作，比如系统整体的实时状态监控，包括各种角色的应用主机的监控、网络设备的监控、用户访问流量的监控、服务可用性监控、安全监控等系统巨量的交易数据转储、交易日志的转储问题。

4 .数据安全，信息时代数据永远是最重要的，一个好的系统必须保证用户数据包括系统产生的数据足够安全，由于对数据安全重视不够，12306前段时间发生了用户数据泄露的事件，在社会上引起轩然大波。也引起了12306对数据安全的重视。

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

12306网络订票系统给了我们足够多的教训，同时我们也有了相应的经验，希望在其他的大型系统构建上我们能够吸取经验教训，设计出一个出色的系统。

通过对12306网站的分析，其不足和失败的经历固然有技术上的问题，但从某种意义上来说已经做的足够出色，之所以该系统会有如此突发的访问量，造成系统瘫痪，其本质原因还是铁路运力不足，票量不能满足大众的需求所致，假使有1000张票，而只有900人有出行需求，就不会有成千上万的抢票大军守在电脑旁等待“攻击”12306。如果不能从根本上解决铁路运力问题，解决12306系统崩溃的问题将成为天方夜谭。因为再高的科技也架不住巨大的访问量（想象一下全国人去12306抢一张票的情形）。

因此，解决12306的窘境必须从两方面入手，一方面从技术方面不断的优化设计，升级系统，另一方面必须提高铁路运力问题，解决根本矛盾！