技术网友踊跃给出自己的设计建议

    “先到先得”是需求方提出的需求，而技术人员就应该想到这个需求背后所有的可能性，说这个销售策略有问题，实际上是说用户提出的需求不合理。

    为什么会出现“每秒钟网上提交门票申请超过20万”这种情况？这可以用“销售的系统压力估计不足”来敷衍，但是压力测试的极限是多少？超过这个极限是怎么处理的？没有处理的预案，怎么就敢使用程序？社区当中，质疑开发商技术能力的声音越来越多。

    在社区的讨论中，大部分技术网友认为还是应该提前找到解决方案的。比如可以出一个折中方案：支持到一定程度即可，同时在软件上进行限制。比如连接数到一定程度就进行一定的处理，例如可以提示网站访问人数太多。但是绝对不能压垮，因为网站崩溃这就是事故了。

   “比如你用LoadRunner压一下百度，压一会就不能访问了——不是把网站压得怎么样了，而是百度不让你访问了。”只要做好相关预案，是绝对不会出现崩溃事故的。

    比如，可以限定表单的提交量，即使是“先到先得”也应 该有个准备，提交前做个排队系统、发送验证系统等等，都提前控制提交表单量，虽然压力可能会集中在这部分排队验证上，但是一旦通过，表单提交系统的压力会大大减轻，成功率会大大提高，也不会造成票务系统数据库瘫痪，整个网站的压力分布也能分散。没有任何的限制，所有用户开始就可以选票，马上提交，数据库如何能够处理这么集中的压力。

    此外，网友从需求分析的设计实现方面，也发现了网站的很多缺点：需要用户访问的不紧急不必要页过多。
    例如，取票网点选择竟然在订单的流程中，明年6月才取票，为什么要早早的就要设置，定上票以后再设不行么？定不上票这些选择这些操作不全是无效操作么！这步操作，这几个页面，20万订单中要浪费多少服务器资源，浪费多少数据库资源，都这么设计网站，访问量这么大，什么服务器什么数据库能承受呀！

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

    目前，高并发的大规模网站架构技术，一直是技术开发领域的热门话题，然而国内能够真正处理好这些技术问题的公司又寥寥无几。随着中国互联网技术的发展，越来越多的网站正面临这些问题，因此，分析奥运订票网站的崩溃，从技术角度而言，有特别重要的意义。

    11月5日，北京奥组委票务中心公布新的北京奥运会门票第二阶段销售政策。即采用给定一段时间提交订单，然后采用一次性抽签的方式决定购票人资格的政策。这实际上是改变需求来化解了这一技术问题。然而，“先来先得，在线抢定”这一需求的技术实现，还会在各大技术社区深入持久地讨论。尽管这是一个失败的技术项目，但希望其他奥运信息化项目能引以为戒。