奥运门票系统瘫痪，再显数据库软肋

计算机核心技术机密资料《揭开数据库内核的神秘面纱》，免费索取！

引自某网站报道：北京奥运会门票面向境内公众第二阶段预售正式启动。上午一开始，公众提交申请空前踊跃。上午9时至10时，官方票务网站的浏览量达到了800万次，票务呼叫中心热线从9时至10时的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请，为此北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意。

早期论点（发自我内心的论述）：

由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请，为此北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意。 当年的悉尼奥运会计算机服务系统的问题再次在中国上演，盲目相信所谓的商业数据库，世人惯有的数据库至上，数据库万能的思维，再次遭到惩罚。 为什么凡是项目都要用数据库？这一点我一直非常奇怪。在国内，做系统集成的项目（奥运门票销售系统就是典型），都会搭建组件架构，都是拿来主义，用现成的商业工具来组成，ibm，sap,oracel， bea,sybase等公司的数据库，中间件产品成为首选。大的系统集成公司的示范，造成众多其它公司的跟风，乐了国外公司，他们高兴的说，“中国是他们最大的市场”，纷纷在国内建立所谓的研发中心，国人也在高兴。中国整个it走向都在被系统集成这个概念指引着“方向”。 可能有人会说，商用数据库当然性能很高了，为什么要怀疑它们？我在这里说，即使商业关系数据库做的再好，它的固有算法，固有架构也都不适合高性能应用。用一个通用的东西，总不如为项目量身定做一个系统好。 奥运门票销售系统的瘫痪，不是数据库优化没做好，也不是http服务器架构有问题，而是思维方式和技术盲目跟风，不考虑特定情况造成的。

中期论点（语气缓和一些）：

对该报道，我的个人理解是，可能是数据库出了问题。数据库服务器处理不了发过来的数据包，就会造成这种局面，尤其是数据库的事务，锁操作，会造成负担加大。如果数据库的表设计不合理，优化参数没有及时调整，出现这样的问题很正常，不但没有完全发挥数据库的优势，反而展现了数据库的软肋。

本文自10月31日发表以来，受到广大网友的关注，承蒙大家厚爱，在这里表示感谢。

但是本人一直从事高性能分布式系统的设计工作，深深感觉到如果只依靠数据库是很难达到高性能要求的。应该对特定的需求设计特定的算法，特定的数据存储系统等。另外，不要在奥运门票系统中使用很强的关系事务操作，应该尽量弱化事务，甚至可以设计异步系统。在实际的应用中，数据库和其他文件系统或专用服务器软件系统混合使用，实践表明确实也能达到好的效果。无论搜索引擎，数据库还是其它，只要有能在高性能系统上达到好的效果办法，都要“海纳百川”。

后期论点（对国家有关负责人的建议）：

后来奥组委公布，此项目为一家国外公司设计开发，我看后，产生了感慨。国人的科技自信，尤其是在 IT领域一直都非常差。老外的东西一定好，盲目相信老外，最后造成自己吃大亏。就800w这么小的压力就后台崩溃，不根据实际情况，盲目采用数据库技术，没有按照互联网高性能系统设计思想等都是该事件的原因。我国一直强调自主创新，数据库技术已经是非常成熟的技术了，几乎走到了它的最巅峰，发展余地很小。从事物的发展规律看，在新出现的需求中，例如互联网领域，肯定会有更好的技术占据主导地位。对我国来说是一个非常难得的机遇，应该政府出面主导和鼓励“互联网高性能系统课题”的发展。抓住了，我国很可能就会出现世界级的软件公司，错过了，将会后悔莫及。

建议：

1。鼓励与“互联网高性能系统”的有关组织，公司，科研单位的发展；

2。建立国家级学术讨论机构，交流经验；

3。将国内的类似项目交给国内公司去做；

4。鼓励和支持类似企业上市等等。

一个有创造力的p2p社会化网络系统http://blog.csdn.net/netchecking/archive/2007/12/14/1934584.aspx

我的高性能奥运门票销售系统设计方案 http://blog.csdn.net/netchecking/archive/2007/11/06/1868924.aspx

计算机核心技术机密资料《揭开数据库内核的神秘面纱》，免费索取！