秒殺場景實踐之搶紅包常用解決方案文章地址: https://blog.piaoruiqing.com/blog/2019/09/01/秒殺場景實踐之搶紅包一/
前言
秒殺場景在生活中幾乎隨處可見, 不論是商品搶購、春運搶票還是一個隨處可見的紅包, 都會涉及到秒殺的場景. 在面試中, 秒殺業務的設計也成爲熱門題目爲面試官和應聘者津津樂道.
接下來, 本文將針對秒殺場景中的搶紅包實現方案進行分享, 包括紅包業務常見的實現方案, 瓶頸及優化.
分析
場景
紅包的應用場景有很多, 如隨機紅包、定額紅包等, 甚至還有結合其他促銷業務的紅包變種如搶購物津貼等. 但從技術的角度來看, 不論玩法有多少變化, 其核心都是相似的:
- 穩定: 扛得住突發的大流量, 確保紅包都能成功派發.
- 準確: 數據一定要正確, 不能出現超額派發的情況.
業務
搶紅包可能會由於業務需求不同而產生很多變種, 設計上要足夠抽象, 不能爲了搶現金紅包和搶購物津貼紅包寫多份相似的代碼. 搶到紅包的後置操作可以作爲消息, 由不同的業務模塊自行處理.
技術
搶紅包核心業務不復雜, 其關鍵點在於應對高併發、資源爭用等.
- 高併發: 異步、橫向擴展負載均衡、限流等.
- 讀多寫少: 緩存.
- 資源爭用: 原子操作, 緩存或數據庫等層面可進行控制. 如使用Lua腳本進行減庫存操作.
方案一 —— 預分配
適用場景
紅包數量相對合理, 很少產生庫存剩餘的情況、用戶量級不大的情況.
- 優勢: 實現簡單、配合緩存很容易應對高併發
- 不足: 頻繁發放較多數量大的紅包會導致一次性寫入大量分配記錄, 如果領取的人不多, 會產生很多無效數據.
簡要描述
預分配是在發放紅包時, 根據紅包總額和數量、按照既定算法進行分配, 提前創建好全部的紅包分配記錄. 領取時只是將紅包分配記錄進行更新.
比較適合系統發放的紅包(面向某一標籤的全部用戶羣體, 發出的紅包基本會被領取完), 不適合用戶羣組紅包(無法控制領取紅包人數, 當紅包個數遠大於羣組人數的情況下, 無效數據比較多, 比如在一個10人羣組發放一個數量爲1000的紅包).
實現細節
流程
- 在紅包開搶前, 預先分配好紅包領取記錄, 領取記錄的用戶ID爲負值.
- 開搶後, 開放唯一領取紅包的入口
-
領取操作核心就是更新紅包分配記錄:
-- 此處劃重點 (￣▽￣)" UPDATE IGNORE record SET user_id = {userId}, gmt_receive = UNIX_TIMESTAMP() WHERE red_envelop_id = 1 AND user_id < 0 LIMIT 1; -- red_envelop_id + user_id 有唯一約束
紅包發放記錄
| ID | 總金額 | 數量 | ... |
|---|---|---|---|
| 1 | 100 | 3 | ... |
紅包分配記錄
unique:紅包ID+領取用戶ID
| ID | 紅包ID | 金額 | 領取用戶ID | 領取時間 | ... |
|---|---|---|---|---|---|
| 1 | 1 | 10 | -1 | 0 | ... |
| 2 | 1 | 60 | -2 | 0 | ... |
| 3 | 1 | 30 | -3 | 0 | ... |
備註
-
UPDATE IGNORE ... LIMIT 1: 解決了資源爭用問題, 確保併發請求下紅包的領取的數據正確性. -
red_envelop_id+user_id: 創建索引並唯一約束, 確保對於同一個紅包同一用戶只能領取一次. - 預分配的
user_id爲負值: 因爲red_envelop_id+user_id有唯一約束. - 對於一般流量的小型活動, 這種方式實現簡單、成本低, 不引入緩存的情況下只用一個MySQL基本也能扛得住.
[版權聲明]
本文發佈於樸瑞卿的博客, 允許非商業用途轉載, 但轉載必須保留原作者樸瑞卿 及鏈接:blog.piaoruiqing.com. 如有授權方面的協商或合作, 請聯繫郵箱: [email protected].
方案二 —— 實時分配
適用場景
領取人數無法估計、頻發退款, 如羣組紅包(經常發生剩餘退款)
實現細節
流程
- 開搶前將紅包信息加載到緩存, 首次加載時間可長一些
- 搶紅包: 從緩存讀取(沒有則加載), 分配紅包後原子更新緩存(若已發放完畢則直接返回失敗)
- 緩存更新後寫入數據庫(校驗數據正確性)
紅包發放記錄
| ID | 總金額 | 數量 | 剩餘金額 | 剩餘數量 | ... |
|---|---|---|---|---|---|
| 1 | 100 | 3 | 100 | 3 | ... |
紅包分配記錄
unique:紅包ID+領取用戶ID
| ID | 紅包ID | 金額 | 領取用戶ID | 領取時間 | ... |
|---|---|---|---|---|---|
| ... | ... | ... | ... | ... |
備註
- 首次緩存加載時間要稍長一點: 紅包剛開始發放時可能會有較大的突發流量, 此時去DB加載緩存不合適.
- 緩存可以不用和數據庫保證強一致: 數據的正確性由數據庫進行維護, 如: 緩存扣除了紅包額度, 但更新數據庫時發生了異常, 此時緩存不需要回滾, 待緩存失效後重新加載即可.(所以緩存時間可以是幾秒鐘, 不用太長)
- 更新緩存可以考慮使用Lua腳本以保證原子性.
- 實時分配紅包不會產生無效的記錄, 適合大多數場景, 但實現比預分配複雜的多.
細節及優化
- 客戶端點擊頻率控制能在一定程度上減少流量.
- 紅包領光後在緩存一層攔截掉全部請求, 直接返回失敗.
- 網關層進行限流.
結語
秒殺場景其特點是高併發、讀多寫少、資源爭用, 每一個點都需要根據其業務場景選擇適合的解決方案, 如使用緩存解決頻繁讀取的問題、使用隊列解決數據庫性能瓶頸等.
對於搶紅包業務來說, 預分配和實時分配都是行之有效的方案, 各有優劣, 具體選擇哪種, 還是要看業務需求.
歡迎關注公衆號: (代碼如詩)
[版權聲明]
本文發佈於樸瑞卿的博客, 允許非商業用途轉載, 但轉載必須保留原作者樸瑞卿 及鏈接:blog.piaoruiqing.com. 如有授權方面的協商或合作, 請聯繫郵箱: [email protected].
