在外地打工的你，肯定都經曆過春運搶票！

經曆過網站進去就卡死、進去就無票的無奈！

今天從技術的角度來分析一下為什麼你買不到票！

買票

一 . 場景分析

都說12306做的爛，技術水平差，也難怪用戶吐槽，12306剛上線的時候，一到買票就崩潰，搞得大家都買不到，排隊起碼還能碰碰運氣，網上真的是無可奈何。

我們從技術角度看，全國幾億用戶，向潮水一樣湧進來買票，堪比98年的大洪水啊，誰能扛得住。

好在，經過多年的努力，現在的12306已經健碩了很多，雖然票還是難買，但僧多粥少，确實沒有辦法。

從數據量看，12306的數據肯定沒有微信qq、淘寶等這些大廠量大，但論并發量，肯定12306更大；車次上，也就幾千輛，每輛車座位幾千個，數據量都不大，但是可能100w人搶1000張票，鎖沖突是非常大的。一般的互聯網應用通過合理的分庫分表，都能很好的降低鎖沖突，但是對12306并不太适用，這就是為什麼12306難點所在。

二. 我們看看12306所采取的措施：

1. 複雜的驗證碼

“一票難求”，催生了大量的網絡刷票軟件，有免費的，有收費的，五花八門！不少網友也用過，一般還是有效的。刷票軟件從登錄、選票、下單，都通過程序完成，比人肉買票快不知多少倍，這也是為什麼到點就沒票的原因，因為一瞬間就賣完了。

所以，為了公平起見，官方就限制任何的三方刷票軟件，從登錄開始，就使用了複雜的驗證碼，采用圖片驗證碼，增加程序自動識别的難度，防止自動刷票軟件登錄；

驗證碼

在github上也有不少開源的搶票程序，感興趣的可以研究一下。

2. 客戶端的限制

查詢車票

查詢餘票時，在沒有返回結果之前，‘查詢’按鈕置灰，不能連續點擊，對于購票用戶中99%是普通用戶，這樣就限制了這些用戶無腦狂刷了。

3.票數顯示折中

因為餘票查詢是量非常大的操作，數據肯定放到了cache，如果顯示餘票數，每次數量變動都需要刷新cache，如果隻顯示 “有無”，就隻需要臨界值才需要淘汰。

查詢

4. 分散始發站售票時間

從早上8：00開始，到下午18：00 ，每個整點和半點都有始發站開始售票，這樣就把流量分散到了一天的多個點上，系統的壓力就大大減輕了

售票時間

5. 購票和支付分開

先購票，購票成功後可以45分鐘内付款，這樣支付系統壓力也小了很多，和購票流分開，也達到了錯峰的效果。

為了方便撿漏，網站還增加了候補功能，也避免了用戶一直刷票了。

三 . 上面都是我們看到的優化措施，那麼看不到的server端會采取哪些措施呢？

通過浏覽器前端的限制，99%的無效請求已經被攔截，但是對于專業人士，如刷票軟件，是可以輕松繞過這些限制的，仍然會有大量請求到達服務器，

1. 頻率限制

短時間内相同用戶的多次請求，肯定隻處理一次，其他的忽略請求計數可以通過redis來實現，也可以通過lua腳本來實現。通過頻率限制，99%的多餘請求也被過濾掉了。

2.cache的使用，

12306的特點是讀操作遠遠大于寫操作，應對海量的查詢請求，肯定會用到cache，唯一的瑕疵是數據同步沒那麼及時，所以有時候總是查詢有票，下單卻沒票，就是cache的數據還沒有及時更新。

3.請求排隊

把用戶請求先放隊列，如1000張票，可以放2000個請求進來，根據順序下單，售完後剩餘的請求返回失敗。

通過隊列和異步操作，把下單和支付一個點的事情擴展成了一個時間段來做，系統壓力大大減輕了。

通過層層過濾，大量的請求被攔截到了上遊，剩餘的在DB層處理的遊刃有餘了。

四 .總結：

通過以上的分析可見：

1. 系統表現層的一些改動，雖然稍微降低了用戶體驗 ，卻能大大降低系統難度，所以程序員同學費盡腦汁想方案，不如和産品好好聊一聊；

2. 針對具體業務 ，肯定還有很多的更細節的優化；

3.萬變不離其宗，其實根本的思想就是“限流” ，後續有時間再聊一聊高并發下的數據安全。

抛磚引玉 ，感謝閱讀，歡迎多提寶貴意見！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!