如果是你铁道部12306网站架构师，如何设计网站的软件架构和硬件系统架构

http://www.cnblogs.com/aigongsi/archive/2012/09/17/2683656.html

铁道部新客票系统的设计（一）

铁道部新客票系统的设计（二）

铁道部新客票系统的设计（三）

__________________________________________________________________________________
http://www.oschina.net/question/88671_35944?sort=default&p=1#answers
用实际场景来表达的话：

1、售票厅不允许一直站在队列的前面跟售票员交谈，交谈超过一定时间，你会被强制赶出队列，解决重复刷新的问题（如果重复刷新，系统仅给出等待界面）

2、多开售票窗口（这拼的就是服务器集群的量级了，如果要支持上亿的人同时购票，想想需要多少窗口？，通常一个购票的事务流程需要数秒的话，任何单纯的集群都解决不了实时的问题）

3、按照目的地，进行分区域限时购票，把1天24小时分成48份，每半个小时对应一个省级行政单位，通过行政规定把顾客分组，提高集群效率。第二天重复该流程，限时表提前公布。

另外，计算机系统不能用简单的加法来计算瓶颈，一个省试点能使用，不代表服务器量*40就可以同时支持全国了。

首先，我要否认一些看起来合理，但实际上根本就没必要的优化方案：

1. 前台数据优化与压缩

如果处理前台网页数据的服务器数量不够，或者压力太大，导致打开网页慢，加载网页元素的速度慢，那么就需要对前台数据进行优化和压缩。但是，打开首页，从HTML文件，到图片，甚至验证码，差不多都是瞬间打开（电信、教育网、联通和网通已测），因此，前台那点文本数据，有什么好优化的。当然，优化也可以，但问题的关键根本就不在于前台这点文本数据。

2. 对数据库使用缓存。

说这话的人，得去弄懂什么叫电子商务。这种东西又不是微博这种ACID可以忽略不计的东西。电子商务的业务处理，需要高ACID，目前，铁路订票系统也就是因为需要保证高ACID，才导致了今天这些问题。然而，一些人居然希望使用缓存，这种会导致ACID降低的方法，去缓解压力，显然，他们没有意识到，这种设计，连需求都违背了，还谈什么优化。

这几天，我跟几个理论性强的导师以及有多个大型项目经验的朋友，一起讨论了这个问题。我们得出了一个结论：目前购票系统的瓶颈，在于ACID的实现关键：锁。由于锁具有一定程度上的硬件独占性，以及过程串行化等特点，加上目前通用的数据库产品，会有内在的锁的升降级带来的开销。这种开销，再乘上国家级的业务量，就造成了，即使是使用目前性能最强的大型机，可能也扛不住这种对锁的使用需求。

要真正解决这个系统中锁的问题，在数量级上提升锁效率，就目前来说，是不可能的，除非未来的计算机结构或部件发生革命性升级。比如，就查询余票操作来说，客户端的每一个查询操作，服务端都需要一次相应操作。这种模式，反应到现实世界中，那就是，在售票厅里，一个人需要获取票的情况，售票员都得回答一次，因此有多少人，售票员就得回答多少次，显然这是一种低效的方法。然而，现实中的实际情况是，所有人只需要看火车站大公告板，就能了解到票的情况，这种模式，在计算机中就是，服务端一次广播数据，所有客户端都可以获取数据，但是，目前计算机以及网络硬件中，不存在这种设备。在未来，可能会出现一些基于光或声波来进行同时数据广播的设备，但现在讨论这种设备显然没什么意义。

虽然如此，但我们还是讨论出了3个小方案，可以在线性级别上提升锁效率。方案如下：

1. 由于火车票这种数据的结构具有单一性，因此，每次业务处理，锁的使用次数并不多。但是，如果使用通用数据库软件，则会带来内存的额外的锁开销以及别的开销。所以，我们需要把火车票这个数据库“抽出来”，单独做成一个C/C++的专门数据库软件，这样就可以免除使用标准数据库软件所带来的额外的锁开销以及别的开销。

2. 尽量把票的数据，分摊到不同的服务器上。这样做，可以让每台服务器的锁的开销尽量小些，并且保证同时能有尽量多的硬件参与锁的运算。比如，把一列火车的车票，分摊到10台数据库上去。但实际操作中，具体怎么分摊，我们认为，这个要根据压力来计算，平时压力很小的时候，也许1台服务器可以同时处理多辆火车的票的数据，但春运期间，1台服务器也许只能同时处理一辆火车的一小部分车票。计算压力，可以人工统计，然后修改分配方案；也可以基于一些简单的策略，加上机器学习，来实行机器自动化统计并修改分配方案。

3. 由于运力问题，火车站所提供的火车票的数量远远小于前来购买的人的数量，并且，在整个购票过程中，查询的次数占的比率最大，因此，在使用系统的整个过程中，是读次数多（查询次数多），写次数少（购买到火车票次数少）。所以，数据库可以做成对读操作进行负载均衡的集群模式。这样做的话，就可以加快查询速度，然而，写速度会稍稍降低，但这个降低显然值得。