12306订票的核心业务，也是最多查询的数据，其实是一个很简单的东西

【本文来自《在外行看来，铁路自主选座非常容易实现，但懂行的程序员才知道这根本做不到》评论区，标题为小编添加】

• 打酱油的星际菜鸟

• 你没有畏难情绪，你相信“办法总比困难多”，那你能明天搞出输出能量为正且能稳定运行超过一小时的可控核聚变吗？

  讲点唯物主义好不好……

你这就犯了最近10多年程序员的通病，习惯使用大量的开源组件来快速解决问题，但是缺乏对底层实现的思考。

如果铁路订票系统使用你这种想法，本质上还是基于关系型数据库的处理。无论怎么优化，这个数据库都是巨大的，或者强关联的，无法应对数量巨大的并发操作。

但是铁路订票的实现，无论是从公开文章中的猜测，还是基于底层逻辑的推测，都不是这么做的。

订票的核心业务，也是最多查询的数据，其实是一个很简单的东西，就是从XX站到XX站的某种类型的车票，还有多少剩票。这通过一个二级查询就可以高效实现。第一级，就是查出XX站到XX站的直达列车的班次。这个既可以用传统的关系型数据库实现，查找包含XX站和XX站的所有车次，也可以更高效的使用预生成的表格，以全国的各个站作为表格（二维数组）的横纵坐标，把相应的车次（每班列车赋一个ID）填入这个数组。本质上就是一个单元是链表的疏松数组，各种高效实现的算法就不用细说了。

第二步，是每个班次每种坐席建立一个二维数组，横纵坐标是该班次停靠的各个站，一般来说，这个数组就是40*40以内。数组的内容是从横坐标站到纵坐标站的可售票数。查询就是一个直接查表的过程，直接一个返回数组[X,Y]的值的操作就好了。订票则至多写数组横坐标上限次数。而具体座位的预定，则和这个系统无关，是一个独立的系统。它的工作量要远远小于之前这个工作（因为只有成功订票/退票才会调用这个系统），可以用一般的数据库实现。而人工选座也是这个系统的工作，你的数量众多的SKU突然就没有了吧？顺便说一下，就算不能客户选票，每个座位从XX站到XX站的状态也是需要记录的，系统毕竟不能出重复票吧？