大鹏(ＤàＰéng)的空间___phpchan.bokee.com    复制

2006年10月27日，北京奥组委与北京歌华特玛捷票务有限公司在北京奥运新闻中心举行新闻发布会，宣布北京歌华特玛捷票务有限公司成为北京2008年奥运会票务服务独家供应商。
作为票务服务独家供应商，北京歌华特玛捷票务有限公司将为北京奥组委提供奥运会和残奥会门票销售技术系统平台、北京奥组委票务网站、票务呼叫中心和场馆现场售票运营、
客户服务等在内的票务服务。
——引自奥组委官方票务网站

其他的不多说了，大家都看到30号订票情况了，讨论一下歌华设计缺陷的地方。
访问量大是肯定的，虽然可能考虑不到800万次/小时的访问量，但是至少要考虑到cc攻击的标准。
网站的带宽和服务器的情况可以肯定，就是访问量最大的时候也可以打开页面，但是带宽够用并不等于页面能够正常执行。
每秒钟网上提交门票申请超过20万，任何数据库都不可能实现这种处理，这还仅仅只是提交表单带来数据库的压力，同时页面浏览过程产生的数据库请求更是巨大。
从数据库层面上看，歌华的设计存在很大问题，不论是程序流程上，还是用户访问友好性上。
10月30日，我在奥运订票网上刷了一天，直到晚上网站关闭售票，侥幸买到了两张排球票，整个流程下来，对于歌华的一些设计感到很不理解。

一、为什么会出现“每秒钟网上提交门票申请超过20万”这种情况？这可以用“销售的系统压力估计不足”来敷衍，但是压力测试的极限是多少？超过这个极限是怎么处理的？没有处理的预案，怎么就敢使用程序。限定表单的提交量，即使是“先到先得”也应 该有个准备，提交前做个排队系统、发送验证系统等等，都提前控制提交表单量，虽然压力可能会集中在这部分排队验证上，但是一旦通过，表单提交系统的压力会大大减轻，成功率会大大提高，也不会造成票务系统数据库瘫痪，整个网站的压力分布也能分散。没有任何的限制，所有用户开始就可以选票，马上提交，数据库如何能够处理这么集中的压力。

二、为什么用户访问的不紧急不必要页这么多？例如，取票网点选择竟然在订单的流程中，明年6月才取票，为什么要早早的就要设置，顶上票以后再设不行么？顶不上票这些选择这些操作不全是无效操作么！这步操作，这几个页面，20万订单中要浪费多少服务器资源，浪费多少数据库资源，都这么设计网站，访问量这么大，什么服务器什么数据库能承受呀！

三、为什么不在订票前显示票的剩余量，或者直接关闭无票项目申请接口？虽然即时显示票的剩余量不太现实，但是设定个界限告知用户票的存量是可以实现的，这样很多用户预先知道了订票的可能性，就会放弃选择存量小，不太可能成功的项目。象现在这样最后才去查询票的存量，既浪费数据库资源，又给用户带来很大的不便。以我为例，我数次选择不同篮球场次不同价位的票，每次在提交表单最后才能得到无票的结果，每次都要重新选择，反反复复，一个用户如此，20万提交表单的用户呢？这不仅加大了网站负担，用户友好性上做的更是失败。