前言
時間回退到 2010 年的 12306 官網，大家還記得多少，又卡又慢時常崩潰，服務器經常宕機的 12306，和今天穩定運行的 12306，就純技術角度而言，拋出一些問題，一起分享討論背后的技術變革
問題點 1 【動態庫存】
小編想買一張春節，“深圳–武漢” 的高鐵票，中途經過 8 個站點，中途售罄如何保證這趟車次的車票，在多站點庫存數據的實時同步，12306app 與車站售票系統的數據一致性問題，多站點下數據行鎖開銷、大事務處理
問題點 2【灰色流量】
春運、節假日應對超高並發和超高流量沖擊，智行火車票等一些搶票軟件，搶占資源帶寬，服務器如何響應並處理
解決思路
1. 技術角度，2010 年上線服務器經常宕機，2012 年進行了重構（解決了大流量請求查詢，讀多寫少），由 redis 切換至 pivotal gemfire 分布式系統的 CAP，服務器改為雲計算彈性擴容（分鍾級），爬蟲與反爬蟲
2. 產品角度，分時段售票（分散流量沖擊），后補車票（異步處理，隊列消費），驗證碼攔截（放棄部分用戶體驗）
參考資料
CAP 的問題 tanzu.vmware.com/content/blog/acid...
Pivotal Gemfire blog.verysu.com/sharearticle/1444