浅谈12306的架构设计

既然有人问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订票系统云架构

一、引言

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

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

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

二、总体架构

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

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

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

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

三、详细架构

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

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

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

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

如果我是12306架构师

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

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

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

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

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

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

焦点四：高并发系统软件层要做哪些工作?

软件层将直接决定整个系统应对高并发的能力，其将应用服务器与数据库、存储结合成为一个有机的整体，使数据在这些IT设备之间传输……

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

爱华网本文地址 » http://www.aihuau.com/a/25101013/185246.html