大量用戶同一時間搶紅包或者秒殺算法研究和整個思路

常常有人問我，大量用戶在同一時間點搶紅包，服務器是否是壓力很大，這個到底怎麼處理比較好，今天就寫一下大概個人一些經驗和一些思路供你們參考。

hihiabc原創，轉載請註明出處。

紅包的整個過程分爲發紅包階段和搶紅包階段，發紅包分兩種，一種是隨機紅包，一種是等額紅包，而搶紅包也分爲兩種狀況，一種是紅包還有，說明搶到了，一種是已經沒有了。

下面具體計解：

一，發紅包階段，輸入數據，首先是用戶在界面操做發紅包功能，支付成功，上傳數據，到後臺，後臺驗證經過。這一步沒有太多問題。主要是驗證好數據合法性，不要出現安全問題。

 

二，發紅包階段，後臺開始計算每一個紅包金額。

對於等額的紅包，固然沒有太多問題，不須要計算，對於隨機的紅包，就須要根據總金額和紅包個數來計算每人紅包究竟是多少。這個具體的算法後面再講，大概就是根據個數和總金額爲依據，有多種實現方式，網上也有不少紅包算法實現，大概是兩個思路， 一是設置最低紅包和最高紅包而後找一些隨時數來算出每一個紅包，二是先平分，再隨時調整每個紅包的大小，這裏就先不細講。這個要用代碼才說得清楚。

 

三，發紅包階段，保存紅包。

紅包計算好之後，須要有地方保存，固然首先是數據庫應該有一份完整的數據，其次是往消息隊列服務器發送一份數據。或者往緩存發送一份數據也行。總之這個數據在用戶開始搶的時候就須要用到了。

 

四，通知客戶端有人發紅包了。

這個過程沒有太多的說的，主要是每一個平臺裏面本身實現，有些平臺用長連接，有些平臺用短連接，該通知哪些人，或者哪一個羣，平臺本身實現就行。不過這種數據最好加密或者使用https傳輸。

 

五，用戶開始搶紅包，高潮的部分來了。

假如如今有100個紅包，可是有10萬我的點進來了怎麼辦，服務器是否是要掛掉了。這個地方有一些巧秒的算法大概說一說。

首先，每一個紅包的金額咱們已經算好了，因此這個地方已經省去了不少麻煩，不用每一個請求進來都去計算一次。

第二，咱們根據紅包的個數咱們設計一個隊列，好比這裏設計一個100長度的就夠了，實際作的時候能夠稍微長一點，用戶搶紅包的請求進來之後，咱們讓這100我的排隊處理分成包，這個過程也很快，直接去紅包數據裏面一個個取就是了，而後在緩存裏面用一個變量記錄一下當前紅包已經沒有了，這100我的之後的請求直接經過這個變量就直接返回沒有了，這100我的之後的請求只須要一個變量的判斷，因此處理速度是至關快，有再多的請求進來也不怕。只要你的緩存生效，不至於去查數據庫就沒問題，這個地方也要仔細設計，不能出現緩存穿透的狀況。

記得併發的時候邊界的處理，這個在具體實現的考慮就能夠了。這理就不仔細講了。

 

六， 有些狀況下能夠減小請求，就是讓客戶端知道這個紅包已經沒有了，這種狀況，也許都不須要發請求到後臺，直接提示紅包已經沒有了，這種作法看上去雖很差，但也確實有人使用過，並且這種請求也是無效請求。好比在本身平臺裏面規定，紅包超過24小時就不能搶了，這種搶紅包的請求就不須要發後臺了。在界面上直接提示就能夠了。不事後臺也要能處理，萬一在界面上沒有生理好，或者萬一有人繞過界面處理，因此後臺比較要處理，這種狀況，後臺根據時間判斷後直接返回就能夠了。沒有任何問題。

 

秒殺也同樣，只是秒殺不用預先計算數據，秒殺是減庫存。思路都有相似的地方。