大白話聊聊秒殺系統的優化思路

目錄

       一、秒殺業務的難點

       二、秒殺業務的優化方向

       3.  常見的秒殺架構

       4.  秒殺業務的各層次優化細節
複製代碼

你們好，我是四九城最豪橫的小耳朵。

今天我們來用大白話聊聊秒殺系統的優化思路。

一、 秒殺業務的難點 常見的秒殺場景：

京東、淘寶上手機商品的秒殺場景，可能手機只有10部，但瞬時進入的流量多是幾百、甚至幾千萬。

12306搶票場景，票是有限的，庫存只有一份，可是瞬時流量很是多，都去讀相同的庫存。會形成讀寫衝突，鎖異常嚴重，這是秒殺業務難的地方。

二、秒殺業務的優化方向 那怎麼去優化呢？

（1）將請求儘可能攔截在系統上游，不要讓鎖衝突落到數據庫上去。傳統秒殺系統之因此掛，是由於請求都壓倒了後端數據層，數據讀寫鎖衝突嚴重，併發高響應慢，幾乎全部請求都超時，流量雖大，可是下單成功的有效流量甚小。好比咱們常見的購票軟件12306，一列火車其實只有2000張票，200w我的來買，基本沒有人能買成功，請求有效率爲0。

（2）充分利用緩存。秒殺買票，這是一個典型的讀多寫少的應用場景，大部分請求是車次查詢，票查詢，下單和支付纔是寫請求。一趟火車其實只有2000張票，200w我的來買，最多2000我的下單成功，其餘人都是查詢庫存，寫比例可能只有0.1%，讀比例卻佔99.9%，這種場景很是適合使用緩存來優化。

三、常見的秒殺架構 常見的站點架構業務以下：

瀏覽器/手機 -----> 服務 -----> 數據

（1）瀏覽器/手機端，最上層，會執行到一些JS代碼或安卓代碼，發送請求給站點 （2）服務層，向上遊屏蔽底層數據細節，提供數據訪問 （3）數據層，最終的庫存是存在這裏的，mysql是一個典型

四、秒殺業務的各層次優化細節

第1層：瀏覽器層、APP層優化

（1）產品層面，用戶點擊「查詢」或者「購票」後，按鈕置灰，禁止用戶重複提交請求；

（b）JS層面，限制用戶在x秒以內只能提交一次請求；

APP層面，能夠作相似的事情，雖然你瘋狂的在搖微信，其實x秒才向後端發起一次請求。這就是所謂的「將請求儘可能攔截在系統上游」，越上游越好，瀏覽器層，APP層就給攔住，這樣就能擋住80%+的請求。

第2層 服務層優化

服務層怎麼攔截？若是已經清楚的知道秒殺的手機只有100部，一列火車只有2500張車票，那麼你放10w個請求去數據庫又有什麼意義呢？這種場景下能夠使用請求隊列來解決。對於寫請求，作請求隊列，每次只透有限的寫請求去數據層。

好比100部手機，只透100個下單請求去db

2500張火車票，只透2500個下單請求去db

若是均成功再放下一批，若是庫存不夠則隊列裏的寫請求所有返回「已售完」。

對於讀請求，怎麼優化？能夠用緩存抗，redis單機抗個每秒10w徹底沒什麼問題。

這種限流方案，只有很是少的寫請求，和很是少的讀緩存的請求會透到數據層去，而99.9%的無用請求被攔住了。

固然，業務規則上也能夠作一些優化。好比12306的按時間段放票，能夠將流量攤勻。

還有，數據粒度也能夠作優化。好比你去購票，對於餘票查詢這個業務，票剩了500張，仍是300張，你真的關注麼，其實咱們關心的是有票和無票罷了，流量大的時候，作一個粗粒度的「有票」「無票」緩存便可。

第3層 最後是數據庫層

瀏覽器攔截了90%，服務層又作了寫請求隊列與數據緩存，每次透到數據庫層的請求都是可控的。db基本就沒什麼壓力了，單機也能扛得住。並且經過對第2次服務層的優化，也保證了請求的有效率。

以上，就是秒殺系統的優化思路。

End
複製代碼

做者簡介：豪橫的小耳朵，一個豪橫的程序員。想和你們一塊兒在技術的世界裏豪橫，用技術的眼光去看待世界。歡迎掃描下方二維碼，持續關注，一大波原創系列文章正在路上。

關注後回覆「666」，可免費獲取java高級工程師學習資料一份。