铁道部 12306 网站的设计最近颇招非议，除了成本高昂之外，设计不透明，交付产品看起来粗糙，订票流程问题多多，铺天盖地的非议就出来了。但是我们可以想象，即便是再糟糕的一个系统，也一定有大量的人员在投入探讨他们的解决方案。在 ITPUB 论坛上，看到一些知情人士的记录，可以一窥这个网站背后的一些真实情况。

    本文实属摘录，主要来自网友 yulihua49 的记录，以下最初的讨论内容来自2012年1月，现在情况应该已经有了一些的不同。

    1.数据库与平台

    12306的架构比较复杂，基本售票系统是SYBASE，网络订单数据库是ORACLE。

    最初性能低下的原因不在数据库，而在安全网闸。

    原来一个网闸处理全国业务成了瓶颈，将来每个局一个网闸和一个出口带宽，有望缓解。

    铁科研那帮人搞了这么多年的大并发处理，经验还是有的。能想的办法都想了。

    关键是SYBASE不给力，换ORACLE难了，全是存储过程，移植到ORACLE，前几年试过，不敢上线。

    但就一般情况来说，数据库还不是瓶颈，仅仅在某些极端状况下是数据库。

    网售更不是数据库瓶颈，网闸那儿档着，请求都进不来，数据库根本不忙。

    有人，还号称是专家，说关系数据库不灵，要用TPF什么的劳什子，更是屁话，在相同配置下TPF比ORACLE慢几十倍，试过的。

    2.关于网络订票只能买到上铺的说法

    关于订票分配的规定： 一张：中，2张：上下，3张：上中下。

    但是实际，卖乱了，就乱七八糟碰运气了。

    窗口可以选铺别，有时为了多完成收入指标就先把下铺卖光了。 网售在窗口之前，还不至于被抢光

    3.关于前期开发和设计

    人员就是清华的一帮。网站开发是铁科院和清华易程竞标，清华没中标。 他们想用IBM的TPF，就是航空订票的那个60年代的东西，太古老了。实际上根本不适用。 95年IBM就找到我们推销TPF，被我们否了，09年又来了，撺掇易程。5个人花了3个月，测了一下，根本不成。

    4.关于Oracle数据库

    关于基本订票系统Oracle替换Sybase，铁科院试过了，可以但是不敢用。

    一个是已经买断了SYBASE的版权，再花钱买ORACLE，给个理由，领导说。

    一个是大规模的移植和培训。

    一个是谁也不敢说不出娄子。

    SYBASE用了10年刚刚使系统稳定下来。谁敢说改ORACLE能稳定？

    16年来，几代人在SYBASE上写了数千个存储过程。没人知道那个有用那个已经过时了。

    后来问了一下铁科院，存储过程可以查孤儿，所以没用的都剔除了，但是常剔常出，还是有。 另外剔除孤儿很危险，如果一个应用在SQL里写了一个调用孤儿的就。。。。。。

    以上的讨论清晰的说明了一些问题：

    1.铁路的基本订票系统，使用的是Sybase数据库，评估过Oracle，但是没有彻底替换的决心；

    2.12306网站的订单系统使用的是Oracle数据库，2012年初的主要问题出现在网闸上，数据库端压力不大；

    3.现在12306的问题体现在排队上了，问题已经转移。

    ITPUB 讨论链接：  http://www.itpub.net/thread-1565638-1-1.html

建议继续学习：

1. 由12306.cn谈谈网站性能技术    (阅读：4663)
2. 用 redis 实现和保护 12306    (阅读：4445)
3. 铁路订票网站个人的设计浅见    (阅读：3612)