作為世界上公認規模最大、特定時段最繁忙的實時交易系統之一，能在絕大部分時間保證平穩運行，12306 已經相當不容易了。

　　臨近春節，12306 崩潰一次，就有人心碎一次。

　　12 月 23 日上午，有不少網友爆料稱 12306 出現了車次加載失敗、購買不了票或卡在候補訂單支付界面的情況，疑似因搶票人數過多，導致服務器崩潰。12306 客服后來回應，原因可能是操作旅客過多，系統繁忙造成的，可嘗試重新卸載安裝客戶端或切換網絡。至于春運期間是否將加強技術保障，客服稱需要反饋給相關技術部門才能得知。

　　似乎每年在春運的節骨眼上，12306 總要掉幾回鏈子。已經有人學會了苦中作樂，有網友想到興許能報個旅行社回家：

??

　　有人出主意不然就直接買輛車吧，路上還能拉個順風車賺錢：

??

　　很多人雖然總喊著過年太煩太累，但家畢竟還是要回。按照 2020 年春運火車票網絡訂票提前 30 天發售的規定，12 月 23 日已經可以購買 2020 年 1 月 21 日的車票，正是搶票高峰期。在離春節假期只剩整一個月的當口，絕大多數歸心似箭的人還是被這波宕機搞得非常著急。

　　12306 每次宕機都伴隨著一片罵聲，這次也不例外。大家不明白為什么這么久過去了，12306 還是如此讓人糟心。這個問題并不簡單，它涉及到我國復雜的國情和背后的種種技術，不是一句話就能說清，我們亦無法輕易給 12306 定性。

　　但有一點可以肯定，作為世界上公認規模最大、特定時段最繁忙的實時交易系統之一，能在絕大部分時間保證平穩運行，12306 已經相當不容易了。

　　為什么會搶不到票？

　　在解釋這次 12306 為什么會崩潰前，我們有必要先了解一些它的基本規則。

　　一直以來，中國鐵路都存在一種被叫做“區間限售”的售票模式。它某種程度是對硬紙板票售票模式的延續，在硬紙板票時代，每輛車在每個車站、每個區間發售的車票都需要提前印刷好，因此售票部門會事先給每趟車不同區間的車票數量制定指標。

　　在互聯網時代，這種指標分配仍然存在，于是漸漸有了區間限售的說法。這種售票模式遵循的原則，12306 官方的對外解釋是“棄短護長”。

　　舉個簡單的例子（僅作舉例不代表真實情況），針對從北京始發經由濟南、南京，最終到達上海的 G1 次高速列車，在一開始售票的時侯，大概率不會發售從濟南到南京段的車票，或者會在開始時限制這一區間銷售的車票數量（不放出全部車票），為的是保證北京到南京、上海的長途旅客的出行需求。

　　因為一旦你先買了濟南到南京的車票，意味著你不僅占用了從北京到南京的一個席位，還占用了一個從北京到上海的。不論是就方便長途旅客（沒人愿意從北京到上海三段區間換三次座位），還是減輕鐵路系統的工作負擔，區間限售都是目前最合適的解決方案。

　　這也在一定程度上解釋了火車票為什么難搶，一邊是巨大的人口基數，一邊是區間限售的措施，都讓車票在剛一放票就被秒光。雖然在臨近開車的一段時間內，為了調控需求、提高列車利用率，會解除限售放出一些沒有賣出的余票，但在春運這樣交通資源極其緊張的時候，人們一天買不著票就要多操心一天，傷時傷財傷感情。

　　越是需要拼手速，第三方搶票軟件就越有利可圖。越來越多人選擇放棄使用 12306 官網及 App 手動訂票，轉而把搶票任務托付給攜程、智行等等的第三方軟件和機器。

　　人工刷新永遠快不過機器，第三方搶票軟件給 12306 帶來的是巨大且更頻繁的數據量。一名曾在第三方軟件的火車票部門工作過的知乎匿名用戶如此回憶，“就我們每天往她（12306）塞的流量，基本上小電商網站都要崩潰，而且我們更早地提出過站補票，買短程票延長，提供機票加火車加汽車一系列的解決方案，查詢量非常大。”

　　12306 為什么會崩潰？

　　第三方搶票軟件給 12306 帶來的壓力，基本都在余票查詢環節，這也是 12306 的崩潰之處。

　　查詢環節就涉及到 12306 庫存機制的復雜性。事實上早在 2014 年，一位 ID 名為“代碼狗”的前淘寶工程師就在著名論壇“西西河”上發文表達過他對 12306 的看法。他曾認為 12306 的系統很容易搭建，于是發起了一個名為“替 12306 設計系統”的開源項目，然而工作中的實踐徹底改變了他對 12306 的認識。

　　12306 系統的復雜之處就在于，它的 SKU（即 Stock keeping Unit，庫存保有單位）并不像一般電商那樣，可以通過區別貨品有和沒有來簡單計算，而是需要結合每條線路的不同區間來做復雜運算，并且，12306 的 SKU 還是時刻動態變化著的。

　　這里引用“代碼狗”舉的一個從北京西到深圳北的 G71 次高速列車的例子（僅討論理論世界的模型）。這趟列車共有 17 個站，3 種座位，表面上看這是 3 種商品（商務座、一等座和二等座），但實際上，G71 的商品種類多達 408 種（注意：這里指的是商品種類，而非具體的商品數量）。

　　計算方法是，如果賣北京西始發的車票，共有 16 種賣法，因為后面有 16 個站，分別是北京西到保定、石家莊、鄭州、武漢、長沙、廣州、虎門……每個區間都可以看作是一種獨立的商品。同理，如果是從石家莊站始發，共有 15 種賣法，以此類推。所以單按車站區間來計算，G71 的商品種類為：16+15+14+…+2+1=136 種。再考慮進 3 種座位類型，商品種類就成了：136*3=408 種。

　　我們再來看 G71 是怎么減庫存的。假如旅客A買了一張區間為北京西到保定東（即順序數北京西的下一站）的車票，那么 G71 的 SKU 就要減去 16 個，包括北京西到余下 16 個車站每個區間都要減1（注意：這里指的就是商品數量了，可以暫時不需考慮座位類型）。

　　同樣，假如旅客B買了一張區間為北京西到深圳北（即終點站）的車票，G71 的 SKU 就要減去 136 個，包括北京西到余下 16 個車站每個區間減1，保定東到余下 15 個車站每個區間減1，石家莊到余下 14 個車站每個區間減1……所以減去的庫存為：16+15+14+…+2+1=136 個。

　　G71 的商品種類本來已經夠多了，庫存減起來更是繁瑣。可見，12306 的動態庫存比我們平時買東西的任何網站的庫存機制要復雜太多太多，等于旅客每買一張車票，12306 就需要更新相應線路的所有車票數據。

　　有業內人士稱，余票查詢系統訪問量巨大，占 12306 整個網站流量的 90% 以上，業務高峰期并發請求密集，性能要求是整個業務系統中最為重要的一環。

　　當第三方搶票軟件加上人工查詢涌入的數據量超出 12306 的計算能力時，崩潰就發生了。

　　不是 12306 不努力

　　對于 12306 來說，應對的方法無非兩種，一種是打擊第三方搶票軟件，一種是升級服務器。實際上，這些 12306 也早就想到了。為了打擊搶票軟件，12306 嘗試過的辦法就包括了最早的字母數字組合驗證碼，后來槽點頗多的圖形驗證碼，規定半年內不得刪除常用聯系人，每個注冊的賬戶必須經過實名驗證，以及推出“官方的搶票功能”候補購票等。

??

當年 12306 的圖形驗證碼被玩壞了

　　經過如何、道理怎樣不再贅述，但結果是，種種復雜的限制最后總能被第三方軟件想方設法破解，這不現在一些搶票軟件已經能幫你實現“官方候補”（別問我怎么知道的），而 12306 的候補功能今年 5 月才剛正式上線。

　　服務器方面，12306 針對余票查詢系統有過的兩次較大升級。

　　一次是在上線后的一年內選擇與美國科技公司 Pivotal（中譯“畢威拓”）合作，引入后者的 GemFire 分布式內存計算平臺技術率先對 12306 的余票查詢系統進行改造。“分布式數據處理”和“集中式數據處理”概念相對，在解決 12306 的票務問題上分布式計算更有優勢（不懂兩者區別的朋友請自行搜索）。這次技術改造效果明顯，讓 12306 暫時舒了一口氣。

??

12306 引入 Pivotal GemFire 改造后的成效

　　另一次則是和阿里云的合作。據一名自稱是阿里云程序員、參與了 2015 年 12306 春運項目工作的知乎匿名用戶稱，在 2014 年初雙方團隊就已開始討論如何將余票查詢系統放到云上，并在 2015 年春運期間將 12306 75% 的余票查詢業務放到云上。

　　云計算相較于 GemFire 這樣基于內存的分布式集群系統功能更進一步，在提升余票查詢能力方面，云計算可以快速部署應用提供服務，通過分鐘級的擴容操作，實現十倍、百倍的服務能力擴展。

　　了解了這些，我們恐怕真的不能指責 12306 不努力。尤其是考慮到每年只增不減、屢創新高的春運鐵路出行人次，12306 幾乎年年都要面臨大考。

　　把近五年的鐵路春運數據放在一起比就很明顯了，2015-2019 年春運鐵路總計發送旅客人次分別是：2.95 億、3.26 億、3.57 億、3.8 億和 4.1 億。據 12 月 25 日國家發展改革委、交通運輸部、公安部、國鐵集團等八部門聯合召開的電視電話會議預測，2020 年全國春運鐵路發送旅客將高達 4.4 億人次。

　　你可能會問，既然如此，12306 為什么不多買一點服務器呢？有人舉了這樣一個例子:

　　“十一黃金周的時候，北京主城區到八達嶺長城的路堵得嚴嚴實實，但不能因為黃金周出行高峰，就把這段路修成長安街那樣 10 車道的公路。花大價錢修了一段路，黃金周是可以飆到 80 公里/小時了，可平時呢，拿來給兩邊的居民曬谷子？逼著 12306 買一大堆服務器對付春運，和逼北京修一條 10 車道的高速公路去八達嶺長城一個道理。”

　　再者，即便是買了更多服務器，當前中國的鐵路運力擺在那，依然會有人搶不到票。