查看完整版本: 奥运门票系统瘫痪，再显数据库软肋

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

引自某网站报道：北京奥运会门票面向境内公众第二阶段预售正式启动。上午一开始，公众提交申请空前踊跃。上午9时至10时，官方票务网站的浏览量达到了800万次，票务呼叫中心热线从9时至10时的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请，为此北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意。
对该报道，我的个人理解是，可能是数据库出了问题。数据库服务器处理不了发过来的数据包，就会造成这种局面，尤其是数据库的事务，锁操作，会造成负担加大。如果数据库的表设计不合理，优化参数没有及时调整，出现这样的问题很正常，不但没有完全发挥数据库的优势，反而展现了数据库的软肋。
俗话说，坏事变好事，通过这样的事件，大家也有了真实实例参考，得到了经验。毕竟压力测试做的很大是很难的，这么大的瞬间访问也是很少出现的。希望该系统的设计者们再接再厉，早日重新上线。
通过这次事件，我有些个人感想。除了增加硬件投入，参数调整，表结构优化以外，能不能彻底分析业务需求，找出关系数据不强的地方，对其专建系统。该发挥数据库的优势时发挥，对于数据库的劣势，对其根据需求专门开发。扬长避短，和谐统一。
小论：
本文自10月31日发表以来，受到广大网友的关注，承蒙大家厚爱，在这里表示感谢。
以上文章写的比较匆忙，本是给朋友看的，没料到会被置到csdn首页，怕给大家造成误解，以前的文字措辞感觉有些草率，也没有真实的表达出我的理解和看法，更改了部分文字，请大家原谅。
本文是以“奥运门票系统”为引，说明了不一定用数据库来存储数据的新的思维，希望能在高性能分布式数据存储，管理等方面集思广益。数据库通过硬件设备投入，参数优化，表的设计优化，是可以支持当前的系统的，我的文章仅仅提出了对该问题的另外的解法，因为在实际的应用中，数据库和其他文件系统或服务器系统混合使用，实践表明确实能达到好的效果。无论搜索引擎，数据库还是其它，只要有能在高性能系统上达到好的效果办法，都要“海纳百川”。
计算机的技术不可能停步不前，不去创新发展，包括数据库本身。这些年来互联网时代的到来，很多以前想象不到的高压力需求都出现了，我也从开始的分布式数据库，各种商业的，开源的，国外实验室专用的，到后来看着cpu和磁盘的受到的折磨，而且我发现有些的需求中，数据的关系性不强，没有统计需求时，自己设计开发专用文件系统，协议等通过压力测试的效果更好。深深感受到一个良好的系统不能只依靠数据库，这是我个人的粗浅的理解。希望能得到广大技术高手，专家，学者的指点。
但可以肯定的是数据库是不可能被替代的，尤其是在对严格的关系数据处理，事务处理，银行应用等方面，国外的数据库算法研究已经非常成熟了。朋友圈中有很多DBA，我们经常讨论技术，他们设计的数据库也都能适应高压力访问，几十年的经验，商业数据库有它的绝对优势，历届奥运会，数据库通过优化也都能支持的住的。当前，商业数据库一般都有方便的调优接口，完善的文档，高素质的技术支持人员。压力太大可以调整数据库参数，适当加大硬件投入，分布式架构，优化表，字段的设计等等，是可以解决的了的。相信我们的“奥运门票销售系统”能顺利实现高压力访问要求。真的希望越快越好，因为我本人还等着买奥运门票呢，呵呵。
最后，衷心祝愿奥运门票销售系统运行成功！