前言
時間回退到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
本作品採用《CC 協議》，轉載必須註明作者和本文連結