浅谈铁道部12306火车票网络订票系统的架构设计 12306铁道部火车票网

浅谈12306的架构设计

2012-01-11 11:04

既然有人问12306这种网站如何设计,我不才,来简单说几句。

忽悠之前先来了解一些基本现状。

1. 按照铁道部公开的数据,注册用户大约在5000万,日访问PV大约在10亿,每日网上订购票大约在500万

2. 每一个个人用户的数据都是独立的,不会和别人共享

3. 每一个铁路局(全国18个铁路局)下管理很多小的车站,每一趟车票的数量控制基本上有其所属的铁路局分配

4.每一个用户的数据非常有限,由于是新上线的网站,平均应该在2张以下(到目前为止应该还没有卖出1亿张票),我们以最大估计没人平均在10张左右

5.比较耗时的操作应该集中在支付对接(不排除要求银行提供更有效的接口)

6.用户查询的需求远远大于订票的需求

7.定时发票可能催生秒杀,访问量瞬时上升

基于以上事实,以下给出几点主要的建议:

1. 业务拆分,资源拆分

对于和订票无关的业务以及资源,例如帮助、政策、新闻、静态资源等等拆分成不同的子域名,减低主域名的干扰以及压力。

业务的拆分可以分成注册、查询类(一些固定资源的查询也可以CDN的,比如车次、时间、车站等等)、交易类、支付类、其它静态类等业务。

现状是一旦网站访问慢时,访问任何资源都非常慢。

拆分成子域名后还可以有效提高浏览器加载css/js的并发量数量。

2. 提高CDN的效率

业务拆分,资源拆分后,与个人无关的所有访问资源都应该纳入CDN,充分利用CDN加速的效果。尤其是js以及CSS这一块,CDN需要承担上99.99%以上的访问量。降低后台服务器的压力。

事实上对于个人而言,除了查询、订票以及支付外(注册的访问量是一次性的,独立拆分就好了),大部分内容都是可以走CDN的。

现状是CDN商为了提高流量,基本上没有发挥出CDN的效果。

3. 数据库拆分

按照铁路局或者省份拆分数据库,访问量高的铁路局或者省份可以多拆分几个数据库。这可以极大降低数据库的压力。一个简单的原则是这些数据基本上是不共享的,而且只有个人查询的需求。不存在跨省、批量查询等需求。

如果按照oracle或者db2的性能,按照写数据那点量是一点问题都没有的。而且对于个人来说一旦一张票支付成功,基本上也不会查看,因此可以定时归档,数据库的数据量也是非常小的。

对于个人而言,按照身份证号码的所属或者尾号等等拆分即可,也降低个人数据的数据库压力。

4. 数据缓存

目前12306的需求是数据缓存10分钟(主要指余票的数量),因此应该大量增加Cache的利用率。例如memcache/redis甚至业务拆分好的话,本地cache也不是不可以的。

而且,如果充分利用nosql的特性的话基本上可以做到数据实时性,不需要缓存10分钟降低用户的体验(提交订单最后一刻总是失败查询却总是有票是令人很崩溃的)。

主要的数据缓存应该集中在车次以及余票上,其它的数据缓存问题都不大。

即使穿透了缓存,最终也要靠数据库的事务保证逻辑的正确性。

5. 用户体验

这年头还是用iframe的体验简直烂到家了。

虽然极少量使用了ajax,但是基本上也没有发挥出威力。即使一次ajax请求也请求了大量无关的资源,造成大量的网络带宽浪费。

为了提高效率,最重要一点就是大量提高ajax的访问量。不仅降低服务器的压力,也要减少传输的耗时。这一块怎么也得专业一点吧。

一个用户登录进去以后的动作其实非常简单,只需要查询、下订单、支付几个步骤,而且绝大多数集中在查询操作上,因此如何降低用户查询的成本、提高查询的用户体验远远比换一个好看的皮肤重要的多。

数据传输这一块应该大量使用json而不是笨重的xml。js对json的支持远远比xml要容易得多,而且json数据量更小更轻便,后端生成json的成本也更低。毫无疑问,使用xml不是一个明智的选择,尤其对于高访问量、大数据库传输。

6. 流量控制

流量控制非常重要。有效的控制流量可以降低并发的数据量,降低服务器临时崩溃的可能性。将压力平摊到各个时间段远远比在短时期内消耗掉要安全得多。

验证码是一个比较好的措施,只是目前有两个缺陷。很多地方的验证码只是在前端做了限制,如果不传输验证码后端也允许通过(难道这是他们为了内部方便测试留的)。这导致大量的工具绕过验证码登录了。第二点,早期的验证码非常简单,导致大量的工具能够自动识别验证码。尽管这些工具的识别率不高,但是由于工具重复操作,造成了大量无用的性能浪费以及流量浪费。真正有需求的人反而没有机会操作。

首先,后端增加验证码的逻辑。无效的访问请求很快就过滤掉了。

其次,验证码不要和session绑定,直接使用单向加密算法传输即可,简单快速。

再次,验证码做得智能点的话可以根据访问量逐渐提高复杂度,甚至不惜动用中文未尝不可。增大ocr识别的成本。

最后,极端情况下控制访问人数是有必要的,但是应该保证能够查询这种基本操作。

7. 支付与安全

其实对于这种业务比较单一的系统,实现起来还是比较容易的。稍微麻烦点就是与银行的对接以及事务的控制。

12306最后和银行的对接还比较少,主要是和银联合作。况且,以这种优势地位,需要什么样的接口还不是人家乖乖提供的。

一旦订单提交成功后就锁定票,等待用户支付。支付操作的压力基本上定向到银行以及银联的支付网关了。另外按照每天500万票来算,每秒钟的压力是非常小的。

有点麻烦的可能就是支付失败或者中间某个环节失败后事务如何回滚的问题。毕竟这需要保证用户的资金安全的。

其实有统一的支付网关接口,操作起来是非常简单的。大部分提交应该都是能够在一个事务内完成的。极端情况下如果有部分操作失败,应该立即将这些操作提交到后台,进行人工审核和处理。而且对于人工来说也无非几个操作,是否扣款(查询支付网关)、是否出票(查询出票记录),然后对比下是否需要退款或者退票等。

8. 流程控制

最后规划化上线流程非常必要。不至于在线调试代码的情况发生。

基本的操作规范都没有,如何保证代码的质量以及系统的可靠性。

网上的戏言是这只是某个学院学生的作业。可见网站的整理水平确实过于低下,没有规范的流程控制,怎么方便怎么来,没有风险意识,更没有问责机制。

按照一般体制内的要求肯定是过了测试流程的,同样肯定也是走走过场的。显然没有进行过多的压力测试和性能测试。代码的质量也不高,基本的业内规范都没有遵守。

再好的想法和规划,没有规范的流程最后还是会打水漂的。

最后合理的规划业务逻辑是必要的,仅仅靠技术和架构是不能解决所有问题的。充分利用CDN加速、负载均衡、业务拆分、nosql加速、有效的安全机制等措施,保证系统在瞬时能够抗住巨大的压力,同时能够平稳处理用户需求。

对于这种简单业务逻辑的系统是非常适合进行扩展和优化的。

一句话:铁道部给程序员的钱不够!!!

大话铁道部12306订票系统云架构

分类:随笔杂谈2013-01-19 23:01 1091人阅读 评论(14)收藏 举报http://blog.csdn.net/xsc2001/article/details/8521069

一、引言

随着春节的临近,大家都忙着从网上刷票,随之而来的就是对12306订票网站的质疑声。今天就针对这个问题和朋友还讨论了一番,有感于此,本人从技术的角度对此进行分析并对整个系统的架构进行了一下重构构想。

首先整个售票系统是一个非常庞大而复杂的系统,是一个高负荷、高并发的云平台,其规模甚至比淘宝大2至3倍,而且对于数据的实时性要求非常高。光是12306网站系统的日访问量达到了15亿次,如果加上各个代售点和车站售票系统,则高峰时段数据访问层的并发量在千万级别。如此大的访问和并发量,如果没有好的架构设计肯定保证了不系统的稳定性和健壮性。

其次,本人觉得12306网络订票系统是在铁道部原有的联网售票系统基础上开发的,所以其原有的数据架构很关键,它直接影响到整个系统的扩展性和稳定性。设想一下如果整个系统全部进行重构那是多么庞大的工程,这不仅涉及到整个架构的重新设计、服务系统开发,还有一个更繁重的工作就是所有火车站的售票系统和代售点系统都将全部升级,至于12306网络订票系统肯定不会出太大的问题,但是对于车站售票系统可是一个很大的考验,不能有半点的闪失。因而我想铁道部也不会冒这个风险。正是因为12306是在原有的架构上增加和扩展的,所以才有了目前的种种问题。如果一切从头架构反而好多问题迎刃而解。

二、总体架构

这里我就对这个新的系统架构做一个详细的设计,首先要认清此应用是一个云平台的典型应用,系统要按云平台的思想分层设计,从上而下分为三层,即:应用层、数据访问层、数据层。每一层之间是松散耦合。合得每一层具有很强的扩展性和伸缩性。每一层内部都是基于集群技术,分组部署,每一组处理单元都是即插即用,可根据计算压力动态扩充,其大致的结构如下图:

应用层:主要是指各种售票和订票系统,主要有三种,如车站售票系统、代售点系统及12306网络订票系统。其中前两个是C/S结构的应用,后一个是B/S应用模式。其客户端应用服务器之间增加一个负载均衡服务,这有利于系统的并发,可以有效地根据当前用户量和访问情况自动地分配相对压力较小的服务器。

数据访问层:主要是将业务应用与底层数据库之间的操作接口专门独立出来,业务应用访问数据不是直接访问数据库,而是通过数据访问层进行间接地访问和操作。这样的好处是可以解决数据访问的并发瓶颈,可以根据系统的压力情况动态地调整和部署访问层。

数据层:根据车次和地域将车次的余票信息分别存储在很多个数据中心上,每一个数据中心是一组服务器。这样将众多的并发用户根据查询车次分散到多个数据中心上去。从而降低单点压力,提高整体的并发性能。如果数据访问是一个大瓶颈则可增加数据中心的节点而减小数据中心的粒度(也就是每个数据中心减少车次数量),可提高数据访问的速度。

三、详细架构

系统整体按分层架构处理,每一层都是可注册、可插拔的体系,这种架构的好处是每一层都可以分层优化,而互不影响。并能根据实际运行的情况对并发和访问量过大的实体层进行动态扩容,很容易提高系统的并发和稳定性。

此架构很好地解决了应用服务器和数据访问的瓶颈问题,如果应用服务器压力大则可以通过注册表对应用服务器扩容,并通过负载均衡均衡地访问各个应用服务器。如果数据访问是一个瓶颈则可增加数据加心的方式来解决数据访问拥挤情况。

对于数据层系统按车次对所有的车次车票信息进行分组,每一组是一个数据中心,数据中心的大小可随时调整。这样可以把用户对数据的访问分散到多个节点上去,从而降低数据中心的压力。每一个数据中心由若干台机器组成,一台主数据服务器,若干从数据服务器。主数据是用于给用户出票,每一个接口调用都需要加锁,保证票数数据修改的原子性,其所管理的车次和车票数据在内存中高速缓存。同时每隔一定的时间周期同步到从数据服务器上,从数据是用来提供查询的数据副本,它把大量的查询操作分散到从数据服务器上。其数据访问的流程如下:

作者微博:http://weibo.com/1879501984

如果我是12306架构师

  12306,因为系统问题,成了IT业界内大家茶余饭后经常谈论的话题。  先分享一个真实故事,我同事看了12306这个网站,他说,这个网站做下来只要5万,我反驳,被他嘲笑。笑话终归笑话,没有讽刺铁道部,以及12306研发方的意思,我同事是实习生,他不懂12306。  近日,我们在一个技术群里讨论了一个开放式话题:如果我是12306架构师,该怎样设计系统架构?  讨论的内容太多,我只将讨论的最终结果做些简单梳理,并在我的blog:zouhui.blog.51cto.com上与大家分享。  背景:12306,需要解决的一个核心问题是,千万级并发的问题。同时,12306应该有自己的特色,与新浪的千万级PV很不一样。根绝目前12306的业务,12306对带宽的要求其实并不大。  架构:与其他大型网站一样,需要采用分布式设计。  前端应该有CDN,尽量将静态内容放到这一级,并配合其他CDN的应用模式;下一级负载均衡应该是DNS,将流量均匀分配到不同的IP;再下一级应该是LVS,将访问请求分发到不同的物理服务器,然后再下一层才是存储层。采用分布式貌似能解决12306的并发问题,为什么12306还是这么慢呢?  瓶颈在哪里?  瓶颈在数据库。尽可能减少到达存储层的访问请求,这才是12306问题的关键所在。  12306底层的数据库应首选Oracle.  我们假设:单数据库+单服务器的方式,用比较好的Unix服务器,使用OCI方式,对于非大字段(clob,blog字段),每秒的入库可以达到10W。  离千万并发还差两个数量级,因此数据库也必须采用分布式。  10万的并发,WebServer有风险,实际单机apache很可能顶不住10W级并发,apache或iis很可挂了。  解决办法:采用N个服务器M个数据库的架构方式。  将服务器与数据库分开,N个服务器皆可访问M个数据库。服务器负责处理不同物理链路上的请求,服务器上采用任务均衡迁移服务,同时负责与各个数据库交互。  感性地认识这个架构,数据库按照地区划分,每个数据库做备分并做warehouse(数据仓库)将不同地域的IP分配到对应地域的服务器集群上,比如10.0.0.x网段的集群负责处理成都铁路局始发的列车订票业务,那么这个网段的集群只需要维护成都铁道部辖区内的始发列车数据即可,对于IP解析与数据分发,需要重写一个LVS分发算法。对于上海,北京,广东这种热门地区,需要做任务迁移处理。  按照以上的架构,大约需要400个数据库,1000台服务器。  最后,对于查票,定票,付宽,多学习支付宝的佳构,对于任务处理,多学习银行的任务分发。  特别感谢本群的:薛定谔的猫,那時花開,/bs暗夜未冥/bs,he,狼鱼,涛涛,等多为朋友对该话题的关注,并积极参与了讨论。  如果你是12306架构师,该怎样设计系统架构?

本文出自 “邹辉”博客,请务必保留此出处http://zouhui.blog.51cto.com/3827922/782379

支招12306 海量高并发网站架构设计经验谈 -IT168

http://www.it168.com/redian/12306hpc/

焦点一:实现高性能高并发系统到底有多难?
每天售票200万张,网站注册用户人数超过1000万,12306日均点击次数超10亿次……

焦点二:与新浪、淘宝等网站并发有何不同?
12306实质上应属于频繁的混合读写操作,而且是小随机频繁读写,公认的难题 ……

焦点三:海量高并发系统架构到底该怎样设计?
IBM软件架构师景文童认为12306 系统应该是一个高性能、高伸缩性、高可靠性系统……

焦点四:高并发系统软件层要做哪些工作?
浅谈铁道部12306火车票网络订票系统的架构设计 12306铁道部火车票网
软件层将直接决定整个系统应对高并发的能力,其将应用服务器与数据库、存储结合成为一个有机的整体,使数据在这些IT设备之间传输……

焦点五:海量高并发系统该如何优化?
经过网友深挖,从12306网站前端的网页设计到后端的数据、缓存、负载均衡、数据分区等一系列问题都提出不同的优化方案,那么……

焦点一:实现高性能高并发系统到底有多难?
每天售票200万张,网站注册用户人数超过1000万,12306日均点击次数超10亿次……

  

爱华网本文地址 » http://www.413yy.cn/a/25101013/185246.html

更多阅读

浅谈我国小微型企业生存问题 我的世界生存战争问题

浅谈我国小微型企业生存问题黎友焕戚志敏发表在《中小企业投融资》2012年第6期作为我国国民经济的重要组成部分,小微型企业的生存状态直接关系着我国国民经济的健康发展。但近年来,受欧美市场萎缩、劳动力成本上升、融资困难等因素

浅谈防止鳄龟在水中产蛋的方法 产蛋箱

浅谈防止鳄龟在水中产蛋的方法近年来,鳄龟养殖得到迅速发展,鳄龟的品种千差万别,不同品种的鳄龟价格不相同。目前养殖户所追求的品种是佛鳄和大黄,因为这些品种的产卵量多,并能到沙地里产卵。根据调查,有人的杂佛和大黄或时也会在水中产蛋

转载 浅谈《水浒传》人物形象的塑造 浅谈个人形象的塑造

原文地址:浅谈《水浒传》人物形象的塑造作者:洪涛浅谈《水浒传》人物形象的塑造内容提要:《水浒传》是我国著名的四大古典名著之一,有许多值得称道的地方,尤其是人物的塑造,使作品具有光辉的艺术生命。全文分引论、本论、结论三部分。

浅谈小学英语教学中学生自主学习能力的培养

浅谈小学英语教学中学生自主学习能力的培养英语教学,不仅要让学生获得英语知识,更重要的是让学生获得自主学习(autonomous learning)英语的能力。而英语教师的任务不仅仅是教会学生英语知识,更重要的是激发学生终身学习的愿望,教给学

c++设计航班订票系统 航空订票系统详细设计

//此航班订票系统由我一同学方辉制作。本人并不喜欢此设计。原因..。//此设计基本实现了系统所要求的各项基本功能。//不及细看。有不足之处,请帮他指正。/July.整理。06.02/。#include<iostream.h>#include<string.h>#include<fs

声明:《浅谈铁道部12306火车票网络订票系统的架构设计 12306铁道部火车票网》为网友的高傲分享!如侵犯到您的合法权益请联系我们删除