eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Oracle Kernel : Function kglic & Library Cache Latch | Blog首页 | Oracle Database 12c 将至与新特性介绍 »

关于 12306 网站设计的一点信息收集
modb.pro

铁道部 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



历史上的今天...
    >> 2009-09-24文章:
    >> 2008-09-24文章:
    >> 2007-09-24文章:
    >> 2005-09-24文章:
           Oracle OpenWorld 2005

By eygle on 2012-09-24 17:32 | Comments (0) | OraNews | 3047 |


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com