对奥运售票系统崩溃的一些想法

    奥运售票系统的崩溃给了我们一个口水的噱头，丰富群众的饭后谈资，也算功德一件。老大就给我们布置了这样一个家庭作业，讨论讨论这个系统。我当时想，既然是崩溃了肯定是系统的处理能力不足吧，那提高它的处理能力不就行了，于是......但是且慢，兵法云：多算胜，少算不胜，而况无算乎？如果不对系统做个估算，可能走得方向就是错的。所以说只顾低头做事是错误的。
     第二阶段的售票策略：先到先得。售票渠道：电话（100多）、银行（1000多）、官网。问题来了，电话和银行都是人工处理的，它们会自然的造成一个排队，而web是并发的，那谁会愿意凌晨就去排队而不是在家喝着coffee等9：00打开电脑订票呢？所以必然会造成的绝大部分人会选择9：00到官网抢票的访问洪峰。如果网站处理不过来这些请求，用户又会不断的涮新，雪崩效应就会发生，不崩溃才怪；如果网站的处理能力超强，全部处理了，那银行和电话渠道就哭去吧，要骂娘了。历史告诉我们分赃不均是很容易内讧的。
    方案一：还是采用第一阶段的预订+抽签的方案（或者干脆就不分阶段，一次售完，多阶段对公平、公正有啥好处？实在没想明白。）这样就不会出现过大的访问洪峰，在若干天内处理完所有的订购请求，相信只要不是太弱的系统都能搞定。既不需要成本高昂的设备，也能保证各个销售渠道的公平性。
    方案二：限制官网的处理能力，让它与另两个渠道的处理能力达到适度的平衡。每个用户登录后给他一个排队号，没轮到的时候拒绝他访问一切订购的页面。这样他每次只能刷一个排队号。

    第三阶段的售票是实时的，似乎挽回了很多面子，看报道说人家很自豪的说他们的系统和模块都是可扩展的，所以在几个月内就扩展了，然后带宽、服务器等都扩展了，所以能应付很大的压力，第三阶段也就很顺利。不评论了，算一下：假设有3000W人想买票，他们基本都在等9：00，大概在10分钟内登录进来，在一次都不刷新的情况下都有5W/s，要处理这个量级，需要怎样的设备支持？报道说崩溃前收到的订单是20W/s，非要说他们的系统处理能力不强也冤枉了他们。OK，假若他们现在的处理能力强了，按2000张/s处理能力算，奥运会的总门票数才700W，一个小时就处理完了，设备就闲置了......n倍于原来成本，这个代价值得吗？
    很多时候可能并不是个技术问题，开始做之前不妨多比较讨论一下几个方案，至少可以少做些吃力不讨好的事情。

    特别鸣谢老大的耐心指导和讨论，给了我一个进一步学习系统架构的机会。