如今的互聯網已經在海量服務領域有了很成熟的理論，因此自己也很慶幸，能夠從 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，手動關閉
- 異步補單邏輯關閉。
- 二級預案，後端隨機丟請求，接入層頻控失效或者下游服務過載，手動開啟進入
- 三級預案，前端隨機丟請求，後端服務過載或者宕機進入。手動開啟
綜上，整個瓜分時刻體驗如下所示：
回顧下漏斗模型，總結下整個實踐：
作者：vincentsu，騰訊 PCG 後臺開發工程師
閱讀更多 運營增長 的文章
