12306訂票的核心業務，也是最多查詢的數據，其實是一個很簡單的東西_風聞

【本文來自《在外行看來，鐵路自主選座非常容易實現，但懂行的程序員才知道這根本做不到》評論區，標題為小編添加】

• 打醬油的星際菜鳥
• 你沒有畏難情緒，你相信“辦法總比困難多”，那你能明天搞出輸出能量為正且能穩定運行超過一小時的可控核聚變嗎？

講點唯物主義好不好……

你這就犯了最近10多年程序員的通病，習慣使用大量的開源組件來快速解決問題，但是缺乏對底層實現的思考。

如果鐵路訂票系統使用你這種想法，本質上還是基於關係型數據庫的處理。無論怎麼優化，這個數據庫都是巨大的，或者強關聯的，無法應對數量巨大的併發操作。

但是鐵路訂票的實現，無論是從公開文章中的猜測，還是基於底層邏輯的推測，都不是這麼做的。

訂票的核心業務，也是最多查詢的數據，其實是一個很簡單的東西，就是從XX站到XX站的某種類型的車票，還有多少剩票。這通過一個二級查詢就可以高效實現。第一級，就是查出XX站到XX站的直達列車的班次。這個既可以用傳統的關係型數據庫實現，查找包含XX站和XX站的所有車次，也可以更高效的使用預生成的表格，以全國的各個站作為表格（二維數組）的橫縱座標，把相應的車次（每班列車賦一個ID）填入這個數組。本質上就是一個單元是鏈表的疏鬆數組，各種高效實現的算法就不用細説了。

第二步，是每個班次每種坐席建立一個二維數組，橫縱座標是該班次停靠的各個站，一般來説，這個數組就是40*40以內。數組的內容是從橫座標站到縱座標站的可售票數。查詢就是一個直接查表的過程，直接一個返回數組[X,Y]的值的操作就好了。訂票則至多寫數組橫座標上限次數。而具體座位的預定，則和這個系統無關，是一個獨立的系統。它的工作量要遠遠小於之前這個工作（因為只有成功訂票/退票才會調用這個系統），可以用一般的數據庫實現。而人工選座也是這個系統的工作，你的數量眾多的SKU突然就沒有了吧？順便説一下，就算不能客户選票，每個座位從XX站到XX站的狀態也是需要記錄的，系統畢竟不能出重複票吧？