作者：vincentsu，騰訊 PCG 后臺開發工程師

如今的互聯網已經在海量服務領域有了很成熟的理論，因此自己也很慶幸，能夠從 0 到 1 完整踐行海量服務。微視春節項目中的集卡瓜分活動，是一個典型的秒殺場景，自己參與其中，分享一些心得和總結。

如今的互聯網已經在海量服務領域有了很成熟的理論，因此自己也很慶幸，能夠從 0 到 1 完整踐行海量服務。微視春節項目中的集卡瓜分活動，是一個典型的秒殺場景，自己參與其中，分享一些心得和總結。

秒殺系統的難點

• 友好的用戶體驗

• 用戶不能接受破窗的體驗，例如：系統超時、系統錯誤的提示，或者直接 404 頁面

• 瞬時高并發流量的挑戰

• 木桶短板理論，整個系統的瓶頸往往都在 DB，如何設計出高并發、高可用系統？

如何設計

上圖是一個典型的互聯網業務，用戶完成一個寫操作，一般會通過接入層和邏輯層，這里的服務都是無狀態，可以通過平行拓展去解決高并發的問題；到了 db 層，必須要落到介質中，可以是磁盤/ssd/內存，如果出現 key 的沖突，會有一些并發控制技術，例如 cas/加鎖/串行排隊等。

直筒型

直筒型業務，指的是用戶請求 1:1 的洞穿到 db 層，如下圖所示。在比較簡單的業務中，才會采用這個模型。隨著業務規模復雜度上來，一定會有 db 和邏輯層分離、邏輯層和接入層分離。

漏斗型

漏斗型業務，指的是，用戶的請求，從客戶端到 db 層，層層遞減，遞減的程度視業務而定。例如當 10w 人去搶 1 個物品時，db 層的請求在個位數量級，這就是比較理想的模型。如下圖所示

這個模型，是高并發的基礎，翻譯一下就是下面這些：

• 及早發現，及早拒絕

• Fast Fail

• 前端保護后端

如何實現漏斗型系統

漏斗型系統需要從產品策略/客戶端/接入層/邏輯層/DB 層全方位立體的設計。

產品策略

• 輕重邏輯分離，以秒殺為例，將搶到和到賬分開；

• 搶到，是比較輕的操作，庫存扣成功后，就可以成功了

• 到賬，是比較重的操作，需要涉及到到事務操作

• 用戶分流，以整點秒殺活動為例，在 1 分鐘內，陸續對用戶放開入口，將所有用戶請求打散在 60s 內，請求就可以降一個數量級

• 頁面簡化，在秒殺開始的時候，需要簡化頁面展示，該時刻只保留和秒殺相關的功能。例如，秒殺開始的時候，頁面可以不展示推薦的商品。

客戶端

• 重試策略非常關鍵，如果用戶秒殺失敗了，頻繁重試，會加劇后端的雪崩。如何重試呢？根據后端返回碼的約定，有兩種方法：

• 不允許重試錯誤，此時 ui 和文案都需要有一個提示。同時不允許重試

• 可重試錯誤，需要策略重試，例如二進制退避法。同時文案和 ui 需要提示。

• ui 和文案，秒殺開始前后，用戶的所有異常都需要有精心設計的 ui 和文案提示。例如：【當前活動太火爆，請稍后再重試】【你的貨物堵在路上，請稍后查看】等

• 前端隨機丟棄請求可以作為降級方案，當用戶流量遠遠大于系統容量時，人工下發隨機丟棄標記，用戶本地客戶端開始隨機丟棄請求。

接入層

• 所有請求需要鑒權，校驗合法身份

• 如果是長鏈接的服務，鑒權粒度可以在 session 級別；如果是短鏈接業務，需要應對這種高并發流量，例如 cache 等

• 根據后端系統容量，需要一個全局的限流功能，通常有兩種做法：

• 設置好 N 后，動態獲取機器部署情況 M，然后下發單機限流值 N/M。要求請求均勻訪問，部署機器統一。

• 維護全局 key，以時間戳建 key。有熱 key 問題，可以通過增加更細粒度的 key 或者定時更新 key 的方法。

• 對于單用戶/單 ip 需要頻控，主要是防黑產和惡意用戶。如果秒殺是有條件的，例如需要完成 xxx 任務，解鎖資格，對于獲得資格的步驟，可以進行安全掃描，識別出黑產和惡意用戶。

邏輯層

• 邏輯層首先應該進入校驗邏輯，例如參數的合法性，是否有資格，如果失敗的用戶，快速返回，避免請求洞穿到 db。

• 異步補單，對于已經扣除秒殺資格的用戶，如果發貨失敗后，通常的兩種做法是：

• 事務回滾，回滾本次行為，提示用戶重試。這個代價特別大，而且用戶重試和前面的重試策略結合的話，用戶體驗也不大流暢。

• 異步重做，記錄本次用戶的 log，提示用戶【稍后查看，正在發貨中】，后臺在峰值過后，啟動異步補單。需要服務支持冪等

• 對于發貨的庫存，需要處理熱 key。通常的做法是，維護多個 key，每個用戶固定去某個查詢庫存。對于大量人搶紅包的場景，可以提前分配。

存儲層

對于業務模型而言，對于 db 的要求需要保證幾個原則：

• 可靠性

• 主備：主備能互相切換，一般要求在同城跨機房

• 異地容災：當一地異常，數據能恢復，異地能選主

• 數據需要持久化到磁盤，或者更冷的設備

• 一致性

• 對于秒殺而言，需要嚴格的一致性，一般要求主備嚴格的一致。

實踐——微視集卡瓜分系統

微視集卡瓜分項目屬于微視春節項目之一。用戶的體驗流程如下：

架構圖

• 客戶端主要是微視主 app 和 h5 頁面，主 app 是入口，h5 頁面是集卡活動頁面和瓜分頁面。

• 邏輯部分為分：發卡來源、集卡模塊、獎品模塊，發卡來源主要是任務模塊；集卡模塊主要由活動模塊和集卡模塊組成。瓜分部分主要在活動控制層。

• 獎品模塊主要是發錢和其他獎品。

瓜分降級預案

為了做好瓜分時刻的高并發，對整個系統需要保證兩個重要的事情：

• 全鏈路梳理，包括調用鏈的合理性和時延設置

• 降級服務預案分析，提升系統的魯棒性

如下圖所示，是針對瓜分全鏈路調用分析如下圖，需要特別說明的幾點：

• 時延很重要，需要全鏈路分析。不但可以提高吞吐量，而且可以快速暴露系統的瓶頸。

• 峰值時刻，補單邏輯需要關閉，避免加劇雪崩。

我們的降級預案大概如下：

• 一級預案，瓜分時刻前后 5 分鐘自動進入：

• 入口處 1 分鐘內陸續放開入口倒計時，未登錄用戶不彈入口

• 主會場排隊，進入主會場以 100wqps 為例，超過了進入排隊，由接入層頻控控制

• 拉取資格接口排隊，拉取資格接口 100wqps，超過了進入排隊，由接入層頻控控制

• 搶紅包排隊，搶紅包 100wqps，超過了進入排隊，由接入層頻控控制

• 紅包到賬排隊，如果資格扣除成功，現金發放失敗，進入排隊，24 小時內到賬。異步補單

• 入口處調用后端非關鍵 rpc:ParticipateStatus，手動關閉

• 異步補單邏輯關閉。

• 二級預案，后端隨機丟請求，接入層頻控失效或者下游服務過載，手動開啟進入

• 三級預案，前端隨機丟請求，后端服務過載或者宕機進入。手動開啟

綜上，整個瓜分時刻體驗如下所示：

回顧下漏斗模型，總結下整個實踐：

總結

以上是生活随笔為你收集整理的如何设计一个高可用、高并发秒杀系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。