前言

針對於秒殺場景來說，流量往往在一個特定時間點有個高度集中的流量洪峰，這個瞬時對於資源的消耗是很大的，這時往往對於服務的穩定性帶來了極大的挑戰，如果按照流量洪峰預估系統資源，則可能存在極大的資源浪費。

所以協調好處理流量洪峰和資源利用率，最好的方式就是設計錯峰方案進行流量削峰。

削峰目的：

讓服務處理請求更加平緩，節省伺服器資源。

針對於削峰來說，本質上是延緩使用者請求的傳送，減少和過濾一些無效請求。

一般採用以下方式：

• 排隊
• 答題
• 分層過濾

這幾種方案都是無損的，當然有損的方案如限流，負載保護等，是另一種不得已的措施，以後再談。

排隊

流量削峰首先想到的就是佇列，將同步的請求轉換成非同步請求，將流量峰值通過訊息佇列平緩推送過去。

當然訊息佇列需要注意的是訊息擠壓和儲存上限等情況。

類似的排隊方式還有很多，如：

• 執行緒池加鎖
• 先進先出記憶體佇列
• 類似於binlog的順序寫讀處理的機制

答題

一般的電商系統秒殺時會有一個答題流程，主要是為了增加購買的複雜度，首先可以防止一些機器參與秒殺的場景，起到防止作弊的目的。還可以拉大請求時間緩解請求，控制流量達到削峰的目的。

由於經過答題之後的請求具有了先後順序，這樣對於後續的業務邏輯來說就可以很容易的控制了。

答題邏輯的設計：

• 題庫產生，生成一個個的問題和答案，問題也不用特別複雜，可以防止機器作弊即可。
• 題庫推送，在秒殺進行之前，將問題推送給交易系統。
• 問題圖片生成，用於將題目生成制定格式圖片，增加一些干擾因素，問題圖片可以提前推送到cdn進行預熱，不然在真正秒殺開始時，可能圖片載入緩慢影響使用者體驗。

答題邏輯比較簡單了，使用者提交答案，後臺比對題目和答案即可。

分層過濾

針對於秒殺場景來說，跟本質的做法是過濾無效請求，分層過濾是採用漏斗方式進行請求處理的。

請求流程：

• 大部分流量在使用者瀏覽器或者cdn上獲取，這一層可以攔截大量資料讀取。
• 前臺讀系統主要是一些快取cache，比如採用nginx+lua等方式攔截無效請求。
• 業務系統主要做好限流，排隊等操作。對資料做合理分片。
• 在最後的資料層做好資料強一致校驗，比如保證庫存的準確性（不能為負數）。

這樣請求經過一層層的漏斗過濾，會盡量將少的資料請求到後端了。

相關推薦