如何設計一個高可用、高並發秒殺系統

作者: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,手動關閉
  • 異步補單邏輯關閉。
  • 二級預案,後端隨機丟請求,接入層頻控失效或者下遊服務過載,手動開啟進入
  • 三級預案,前端隨機丟請求,後端服務過載或者宕機進入。手動開啟

綜上,整個瓜分時刻體驗如下所示:

如何設計一個高可用、高並發秒殺系統

回顧下漏鬥模型,總結下整個實踐:

如何設計一個高可用、高並發秒殺系統

Published in News by Awesome.

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *