12306火车票订票系统的设计思路

众所周知，火车票订票系统的问题是一个政治问题，而不是技术问题，所以本文并不是用来解决此问题的，只是一篇随笔。

在11/11这个4A节日里，淘宝成交了超过1亿的订单，因此12306躺着也中了很多枪，当然，也有不少人提出了订票系统和淘宝的商品交易有很多不同的地方，不能一概而论。

我考虑的问题是，订票业务能不能拆分成多个独立的事务，如果可以拆分，那就意味我们可以通过增加相对独立的设备/数据库来提高吞吐量，而不会遇到明显的瓶颈。

火车票本身是分段的，比如T15次从北京西->石家庄->武汉->长沙->广州。如果有一个人订了武汉->长沙段的票，那么其他人也会受到影响，这点和飞机票或单一商品有所不同。另外，能够提供武汉->长沙段的票不止T15，T97也可以，G1179也行。

我们可以考虑把站站之间的票作为可出售的元商品，这样带来的麻烦是，订一张票在后台，往往是多个商品，比如订北京西->广州的票，后台会记为4个商品。

从数据组织上来看，将同一车次的票放在一个独立的数据库操作起来比较方便（事务处理比较方便可靠）。但是我们是否要把同段而不同车次的元商品放到同一数据库？如果放在同一数据库显然不合适，因为很多车次的经过站之间会略有重叠，这样会是的很多车次都必须捆在一起，不利于分布。如果不在同一数据库，则对搜索需要作出一定的调整。好在这点不难，一个元商品站会在哪几个数据库属于比较静态的信息。

OK，这不是一个技术文章，所以只是简单设想一下。看上去，将事务分开并不是太难的事情，而事务可以分步处理的话，后台的性能就不是问题。而前台从来不是问题，它的解决方案是成熟而现成的。

不过，即使不考虑政治问题。和已有系统兼容就是一个大麻烦，考虑兼容已有系统，很多简单有效的方案是无法采用的。事实上，绝大部分设计方案的时间都浪费在兼容旧系统上了。而火车票订票系统发展到了今天，历史包袱很多，不可能将它们抛弃而不考虑。所以，上面这个想法基于全新搭建系统，对解决实际问题没有啥帮助。

如果考虑到政治问题，12306这个网站能摆出来，已经是人类的一大进步了 :)