畅聊12306，赢精美礼品——已结束

从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？

首先是服务器时间错误问题，数据说话

后续测试发现真正的问题是CDN加速配置以及同步周期有问题，12306想通过CDN来做保障，可谁来保障CDN呢？

测试时间：2013/02/07 上午

测试网址：http://www.12306.cn/mormhweb/

请求数量简单统计

　　　　总计　　HTML　　CSS　 JS　　XHR　 PIC　　 FLASH　

请求数　67　　　1　　　 2　　 6　　 1　　 55　　　2

响应KB　622　　 26.3　　16　　92.4　2.2　 408.6　 76.6

缓存KB　592.7　 26.3　　16　　92.4　0　　 381.5　 76.6

说明：第一次访问 images/tab.png 加载了2次，缓存为第2次加载的统计

　　　静态响应速度还是很快的，不做对比记录

HTTP 响应头信息

* 第一次

HTTP/1.1 200 OK

Date: Wed, 06 Feb 2013 11:19:56 GMT

Content-Length: 11322

Last-Modified: Mon, 10 Sep 2012 08:36:50 GMT

Accept-Ranges: bytes

Age: 1

X-Cache: HIT from cache.51cdn.com

X-Via: 1.1 hnxc9:8361 (Cdn Cache Server V2.0)

Connection: keep-alive

Cache-Control: max-age=36000

------------缓存-------------

Data Size11322

Devicedisk

ExpiresThu Feb 07 2013 09:54:49 GMT+0800

Fetch Count2

Last FetchedThu Feb 07 2013 09:54:50 GMT+0800

Last ModifiedThu Feb 07 2013 09:54:50 GMT+0800

-----------------------------

* 再次

HTTP/1.0 304 Not Modified

Date: Wed, 06 Feb 2013 11:19:56 GMT

Last-Modified: Mon, 10 Sep 2012 08:36:50 GMT

Age: 1

X-Cache: HIT from cache.51cdn.com

X-Via: 1.0 hnxc9:8361 (Cdn Cache Server V2.0)

Connection: keep-alive

Cache-Control: max-age=36000

------------缓存-------------

Data Size11322

Devicedisk

ExpiresThu Feb 07 2013 09:55:33 GMT+0800

Fetch Count4

Last FetchedThu Feb 07 2013 09:55:33 GMT+0800

Last ModifiedThu Feb 07 2013 09:55:33 GMT+0800

------------------------------

* 再次

HTTP/1.0 304 Not Modified

Date: Wed, 06 Feb 2013 11:19:56 GMT

Last-Modified: Mon, 10 Sep 2012 08:36:50 GMT

Age: 1

X-Cache: HIT from cache.51cdn.com

X-Via: 1.0 hnxc9:8361 (Cdn Cache Server V2.0)

Connection: keep-alive

Cache-Control: max-age=36000

------------缓存-------------

Data Size11322

Devicedisk

ExpiresThu Feb 07 2013 09:57:21 GMT+0800

Fetch Count6

Last FetchedThu Feb 07 2013 09:57:21 GMT+0800

Last ModifiedThu Feb 07 2013 09:57:21 GMT+0800

------------------------------

问题：服务器时间不对，比GMT时间小将近13个小时，且几次刷新时间是不变的

定格在 Date: Wed, 06 Feb 2013 11:19:56 GMT，造成浏览器缓存很快过期

刚刚测试发现

问题：服务器时间不对，比GMT时间小将近4个小时，且几次刷新时间是不变的

定格在  Thu, 07 Feb 2013 01:38:04 GMT，造成浏览器缓存很快过期

我实在不明白为什么服务器时间会定格，max-age的失效，会造成浏览器缓存彻底失效。

造成CDN加速资源的浪费，因为不能减少客户端请求数量。

一般应用这也许不会有大问题。但是回家的人理论上是有13亿的。

我立刻明白了正是CDN加速产生的问题，CDN加速把HEAD头照搬了，而且看来更新周期控制的也有问题。

至少在我检测的时候发现了过期未同步问题，如果这个时间控制的不好，那CDN加速就是完全失败的。

我如何做

把服务器时间搞对，可以使用网络授时同步，很简单的配置，而且免费

就目前来说修补CDN加速配置。呵呵，这个要服务商配合了。

如果是我来设计：我根本就不用CDN加速，原因很简单，这是个特定场景需求的应用，

那些静态文件可以预计很长时间内根本不需要更新，所以静态文件max-age设置足够大，比如30天就行了。

如果遇到更新，那更换地址就OK了。

我猜测CDN加速也花大钱了吧，这笔钱剩下来用到动态处理服务器上吧。

动态部分还的动态处理，那必须是时时的。什么加速都没用。不可避免的压力在这里。不过那是另外一个问题了。

一些个人看法

◆ 关于排队系统

  我个人觉得排队系统还是比较合理的，可以分离主干系统的压力。

  当然不应该是现在这个样子的。下列功能应该需要在排队系统中提供。

1. 登录。
2. 设置查询条件，个人信息及付款选项等。
3. 简单查询结果。这个结果不会是即时，而且是简单的。比如根据用户设置的查询条件，锁定几条换乘线路，该线路是否有剩余等等。类似售票处墙上定时刷新的大屏幕。
4. 等待队列即时信息。比如目前有多少人在排队，预计需要等待时间。
5. 自动跳转订票主干系统。

  其中2，3既可以减轻主干系统的压力，又可以让用户在等待时有事可做。

  4也很重要。大家应该也有类似的经验，在时间不可预知的情况下，等待会变得异常漫长。当知道大概的等待时长，并且还看到有那许多人一起在等待，多少会减少大多数人心理上的焦虑。当然我也知道，这只是个改善用户体验，治标不治本的措施。

◆ 关于系统设计

  排队，简易查询，订票这3个系统需要分离。从需求到结构都有很大不同，放一起只会互相干扰。

1. 排队系统。上面提到的那样，基本不需要多大的服务器资源。完全作为业务处理意义上的缓存。
2. 简易查询系统。上面也有提到，无须精确只要明确！由系统后台定间隔，非同期，自动更新。因为没有事务，NoSQL最合适。
3. 订票主干系统。大家都熟悉的那些以外，个人觉得这个系统可以加上限时——比如十分钟！和窗口买票一样，十分钟内选好票，没搞定的回去重新排队！（会有争议吧？）

  1和2重点在大并发请求，3的重点在精确。当然排队时间，简易查询更新间隔及订票限时应该根据系统压力可以调整，而且需要不断的努力以缩短等待和延长限时。（纯官腔？！哈！）
  这个设计有个前提，就是造价是百万单位。上亿？！那还排个毛队，限个毛时！

  最后，竟然是Oracle和Weblogic？！大家可以查查Oracle的授权！咱们大天朝，真有钱！

◆ 关于抢票软件

  抢票软件的目的是正义和善良的，抢票软件的存在是错误和无奈的，这种扭曲恐怕也可以说是我们天朝的特色吧！

  作者有句话，“其实还幻想过，倘若有一天他们发现助手的功能不错，他们也许会直接集成到网站里，然后我就可以不用再去弄了。 ”看着想哭！

◆ 其他想说的话

  当年的奥运订票系统都还记得吧？！也是上来就瘫，瘫了又瘫！但好歹那次是一过性的，还是面向全球的（是吧？！）？！而且靠开幕式闭幕式什么的还能挣点脸回来。这火车订票就不一样了，对几亿人来讲，每年都得折腾上几次的啊！2亿多的老百姓年年受几次这种罪，你们就真的能心安吗？！

  相当同意freish的观点，特别是第一点。
  我不靠谱的说，国家就应该或拆分铁道部或扶持个“地道部”出来。有竞争才有动力，垄断必然失败。
  虽说国情在那里，但是比如移动，联通，电信等等间的竞争还是有那么点点好处的，对吧？比如如果不是两桶油，只有“中石油化”，简直无法想象会如何的不堪！

   至于2，在理是在理，只是好远好大的说。哈。我们现在毕竟是在ITEye上聊不是，除了YY些系统上的事情，还能怎样？

12306在去年国庆之前进行了改版，加入了排队系统，您认为排队系统的增加目的是什么？ 
12306在系统、业务设计上，还存在哪些问题与挑战？ 
通过12306的现状您认为高性能并发系统架构应该如何设计？关键是什么？ 
高性能并发系统技术实现的关键是什么？

一起回答，结论从一步步分析后得出

首先我们要再分析下业务场景，以下几点关键

0. 1.26-3.6日的40天春运，节前15天节后25天

1.运量

   发改委既然预测了，那铁路部门必须完成运送额也就是指标了。2.25亿的一半1.125亿，要在15天里面运送完毕。每天就是750万人次，这与公布的现实信息基本符合。每天750万运量。节前1.125亿。

2.预售期长短直接影响并发量

    大家都想提前买到票，预售是有必要的，过长的预售期那就是高并发的加速器，而且也不现实，因为现实中火车会做调整。

    当然铁老大是很有钱的，也可能人家不怕这个造成的高并发，只要花钱解决这个问题就行，如果真能解决，大众自然高兴。

    因此我们假设20天预售期，因节前15天节后25天，事实上是所有火车客运量全部都满预售了。

3.返程票可以一起购买是个很好的解决节后返程2次高发问题，而且是个友好设计

    很明显，这个受预售期影响。目前没有统计数据，无法分析具体数据量。但是可以预计有相当比例的用户想一起买了返程票，但是你提前20天预售，那大家都在抢票强速度。这就造成这个返程票操作的有效性大大降低。且问题更复杂了，因此忽略返程票问题。

4.对于这么大的业务需求，所有数据结构的设计都是严重影响性能，要认真对待每一项

开始分析

1：从注册开始

    预定火车票是个特殊应用，所有用户都必须提交身份信息和联系信息，也就是身份证号和手机号。这两个是数字信息而且具有固定的数据结构，区域注册量可统计。可根据数据特性直接把用户负载均衡到不同的固定的服务器（数据服务器）。至于是用身份证还是手机号，毫无疑问身份证号更可靠保险。而常规的用户名/邮箱在这个应用中毫无价值。而且制造了麻烦。

    方案：用二代身份证号码做用户注册名和登录名，并且直接负载均衡到固定的服务器中去处理，不同服务器之间不必共享用户信息

2：座次标记中心（简称座标）

    是的我们把这个座次信息独立出来，做成数据中心，里面只包含座次和标记状态，也就是几组数字而已这有多大数据量呢？我们按300亿座次计算（因为站点很多），也就是30G座次单位，那如果每个座次信息需要10个字节（10字节的序号和状态标记足够了），也就300G数据，这不算啥海量数据库。事实上根本用不了这么多。我们就按这个标准来算。这可是结构化非常强的数据，不用特别设计数据库，做个索引，加大内存分配，CURD速度那是杠杠滴。如果特别设计具有内存映射功能的数据库那速度就更快了。

    座标负责什么？就是个总的座次状态标记中心，负责和其他数据负载均衡服务器进行通讯查询，而各个负载均衡数据服务器间根本不必完全同步数据，每个数据服务器操作数据都和这个中心服务器进行标记同步就行了。无论做什么方案这个中心服务器是不可少的，因为她是中心，她的数据是特别设计的，响应速度最快，对整体性能提高有很大帮助。事实上，大量的客户查询是先通过数据服务器的，这个均衡过了，写操作必须又数据服务器同步标记到中心。车次起点和终点确定后，负载均衡到那些数据服务器上也是可以实现分配好的规则。

    方案：中心服务器就是一个简单的座次标记中心，各个数据服务器只和中心同步标记，数据服务器间根本不必做数据同步。

3：具体需要多少数据服务器

    这个根本不用讨论，因为架构清楚了，需要多少服务器那就用多少服务器，这业务量决定的。但是中心服务器只要一组（备份用）足以，因为中心服务器的操作太简单，而且是阻塞型的，最终数据写操作必须阻塞。读取要不要多弄几个？别被750万的数据量吓住，1秒钟也就1000个操作，别忘记大量的操作被负载均衡数据服务器组给过滤了，虽说1000每秒虽然不精确严禁。但是别忘记操作的就是几个字节，在目前的硬件性能下完全没有问题，大内存服务器，高速固态硬盘对这样的项目，那根本就是便宜的很。好吧！你还是担心，那就分10组吧，因为是用序号作为座标的，所以可以直接通过座标计算出数据在那一组服务器上，同样不需要数据同步。

方案综述：身份证号做用户名(并直接均衡到) + (无需同步数据的)数据服务器+中心座标服务器

其他各种常规优化不讨论了，有很多同行早就给出各种建议了。

关于排队：排队是因为你处理不过来，但是排队本身也是新的请求，增大了总体负担。要说目的作用只是在用户心里上的安慰而已。实在是标本都不治的法子。

关于系统设计：12306的设计有公开过真正的技术细节或者架构么？

高性能并发关键：

    那大家都知道如果不用分布式系统，高性能并发必须解决负载均衡的分发和数据同步问题。这两个问题前面的讨论中都有。从技术上讲我的方案不是个分布式系统，也不需要。这是一个直接通过各种数据信息分离存储，再负载均衡，完成任务的方案。

另外：关于CDN加速的问题，我前面的帖子中单独有阐述，总结就是：因12306的特殊性，通过加大静态文件的max-age代替CDN。省下的钱可以用于降低车票也好啊。

高性能并发系统技术实现的关键是什么？

这个可以仿照电信的计费系统，采用商用的内存数据库

有人提议12306采用NoSQL存储，您认为是否可行？

关键数据用NOSQL不靠谱，既无事物特性，又不支持复杂的业务逻辑。可以用的地方只有一些非关键数据的cache，会话

从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？

12306个人感觉做的也挺好了，短短俩年上线就能满足如此高的访问量，这是其他网站做不到的（ps:其他网站都发展了10几年).我觉得可以业务上重新梳理一下

• 将中国分为几个片区，输入是用户从哪儿到哪儿这个信息，类似电信营业厅这样系统，这样能实现分布式
• 允许用户预先充值，这样订票后就直接购买成功
• 加大退票难度，防止用户购买过多重复的票
• 将给与传统售票点的票更多的放给12306网站。

如果以上业务能成立，那重构后的12306网站很容易达到大家的期望

12306技术上的改善已经不错了，但建议不用hibernate，因为此工具容易用的不正确而导致应用系统性和数据库系统同时的性能损耗，毕竟大部分开发者都不是高手。对于效率要求很高的网站，用Hibernate不是明智之举。