对于12306，我的完整技术方案

建议不要猜想着去设计方案，还是找机会去了解下铁路系统内部的情况吧，估计出票的方式不是12306系统可以解决的，只给12306提供了一个接口而已

根本就不该有查询剩余票数等功能

铁路票务的业务逻辑是不简单的。


1、“车次查询时，把车次信息分库存储，并作冗余存储”，全国的铁路站点是数据结构中的图，如果每两个站点之间都做一个分库存储，那么库本身的数量就相当可观，运营维护的压力很大，并不可行；用内存表不行，因为要考虑集群之间内存同步问题，服务器掉电也会出问题，而且万一内存表服务器挂了，那么会直接击垮后台数据库服务器。

2、“创建新表20120113_G113，然后把2000张票提前插入到表中，每个票都有一个本表内唯一的数字编号”，动态表的设计思路本身就有待讨论，而且铁路系统有全国列车时刻表，每天的车次都是有据可查的，并不是动态随机出现的，即便是加开临客，也只需要临客数据表而且，使用动态表保存票据是费力不讨好的。

3、“把上面提到的预售车票表加载到内存中”，内存中使用数组查询车票剩余数量没有考虑集群问题和掉电问题，同问题1。

4、“中间站买票的，在预定成功后，车票自动分裂”，分裂票有问题，卖出去的全程票如果退票，那么已经分裂票和退回的全程票有重复卖出的可能性。

5、比如我买北京到广西北海的车票，需要换乘不同车次，这种票怎么出，不知楼主考虑过没有，这个算法我记得是铁科院的几个专家做的，水平比较高。

另外这个12306本身只是核心票务系统的一个网上购买渠道，本身不涉及到这些数据库设计问题。目前出问题在于系统架构的规划和设计需要改进，而且这个压力对于一个新网站来讲是大了一些的。

诅咒贴看第一次让人感觉有趣，第二次开始越来越多了后，让人越来越反感，越来越感觉低级。

淘宝牛B，秒杀的时候不也服务器没响应么，铁路的放票方式和秒杀差不多，但是抢得人多多了

楼主的停留在设计细节层面，关键是架构和业务模式要变化

业务模式上，要改变秒杀的抢票方式，另外技术架构上，排队和分流是两个大方向

此贴正解，如果不是总是被和谐。诅咒早已满天飞。