【文/觀察者網專欄作者 符潔文】
國慶假期，你在12306上搶到票了嗎？
雖然每到節假日「高鐵票好難買啊」「為什麽開票就搶了還是候補呀」等吐槽不絕於耳，但從2011年6月12日上線起，中國鐵路客戶服務中心12306平台至今已不知不覺走過了13載春秋，也成為了大部份旅客乘坐高鐵出行的首選購票平台。
回顧12306的發展歷程可以說是一部與搶票軟體鬥智鬥勇，「魔高一尺道高一丈」的「史詩」。
2024國慶，鐵路迎來客運高峰ICPhoto
一切還得從12306成立的時候說起。隨著2011年6月12日第一張京津城際鐵路電子客票的售出，中國正式拉開了鐵路網路售票的序幕，此後短短幾個月，網路售票的範圍就急速擴充套件到了京滬、武廣、鄭西等高鐵路線。到9月30日，全國範圍的高鐵車票（G字頭、D字頭）都可以上12306購買。到2011年底，全國範圍的火車車票（Z字頭、T字頭、K字頭）都可以上12306購買。僅用了半年時間，中國鐵路網路購票就完成了「從無到有」到「全面普及」的飛躍！
但鐵路網路購票的新鮮感還沒消散，2012年的春運便悄然而至，春運——這一世界罕見的人口大遷徙盛況，每年都會給中國的交通行業帶來前所未有的壓力，可以說是交通行業的「大考」。而12306的第一次系統崩潰也來得出乎所有人的預料。
從2012年1月5日起，12306網站連續5天點選量超過10億次，存取量環比上月激增10余倍，其中1月9日點選量超過14億次，成為全球最繁忙的網站之一——要知道2011年底中國網民也才5億人。
對於這樣的存取壓力平台在建設之初並非沒有考慮到。12306系統建設之初，在借鑒和參考客票核心系統架構的基礎上，根據互聯網套用的特點，研發者們為系統設計了緩存服務、使用者管理、車票查詢、訂單及電子客票處理等多個相對獨立的業務分區，以及三級網路安全域，分別是外網、內網和客票網。上線前的壓力測試，一筆流程包含使用者登入、車票查詢、下單及支付等業務操作，系統極限交易能力為34張/秒，按高峰期10小時計算，售票量可達到120萬張/天的設計能力。
然而，壓力測試卻漏算了一個「不速之客」——搶票軟體。搶票軟體是一種基於瀏覽器的外掛程式，利用機器的快速反應來幫助使用者完成不斷查詢和重新整理頁面的動作，透過高頻查詢車次余票、自動填寫個人資訊、多帳號同時操作等方式，從而比手動購票的使用者更快完成購票流程。
苦於平台「無票」的旅客為了確保萬無一失只能花錢求助搶票軟體
由於缺乏對搶票軟體造成的超大流量存取的充分預估，導致12306在大量搶票軟體面前不堪一擊——12306網站出現癱瘓情況，大量使用者無法登入，頁畫重新整理時間長達30分鐘，訂票付了款卻無法購票。不少購票者無奈地怒斥12306網站「形同虛設」。
但是開弓沒有回頭箭，12306客票團隊只能背水一戰了：針對頻寬不足的問題，12306客票團隊當機立斷，迅速將頻寬由600兆上調至1000兆，不久又上調至1500兆；客票團隊對網上購票數據進行監控與分析後發現，極個別使用者在網上大量購票，單日購票總量竟超過100張。為保證購票公平，自1月5日起，12306客票團隊對網上購票流程進行了調整，在使用者購票成功後系統將強制使用者結束，再次購票時需重新登入。
原鐵道部還想到了邀請「外援」，當時所有網站中有豐富的「短時間內存取量劇增下不垮掉」經驗的莫過於「雙十一」搞得如火如荼的天貓和淘寶了。於是，阿裏巴巴集團派出17名技術精英組成計畫組，協助12306網站進行最佳化和改進。兩支團隊並肩作戰，使12306網站的使用者體驗得到了極大地改善。系統的每日售票量由1月上旬的65萬張提高到100萬張以上，並於1月20日創造了119.2萬張的日售票最高紀錄。
天貓淘寶商城的「雙11全球購物狂歡節」宣傳廣告霸屏上海徐家匯地鐵站爭奪使用者人氣流量IC Photo
這場上線不到一年的春運「極限測試」過後，互聯網上也出現了關於12306架構的討論和爭議，當時的鐵道部透過認真聽取各方意見，也在認真梳理問題的原因，總結出主要是由於車票查詢以及訂單/電子客票業務分區處理能力不足，造成高峰期高並行存取請求下響應時間過長，加之各個業務分區未能很好進行隔離，導致系統由內至外產生「雪崩」效應，造成網站擁堵，影響使用者的購票體驗。
針對上述問題及原因，研發者將架構最佳化及重構思路重點放在提升車票查詢和交易處理的響應速度，提升後台系統的擴充套件性，改變網上排隊方式，減輕高峰時段集中放票造成的頻寬壓力。同時盡可能分離核心業務，減少業務環節間的強關聯，具體內容包括：
首先，必須大幅提升並行查詢能力，12306使用記憶體計算資料庫取代傳統資料庫，將車票查詢的響應速度由不足1000次/秒提升至超過20000次/秒，響應時間由原來的1s縮減至10ms，使使用者可以快速獲取到車次及余票情況。
其次，要讓使用者在高峰期「排隊下單不擁堵」，為此12306構建了交易處理排隊系統，佇列的下單請求接收能力超過10萬筆/秒，使用者可以在售票高峰期迅速完成下單操作，等候系統依次處理，等候過程中可以查詢排隊狀態（等候處理的時間）。排隊系統中也采用了記憶體計算資料庫。
第三，對訂單/電子客票進行分節點分庫分表改造，將原有的1個節點、1個庫、1張表拆分為3個節點、30個庫、30張表，線上相關操作被分散到各個節點和庫表中，這樣，使用者在網站上的訂票請求可以得到更快的響應和處理。
最後，對訂票、取票操作進行了業務分離，由不同的業務節點（售票節點和取票節點）承載網上售票和線下取票業務；對訂單/電子客票生成和查詢進行了讀寫分離，使用記憶體計算資料庫集中儲存訂單/電子客票，訂單查詢的響應速度由200次/秒左右提升至5000次/秒以上，大幅提升了訂單/電子客票的查詢效率。
最佳化架構後的系統在上線前壓力的測試中，極限交易能力為300張/秒，可以滿足日售票量500萬的業務需求。2013年春運，最佳化架構後的12306網站最高日售票量達到364萬，占全路售票量的40%，售票量為2012年春運最高峰（119萬）的3倍多。
2013年2月14日，家長帶著孩子在安徽省淮北火車站候車返程。IC Photo
然而，對於12306平台的需求依然在急速增長，原有的改良很快到達極限。2013年十一黃金周，12306互聯網售票量達到了460萬，再次接近系統處理的上限，且由於3G網路的限制（4G網元年但未普及）和網民數量的迅速增長導致高峰期外網入口頻寬緊張，已不能滿足互聯網售票量進一步提升的需要。此外，作為鐵路售票的主要渠道，互聯網售票系統單中心執行模式已不能滿足業務安全性和可靠性的需求。
為此，自2013年底起啟動了12306網站的第2輪架構最佳化：
將使用者登入及常用聯系人查詢等業務遷移至記憶體資料庫中，提高了相關業務的處理效能和可靠性。
構建了鐵科院第2生產中心，與既有的中國國家鐵路集團有限公司第1生產中心間實作「雙活」，提升網站的安全性和可靠性，並將訂單/電子客票集群的處理能力提高1倍。訂單/電子客票集群擴充至10組節點、100個庫、100張表。
在公有雲上部署車票查詢服務，透過策略配置可隨時將車票查詢流量分流至公用雲，以緩解在售票高峰期網站的處理資源和頻寬壓力。
上線前的壓力測試驗證了系統可以滿足1000萬張/天的設計售票能力，在2015年春運高峰時段，實際售票速度超過了1000張/秒（約合360萬張/時）。公有雲在2015年春運期間最高分流了75%的查詢請求，網站對外車票查詢服務能力增加了3倍。12306網站在2015年春運高峰日處理了超過180億次車票查詢服務，平均響應速度超過30萬次/秒。
隨著12306對於春運「極限壓力」的承載能力超級加倍，一度讓設計和營運團隊頭疼不已的「搶票外掛」已然成為了最大的不穩定因素。12306團隊雖然一再抗議購票使用搶票軟體，但是網路上依靠自動頻繁重新整理車票資訊、進行自動填報搶票的小軟體依舊層出不窮。這類軟體透過快速重新整理票務資訊，提高搶票成功率，旨在幫助使用者在第一時間搶到車票。雖然滿足了市場需求，但同時嚴重幹擾了手動購票的大眾，影響了購票的公平性；且為了提高成功率，使用者往往需要提前在系統輸入乘車人的個人資訊，在「搶票」的焦慮中，親手將個人資訊泄露了出去。
在這樣的背景下12306團隊也必須做出有針對性的改變——除了持續最佳化系統的高峰處理能力外，還引入了實名制、復雜驗證碼、手機驗證碼等功能，但依舊無法遏制搶票軟體的猖獗，導致在春運、十一黃金周期間依舊出現網路不暢的購票現象。
直到2019年春運期間，12306試點候補購票服務功能。這一功能是將手動操作的使用者訂單與搶票軟體的使用者訂單放到同一個「獎池」裏，大家進行公平競爭，系統隨機挑選「中獎者」完成接下去的購票流程，這樣一來，即使刷屏再快的搶票軟體也再無優勢可言，這才使得搶票軟體的風頭被逐漸遏制。
正所謂「魔高一尺道高一丈」，候補票模式是12306針對搶票軟體的一記重拳，但在利益的驅動下，搶票軟體必定會繼續針對這一模式再次進行不公平的競爭，例如提高搶票軟體訂單在候補票獎池中的「中獎機率」等。相信我們12306團隊能夠克服困難，維護好全球存取量最大、交易量最大的票務系統，雙方的「鬥智鬥勇」依然伴隨著中國不斷發展的鐵路網路和居民出行的需求不斷前進演化著。
