奥运门票官网的崩溃

虽说近年感受到越来越多的骄傲，中国还是有那么多不尽人意的地方。不说亚运村汇园公寓北面的那条路修了两年多都没有修好，埋好了又挖，挖好了再埋，那条路上的饭馆都倒闭了。也不说上个礼拜天，鸟巢施工把供水水管挖爆，造成附近地区停水一天。（当天下电梯时里面有两个人，说：“……挖爆了。要是这件事情在我们台湾，至少得要一个礼拜。不知道这便怎样，就看这边效率了。”结果当天晚上就好了。这个关乎ZJ的东西怎么可能慢呢？）

今天最让人郁闷的就是门票的官网崩溃了，搞得我都没有兴趣去买票了，之前还兴致勃勃的。


很明显，抗不住压力了，全国人民的力量还是很大的。其实，抗不住情有可原，毕竟人多。但是从技术角度，这里面有几样东西是不应该的。
第一个不应该的就是在加密连接的页面里面，有非加密的内容。只要选择了不现实非加密内容，样子就成这样极丑。
第二个，是这样的系统，应该有相应的设计，不应该是出现“对不起，现在无法处理您的请求，请重试。”这样的东西。
理由很简单，如果系统能够承受的处理能力是1000，实际需要处理10000，就会出现无法处理的情形。这个时候如果提供一个很简单的方式让用户刷新，问题就会变得极其糟糕。因为当这个系统刚处理完1000个请求的时候，上一次9000个请求，以及下一次10000个请求就会到达。于是，实际需要处理的请求就会越滚越大，毫无恢复正常的希望。

解决的办法有好几种，一种是不允许刷新，种下一个Cookie，服务端如果发现Cookie中的上次尝试时间距现在不到1分钟，就不允许刷新。这样9000个剩余请求就不会立刻转入下一次请求当中，系统符合的增长速度相对就会放缓，恢复正常的希望也就比较大一点。缺点是，对这剩余的9000个用户有点不公平。但是实际上，如果系统不提供刷新，你必须重新从搜索结果到现实内容页面，到点击订票按钮，到最终系统受理，也差不了多少。反而提供了一些方便。

另一种方案是，给每一个具体操作请求排号，一进来就发一个号码，每过一段时间，页面自动刷新。服务端如果发现现在这个号码进入了系统能处理的范围，就换发一个令牌，允许进入实际操作或者处理。这样的话，处理比较当前排号是否在系统处理范围的页面功能相对简单，服务器吞吐量比较大，可能是实际订单操作（数据库操作）的100倍。于是用户不会觉得有问题，相对第一种方案会更公平一点。
这种东西又不是没有见过，最简单的，大部分提供公开下载功能的网络硬盘的下载页面都有类似的功能。很难吗？应该不难，至少应该比怎么确保网站不被攻破，保障网上付费交易要简单。可惜没有这样的功能。

还有一种方案，就是在之前就开放填写订单的功能，到了9点钟，大家一起刷，谁刷上了算谁厉害。区别就在于，现在的系统，下订单也要在9点之后才允许操作。但是先下订单似乎又不分先后，最后买不买的上要看谁先付钱。而这个系统又非常讨厌的必须前面票款结清了之后，才允许新的购买。这样大家就只能够买上一张就付费一张，无形中增大了处理量。

以现在的系统为例假设：
平均刷30次，有一次能够成功。这类操作包括了下订单，进入订单列表，以及付费三个操作。（我连自己的订单都无法进去，所以也不知道后面还有什么操作，就假设只有一个付费操作好了。）

那么，如果我要购买3个场次，我至少得要做 90次订单+90次进入列表+90次付费操作，一共是270次操作。这里99%都是毫无必要的系统负荷。
如果下订单，就能取得优先权，那么操作就会减少到 90次订单 + 30次进入列表 + 30次付费操作，一共是150次操作。这样系统负荷就减少了一半。
如果订单能够提前下，最后9点以后付费就可以了，那么9点之后的操作就会变成30次进入列表+30次付费操作，一共是60次，只有现有系统设计的负荷的2/9。
如果再上一个设计的基础上，提供一个快速付费按钮，那就只有30次付费操作，几乎是现有系统的10%

这个讨论还没有考虑到，系统负荷降低后，需要重试的次数也会相应降低的实际情况。如果考虑到这个因素，也许最终方案重试次数就会降低到3次。

其实所谓先到先得，不就是看谁手快嘛？为什么非要大家忍受那么多次的失败呢？就让我点一下付费，不行了再试一次就好了。重试次数越少，运气成分就越少。比谁快的时候，需要操作的内容越少，技巧的成分也越少。这样才更公平！

目前这个系统，还有一个很有毛病的地方，是没有验证码。这样的话，系统很可能会遭到攻击，或者至少有人会尝试通过程序来刷票。要知道一个程序对系统造成的负荷，会比人至少高出好几倍。尤其在这样全国范围都会使用的系统，你很难对某个特定IP列入黑名单，因为很容易会把一大群无辜的人伤害到，甚至有可能全国各地都存在这样的刷票程序，最终没有进入黑名单的地区可能就寥寥无几了。在黑名单机制不存在的情况下，刷票程序对系统造成的负荷可能不是几倍的问题，有可能是好几千倍。只要有1000个这样的程序存在，就可能比真实购买人群对系统造成的压力更大。

负荷的问题不说了，还有不是负荷的问题，就是这个网站的逻辑非常奇怪：


告诉我说您当前订票单中对本场次的门票总数将超出本场次的购票数量限制，这句话本身就有点让人费解——
是已经售完呢，还是每次只能买一张？
如果是前者，为什么不直说。如果是后者，我后来又重新打开订票页面：

结果却是可以订2张啊？

到了下午一看，果然重试按钮被取消了。
但这样做还是不行的，因为用户可以很容易的返回，再点击提交就能重试了，并不减轻服务器压力多少。
看吧，看什么时候这个系统才能够正常，比如说告诉你“已经售完”而不是“无法处理您的请求”