如果是你铁道部12306网站架构师，如何设计网站的软件架构和硬件系统架构
如题，就是现在这个网站基本瘫痪了，看看大家如果作为一个系统架构师，如何去设计这么一个大规模，高并发的网站。
[解决办法]
p民提个简单建议，就是取消座位锁定机制，问题能根本解决。不用到架构师的程度：http://blog.csdn.net/dragonimp/article/details/7184319
[解决办法]
减少客户端与Web服务器交互次数,
[解决办法]
减少一次,就是在并发的情况下减少N-1次
[解决办法]
采用高性能的本地缓存和分布式缓存机制是个必要的措施
[解决办法]
每一个省会建一个服务器，这样就有多个不同的IP可以访问，北京、上海、广州这三个地方可以多建几个服务器。
服务器建在骨干网上，服务器之间进行交互数据。
PS:这么大又有这么多资金流动的网站一定会成为黑客攻击的目标，所以，如果坐不好安全措施，后果大家都懂的。
[解决办法]
更正下8楼
首先，我要否认一些看起来合理，但实际上根本就没必要的优化方案：
1. 前台数据优化与压缩
如果处理前台网页数据的服务器数量不够，或者压力太大，导致打开网页慢，加载网页元素的速度慢，那么就需要对前台数据进行优化和压缩。但是，打开首页，从HTML文件，到图片，甚至验证码，差不多都是瞬间打开（电信、教育网、联通和网通已测），因此，前台那点文本数据，有什么好优化的。当然，优化也可以，但问题的关键根本就不在于前台这点文本数据。
2. 对数据库使用缓存。
说这话的人，得去弄懂什么叫电子商务。这种东西又不是微博这种ACID可以忽略不计的东西。电子商务的业务处理，需要高ACID，目前，铁路订票系统也就是因为需要保证高ACID，才导致了今天这些问题。然而，一些人居然希望使用缓存，这种会导致ACID降低的方法，去缓解压力，显然，他们没有意识到，这种设计，连需求都违背了，还谈什么优化。
这几天，我跟几个理论性强的导师以及有多个大型项目经验的朋友，一起讨论了这个问题。我们得出了一个结论：目前购票系统的瓶颈，在于ACID的实现关键：锁。由于锁具有一定程度上的硬件独占性，以及过程串行化等特点，加上目前通用的数据库产品，会有内在的锁的升降级带来的开销。这种开销，再乘上国家级的业务量，就造成了，即使是使用目前性能最强的大型机，可能也扛不住这种对锁的使用需求。
要真正解决这个系统中锁的问题，在数量级上提升锁效率，就目前来说，是不可能的，除非未来的计算机结构或部件发生革命性升级。比如，就查询余票操作来说，客户端的每一个查询操作，服务端都需要一次相应操作。这种模式，反应到现实世界中，那就是，在售票厅里，一个人需要获取票的情况，售票员都得回答一次，因此有多少人，售票员就得回答多少次，显然这是一种低效的方法。然而，现实中的实际情况是，所有人只需要看火车站大公告板，就能了解到票的情况，这种模式，在计算机中就是，服务端一次广播数据，所有客户端都可以获取数据，但是，目前计算机以及网络硬件中，不存在这种设备。在未来，可能会出现一些基于光或声波来进行同时数据广播的设备，但现在讨论这种设备显然没什么意义。
虽然如此，但我们还是讨论出了3个小方案，可以在线性级别上提升锁效率。方案如下：
1. 由于火车票这种数据的结构具有单一性，因此，每次业务处理，锁的使用次数并不多。但是，如果使用通用数据库软件，则会带来内存的额外的锁开销以及别的开销。所以，我们需要把火车票这个数据库“抽出来”，单独做成一个C/C++的专门数据库软件，这样就可以免除使用标准数据库软件所带来的额外的锁开销以及别的开销。
2. 尽量把票的数据，分摊到不同的服务器上。这样做，可以让每台服务器的锁的开销尽量小些，并且保证同时能有尽量多的硬件参与锁的运算。比如，把一列火车的车票，分摊到10台数据库上去。但实际操作中，具体怎么分摊，我们认为，这个要根据压力来计算，平时压力很小的时候，也许1台服务器可以同时处理多辆火车的票的数据，但春运期间，1台服务器也许只能同时处理一辆火车的一小部分车票。计算压力，可以人工统计，然后修改分配方案；也可以基于一些简单的策略，加上机器学习，来实行机器自动化统计并修改分配方案。
3. 由于运力问题，火车站所提供的火车票的数量远远小于前来购买的人的数量，并且，在整个购票过程中，查询的次数占的比率最大，因此，在使用系统的整个过程中，是读次数多（查询次数多），写次数少（购买到火车票次数少）。所以，数据库可以做成对读操作进行负载均衡的集群模式。这样做的话，就可以加快查询速度，然而，写速度会稍稍降低，但这个降低显然值得。
[解决办法]
9楼是8楼的原创~
[解决办法]
8楼是9楼的作者~
[解决办法]
嗯，谢谢管理员帮我更新。
[解决办法]
如果把火车票系统比作win7, 那么现在的火车票系统就是Vista...慢的要命...
看看高操作系统是怎么干的...
http://www.osnews.com/story/22501/Microsoft_Kernel_Engineers_Talk_About_Windows_7_s_Kernel
很多问题总是惊人的相似...
[解决办法]
我建议使用网上排队
把能够容下的数据库连接作为一个售票站进行卖票
每一位用户购票时间受限
把所有的用户登陆之后可自行进行排队
进行排队时用户必需每隔几分钟之内刷新一次页面，否则会自动退出排队
[解决办法]
座位锁定机制,是购票系统的基础，另外整套系统的核心是数据库和锁的应用，如何减少数据库压力是基础，WEB并发数的解决可以提高服务器性能和分发机制解决，另外生成预取静态数据备用，有请求直接转向！减少连接与数据库压力
[解决办法]
对，要进行排队，
[解决办法]
菜鸟路过。。。膜拜各位大牛。。与LZ一样。。想知道答案。
------解决方案--------------------
菜鸟路过。。膜拜各位大牛。。
[解决办法]
8楼9楼是典型的学校派的方案,实际操作中一般并不可行,虽然理由好像很扎实.
比如如何保证自行设计的专门数据库软件可以达到现有DBMS的性能级数(即使解决锁这个问题,这也几乎是在此项目工期内不可能完成的任务)
尽量把票的数据，分摊到不同的服务器上,我相信人家铁道部早就已经这么做了.
在整个购票过程中，查询的次数占的比率最大. 这只是你的想像.
虽然都在骂铁道部那些弄技术的, 然试易地以处之,吾果无一失乎? 其实人家设计时在并发和吞吐上早已经有很多考虑(否则结果会比现在严重得多), 导致网站瘫痪的核心问题并不主要是购票的人给网站带来的Web压力. 春运大约有多少人要购票是可以大致根据往年数据估算出来的,所以吞吐量设计就算偷工减料(谁在这里偷真是傻了)也不会差太多,真正引起问题的不是在网站上买票的压力,而是成百上千种不同的购票外挂,低估了外挂带来的问题,更可能是引起问题的关键. 因为外挂有着跟网站设计者完全不同的操作方式和请求的次数,可能几乎没有查询而瞬间爆发成百上千的并行请求. 现在我所知道的周围买到票的大部分是通过各种外挂买到的, 保守估计外挂种类应该在百种以上,按平均每种有1000人用,每个外挂产生相当于1000人同时在线的请求压力是没什么难度的,这个额外的压力不是你去设计一个 "好一点 "的结构可以消化的. 对外挂的一些防范手段比增加压力容量可能带来更好的效果.
这两年云计算一直在喊一直在喊, 全中国最应该最合适占云计算这个便宜的恰恰就是这么一个购票的网站,为什么?这是个日峰值和日平均值相差很大的网站,比任何其他网站都大.全世界上云计算第一个大型应用是亚马逊网站,因为圣诞节的峰值购物比平时大很多,为了保证圣诞节正常运营需要更多的服务器,而这些服务器在平时又没压力,硬件闲置. 这个铁道部的购票网站其实是个比亚马逊更能在云计算中占便宜的系统, 根本不该自己建设硬件系统而应该使用通用的云服务器. (国内价格比美国要高一些,但是对这么一个典型应用,要节约很多钱而且负载能力更有保障,完全可以在过年时请求平时1000倍甚至10000倍的资源,因为时间很短)
其实做二十几年程序学到一点,就是看见数据之前,千万不要谈优化, 而我和上面所有人相信都没看见性能数据,所以所有优化都是纸上谈兵,拿来说着玩,实际情况可能差十万八千里.
[解决办法]
