12306网络订票系统分析_图文析报告班级 2011211306学号 2011211261姓名 门鑫摘要由于市场客运的刚性需求和互联网的普及以及信息化时代的到来，12306网络 订票系统在铁路客运系统中扮演着越来越重要的角色，成为了越来越多的人的订票 方式，该系统的稳定运行也是人们能够方便出行的保障而由于铁路运力的限制， 越来越多的人不得不“抢票”据统计，12306网站最高有日均14亿的点击量， 这“12306”迅速也使得12306成长为网界上最繁忙的网站之一，14亿次的点击大 军，直接导致了12306系统的崩溃对12306系统的分析和研究，有助于我们吸取其经验教训，总结成功经验对 网络订票系统进行优化，构建一个可靠的网络订票系统满足市场的需求，为用户提 供一个方便可靠的订票平台目录摘要„112306系统概述„„„„„„„„„„„„ 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个铁路局（公司）所 在地也分别成立了铁路客户服务中心,并公布了服务热线[3]2013年11月20日, 12306新增支付宝支付通道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网幷勒亍至坦尊据產"X. >f '"严/ \ / If 報懈申心1 跚B中认 姣嶠书心n应用层:主要是指各种售票和订票系统，主要有三种，如车站售票系统、代售 点系统及 12306 网络订票系统。
其中前两个是 C/S 结构的应用，后一个是 B/S 应用 模式其客户端应用服务器之间增加一个负载均衡服务，这有利于系统的并发，可 以有效地根据当前用户量和访问情况自动地分配相对压力较小的服务器数据访问层:主要是将业务应用与底层数据库之间的操作接口专门独立出来， 业务应用访问数据不是直接访问数据库，而是通过数据访问层进行间接地访问和操 作这样的好处是可以解决数据访问的并发瓶颈，可以根据系统的压力情况动态地 调整和部署访问层数据层:根据车次和地域将车次的余票信息分别存储在很多个数据中心上，每 一个数据中心是一组服务器这样将众多的并发用户根据查询车次分散到多个数据 中心上去从而降低单点压力，提高整体的并发性能如果数据访问是一个大瓶颈 则可增加数据中心的节点而减小数据中心的粒度（也就是每个数据中心减少车次数 量），可提高数据访问的速度详细架构系统整体按分层架构处理，每一层都是可注册、可插拔的体系，这种架构的好 处是每一层都可以分层优化，而互不影响并能根据实际运行的情况对并发和访问量过大的实体层进行动态扩容，很容易提高系统的并发和稳定性1t艷据中心Inn11-'Ut']_Js 用 J® 軒 fit J ■_订氐衷■JW搦j—— ■—.-亢注爲n穷■罚矿岡賣fl111 u nB=l?'援口用茹曙 LJf~!涯瞬疋>■-—从數期，MJ&拐此架构很好地解决了应用服务器和数据访问的瓶颈问题，如果应用服务器压力 大则可以通过注册表对应用服务器扩容，并通过负载均衡均衡地访问各个应用服务 器。
如果数据访问是一个瓶颈则可增加数据加心的方式来解决数据访问拥挤情况对于数据层系统按车次对所有的车次车票信息进行分组，每一组是一个数据中 心，数据中心的大小可随时调整这样可以把用户对数据的访问分散到多个节点上 去，从而降低数据中心的压力每一个数据中心由若干台机器组成，一台主数据服 务器，若干从数据服务器主数据是用于给用户出票，每一个接口调用都需要加 锁，保证票数数据修改的原子性，其所管理的车次和车票数据在内存中高速缓存同时每隔一定的时间周期同步到从数据服务器上，从数据是用来提供 查询的数据副本，它把大量的查询操作分散到从数据服务器上其数据访问的流程 如下:rt鼻 T常见问题及崩溃案例分析„„„„„„„„„„„„播IR樂次号进行怅谨社测常也” 幻数播中住灼旳 4 去可埋存l皿电&肯牛HJt- 』 社祈在丙石绅擁藕 L ^― J 阁團应涉咖t库可恿现妙渤山出丸■・同謹9V出HIL・《l总结网上订票系统常见的问题如下: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. 单独支付会在一定程度上给订票网站减轻访问与处理压力u ^勺电/X 士人"IJ ””””””””””””””””回顾总结12306网络订票系统的不足。