搶不到回家的票，還真不是12306技術不行

　　爲什麼會搶不到票？
　　在解釋這次 12306 爲什麼會崩潰前，我們有必要先了解一些它的基本規則。
　　<strong>一直以來，中國鐵路都存在一種被叫做“區間限售”的售票模式</strong>。它某種程度是對硬紙板票售票模式的延續，在硬紙板票時代，每輛車在每個車站、每個區間發售的車票都需要提前印刷好，因此售票部門會事先給每趟車不同區間的車票數量制定指標。
　　在互聯網時代，這種指標分配仍然存在，於是漸漸有了區間限售的說法。<strong>這種售票模式遵循的原則，12306 官方的</strong><strong>對外解釋</strong><strong>是“棄短護長”</strong>。
　　舉個簡單的例子（僅作舉例不代表真實情況），針對從北京始發經由濟南、南京，最終到達上海的 G1 次高速列車，在一開始售票的時侯，大概率不會發售從濟南到南京段的車票，或者會在開始時限制這一區間銷售的車票數量（不放出全部車票），爲的是保證北京到南京、上海的長途旅客的出行需求。
　　因爲一旦你先買了濟南到南京的車票，意味着你不僅佔用了從北京到南京的一個席位，還佔用了一個從北京到上海的。不論是就方便長途旅客（沒人願意從北京到上海三段區間換三次座位），還是減輕鐵路系統的工作負擔，區間限售都是目前最合適的解決方案。
　　這也在一定程度上解釋了火車票爲什麼難搶，一邊是巨大的人口基數，一邊是區間限售的措施，都讓車票在剛一放票就被秒光。雖然在臨近開車的一段時間內，爲了調控需求、提高列車利用率，會解除限售放出一些沒有賣出的餘票，但在春運這樣交通資源極其緊張的時候，人們一天買不着票就要多操心一天，傷時傷財傷感情。
　　<strong>越是需要拼手速，第三方搶票軟件就越有利可圖</strong>。越來越多人選擇放棄使用 12306 官網及 App 手動訂票，轉而把搶票任務託付給攜程、智行等等的第三方軟件和機器。
　　人工刷新永遠快不過機器，第三方搶票軟件給 12306 帶來的是巨大且更頻繁的數據量。一名曾在第三方軟件的火車票部門工作過的知乎匿名用戶如此回憶，“就我們每天往她（12306）塞的流量，基本上小電商網站都要崩潰，而且我們更早地提出過站補票，買短程票延長，提供機票加火車加汽車一系列的解決方案，查詢量非常大。”
　　<strong><strong>12306 爲什麼會崩潰？</strong></strong>
　　第三方搶票軟件給 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 的動態庫存比我們平時買東西的任何網站的庫存機制要複雜太多太多，<strong>等於旅客每買一張車票，12306 就需要更新相應線路的所有車票數據</strong>。
　　有業內人士稱，餘票查詢系統訪問量巨大，佔 12306 整個網站流量的 90% 以上，業務高峯期併發請求密集，性能要求是整個業務系統中最爲重要的一環。
　　當第三方搶票軟件加上人工查詢涌入的數據量超出 12306 的計算能力時，崩潰就發生了。
　　<strong><strong>不是 12306 不努力</strong></strong>
<strong>　　對於 12306 來說，應對的方法無非兩種，一種是打擊第三方搶票軟件，一種是升級服務器</strong>。實際上，這些 12306 也早就想到了。爲了打擊搶票軟件，12306 嘗試過的辦法就包括了最早的字母數字組合驗證碼，後來槽點頗多的圖形驗證碼，規定半年內不得刪除常用聯繫人，每個註冊的賬戶必須經過實名驗證，以及推出“官方的搶票功能”候補購票等。
　　經過如何、道理怎樣不再贅述，但結果是，種種複雜的限制最後總能被第三方軟件想方設法破解，這不現在一些搶票軟件已經能幫你實現“官方候補”（別問我怎麼知道的），而 12306 的候補功能今年 5 月纔剛正式上線。
　　服務器方面，12306 針對餘票查詢系統有過的兩次較大升級。
　　一次是在上線後的一年內選擇與美國科技公司 Pivotal（中譯“畢威拓”）合作，引入後者的 GemFire 分佈式內存計算平臺技術率先對 12306 的餘票查詢系統進行改造。“分佈式數據處理”和“集中式數據處理”概念相對，在解決 12306 的票務問題上分佈式計算更有優勢（不懂兩者區別的朋友請自行搜索）。這次技術改造效果明顯，讓 12306 暫時舒了一口氣。
　　另一次則是和阿里雲的合作。據一名自稱是阿里雲程序員、參與了 2015 年 12306 春運項目工作的知乎匿名用戶稱，在 2014 年初雙方團隊就已開始討論如何將餘票查詢系統放到雲上，並在 2015 年春運期間將 12306 75% 的餘票查詢業務放到雲上。
　　雲計算相較於 GemFire 這樣基於內存的分佈式集羣系統功能更進一步，在提升餘票查詢能力方面，雲計算可以快速部署應用提供服務，通過分鐘級的擴容操作，實現十倍、百倍的服務能力擴展。
　　<strong>瞭解了這些，我們恐怕真的不能指責 12306 不努力</strong>。尤其是考慮到每年只增不減、屢創新高的春運鐵路出行人次，12306 幾乎年年都要面臨大考。
　　把近五年的鐵路春運數據放在一起比就很明顯了，2015-2019 年春運鐵路總計發送旅客人次分別是：2.95 億、3.26 億、3.57 億、3.8 億和 4.1 億。據 12 月 25 日國家發展改革委、交通運輸部、公安部、國鐵集團等八部門聯合召開的電視電話會議預測，2020 年全國春運鐵路發送旅客將高達 4.4 億人次。
　　你可能會問，既然如此，12306 爲什麼不多買一點服務器呢？有人舉了這樣一個例子:
　　“十一黃金週的時候，北京主城區到八達嶺長城的路堵得嚴嚴實實，但不能因爲黃金週出行高峯，就把這段路修成長安街那樣 10 車道的公路。花大價錢修了一段路，黃金週是可以飆到 80 公里/小時了，可平時呢，拿來給兩邊的居民曬穀子？逼着 12306 買一大堆服務器對付春運，和逼北京修一條 10 車道的高速公路去八達嶺長城一個道理。”
　　再者，即便是買了更多服務器，當前中國的鐵路運力擺在那，依然會有人搶不到票。
　　所以別總抱着“12306 技術不行”的怨念不放了，那樣沒有意義。就像一位 12306 工程師回顧系統剛上線時說的，“其實我們知道，他們罵的不是 12306，他們罵的是這個時代。”