讨论火车票订购网站架构

昨天用12306网上订票了，可不是用户数过多，就是提示系统忙，可说是这个网基本上是瘫痪了。我想可能是整个系统架构有问题，如果你来设计这么庞大用户数的网站，这个架构该是怎么样的？我是设计不出来，大家来讨论讨论，

我也设计不出来，求答案

最主要的还是负载均衡吧，我觉得可以将数据分布到各个省的数据中心去，然后各做各的负载均衡！当然估计还是承受不了的，所以还需设置一个队列系统，让用户排队。最后限制在线时长！！！而不是一直说用户忙，用户多之类的！！

主要是游击队做的软件，负载均衡估计啥都没做。。。

呵呵，做了队列，还限制了等待时间，如果队列长度超过了票的总数，你除了说用户忙，票不足，你还能怎么样？

唉  不行啊  网上订票系统只是浮云

按10亿人口（当然网络购票绝对不会有10亿人）、售票高峰15天，每天12小时出票来计算，若每次都能购票成功，则每秒的理论并发为1543个（事实上1543的并发完全不需要多余的负载）。但若出现阻塞的情况，就会导致用户不停的刷新，从而导致系统更加繁忙。
要解决这个问题，可以从几个方面下手：
1.使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”，当排队成功后，一天之内付款，购票成功！这样就可以避免购票者不断提交造成的压力。
2.提高系统并发，使用nginx作为HTTP服务器，据说nginx的并发高达3万，这个我没有具体测试，当然这个也取决于业务逻辑的复杂度。
3.缓存所有车票信息，提高查询的响应时间

那得多少台服务器？

全国这么多人网络买票，每人扣1块钱出来也够他买服务器了。

这套系统别的没什么，就是缺排队系统。

PS：很明显，电话订票更靠谱。

实际高峰期是刚出票的那个时间点，那几分钟内每秒有几十万点击不奇怪，类似于秒杀。
排队系统也不完善，排入队内的那次点击应该是选好了票和填完了身份信息，然后点下单的那次请求，这次请求将被排入队内，但由于下单成功后现在有45分钟的时间支付，这段时间内这张票状态是锁定的，所以，实际上队伍前进一批人基本要等上45分钟，所以他拿到排队名次并无多大实际意义，因为45分钟后队里有些人已经不在线了，不可能排上队的都分一张剩余的票。
当然如果不能连续承受几十万每秒的登陆和查询请求，那根本就到不了下单的页面。

电话订票也丝毫没有好处，接电话那头的人也一样在使用一个类似的订票系统，那系统没崩掉的原因只不过是接电话的人有限，那些人又不会连续点击。实际状况和现在的用户忙差不多，变成了你电话打不进去。
如果你幸运的成为了网站上没出现用户忙，而挤进去的那个人，那你也在线订上了