前言
秒殺場景在生活中幾乎隨處可見, 不論是商品搶購、春運搶票還是一個隨處可見的紅包, 都會涉及到秒殺的場景. 在面試中, 秒殺業務的設計也成為熱門題目為面試官和應聘者津津樂道.
接下來, 本文將針對秒殺場景中的搶紅包實現方案進行分享, 包括紅包業務常見的實現方案, 瓶頸及優化.
分析
場景
紅包的應用場景有很多, 如隨機紅包、定額紅包等, 甚至還有結合其他促銷業務的紅包變種如搶購物津貼等. 但從技術的角度來看, 不論玩法有多少變化, 其核心都是相似的:
- 穩定: 扛得住突發的大流量, 確保紅包都能成功派發.
- 準確: 數據一定要正確, 不能出現超額派發的情況.
業務
搶紅包可能會由于業務需求不同而產生很多變種, 設計上要足夠抽象, 不能為了搶現金紅包和搶購物津貼紅包寫多份相似的代碼. 搶到紅包的后置操作可以作為消息, 由不同的業務模塊自行處理.
技術
搶紅包核心業務不復雜, 其關鍵點在于應對高并發、資源爭用等.
- 高并發: 異步、橫向擴展負載均衡、限流等.
- 讀多寫少: 緩存.
- 資源爭用: 原子操作, 緩存或數據庫等層面可進行控制. 如使用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
- UPDATE IGNORE ... LIMIT 1 : 解決了資源爭用問題, 確保并發請求下紅包的領取的數據正確性.
- red_envelop_id + user_id : 創建索引并唯一約束, 確保對于同一個紅包同一用戶只能領取一次.
- 預分配的user_id為負值: 因為red_envelop_id + user_id 有唯一約束.
- 對于一般流量的小型活動, 這種方式實現簡單、成本低, 不引入緩存的情況下只用一個MySQL基本也能扛得住.
方案二 —— 實時分配
適用場景
領取人數無法估計、頻發退款, 如群組紅包(經常發生剩余退款)
實現細節
流程
- 開搶前將紅包信息加載到緩存, 首次加載時間可長一些
- 搶紅包: 從緩存讀取(沒有則加載), 分配紅包后原子更新緩存(若已發放完畢則直接返回失敗)
- 緩存更新后寫入數據庫(校驗數據正確性)
紅包發放記錄
unique: 紅包ID+領取用戶ID
- 首次緩存加載時間要稍長一點: 紅包剛開始發放時可能會有較大的突發流量, 此時去DB加載緩存不合適.
- 緩存可以不用和數據庫保證強一致: 數據的正確性由數據庫進行維護, 如: 緩存扣除了紅包額度, 但更新數據庫時發生了異常, 此時緩存不需要回滾, 待緩存失效后重新加載即可.(所以緩存時間可以是幾秒鐘, 不用太長)
- 更新緩存可以考慮使用Lua腳本以保證原子性.
- 實時分配紅包不會產生無效的記錄, 適合大多數場景, 但實現比預分配復雜的多.
細節及優化
- 客戶端點擊頻率控制能在一定程度上減少流量.
- 紅包領光后在緩存一層攔截掉全部請求, 直接返回失敗.
- 網關層進行限流.
結語
秒殺場景其特點是高并發、讀多寫少、資源爭用, 每一個點都需要根據其業務場景選擇適合的解決方案, 如使用緩存解決頻繁讀取的問題、使用隊列解決數據庫性能瓶頸等.
對于搶紅包業務來說, 預分配和實時分配都是行之有效的方案, 各有優劣, 具體選擇哪種, 還是要看業務需求.
如果這篇文章對您有幫助，請點個贊吧 (￣▽￣)"
原文：https://blog.piaoruiqing.com/blog
