秒殺架構設計

限流

因爲活動庫存量通常都是不多，對應的只有少部分用戶才能秒殺成功。因此咱們須要限制大部分用戶流量，只准少許用戶流量進入後端服務器

削峯

秒殺開始的那一瞬間，會有大量用戶衝擊進來，因此在開始時候會有一個瞬間流量峯值。如何把瞬間的流量峯值變得更平緩，是可否成功設計好秒殺系統的關鍵因素。實現流量削峯填谷，通常的採用緩存和 MQ 中間件來解決

異步

秒殺其實能夠當作高併發系統來處理，在這個時候，能夠考慮從業務上作兼容，將同步的業務，設計成異步處理的任務，提升網站的總體可用性

緩存

秒殺系統的瓶頸主要體如今下訂單、扣減庫存流程中。在這些流程中主要用到 OLTP 的數據庫，相似 MySQL、SQLServer、Oracle。因爲數據庫底層採用 B+ 樹的儲存結構，對應咱們隨機寫入與讀取的效率，相對較低。若是咱們把部分業務邏輯遷移到內存的緩存或者 Redis 中，會極大的提升併發效率

 

客戶端優化

緩存秒殺頁面：將秒殺頁面靜態化以後的頁面分發到 CDN 邊緣節點上，起到壓力分散的做用。

防止提早下單：主要是在靜態化頁面中加入一個 JS 文件引用，該 JS 文件包含活動是否開始的標記以及開始時的動態下單頁面的 URL 參數。同時，這個 JS 文件是不會被 CDN 系統緩存的，會一直請求後端服務的，因此這個 JS 文件必定要很小。當活動快開始的時候（好比提早），經過後臺接口修改這個 JS 文件使之生效

 

API 接入層優化

限制用戶維度訪問頻率

針對同一個用戶（ Userid 維度），作頁面級別緩存，單元時間內的請求，統一走緩存，返回同一個頁面

限制商品維度訪問頻率

大量請求同時間段查詢同一個商品時，能夠作頁面級別緩存，無論下回是誰來訪問，只要是這個頁面就直接返回

 

SOA 服務層優化

對於後端系統的控制能夠經過消息隊列、異步處理、提升併發等方式解決。對於超過系統水位線的請求，直接採起 「Fail-Fast」原則，拒絕掉

秒殺系統核心在於層層過濾，逐漸遞減瞬時訪問壓力，減小最終對數據庫的衝擊。

MQ 排隊服務，只要 MQ 排隊服務頂住，後面下訂單與扣減庫存的壓力都是本身能控制的，根據數據庫的壓力，能夠定製化建立訂單消費者的數量，避免出現消費者數據量過多，致使數據庫壓力過大或者直接宕機。

庫存服務專門爲秒殺的商品提供庫存管理，實現提早鎖定庫存，避免超賣的現象。同時，經過超時處理任務發現已搶到商品，但未付款的訂單，並在規定付款時間後，處理這些訂單，將恢復訂單商品對應的庫存量

 

總結

核心思想：層層過濾

• 儘可能將請求攔截在上游，下降下游的壓力

• 充分利用緩存與消息隊列，提升請求處理速度以及削峯填谷的做用

 

https://mp.weixin.qq.com/s/655E_pHo_xNhf8BrrMQrAw

 

 

 

秒殺系統特色，庫存只有一份，全部人會在集中的時間讀和寫這些數據，多我的讀一個數據。

優化思想：

將請求儘可能攔截在系統上游（不要讓鎖衝突落到數據庫上去）。

充分利用緩存，秒殺買票，這是一個典型的讀多些少的應用場景，大部分請求是車次查詢，票查詢，下單和支付纔是寫請求。

優化方案：

客戶端怎麼優化（瀏覽器層，APP層）

    產品層面，用戶點擊「查詢」或者「購票」後，按鈕置灰，禁止用戶重複提交請求；

    JS層面，限制用戶在x秒以內只能提交一次請求；

站點層面的請求攔截

    站點層面，對uid進行請求計數和去重，甚至不須要統一存儲計數，直接站點層內存存儲（這樣計數會不許，但最簡單）。一個uid，5秒只准透過1個請求，這樣又能攔住99%的for循環請求。

    5s只透過一個請求，其他的請求怎麼辦？緩存，頁面緩存，同一個uid，限制訪問頻度，作頁面緩存，x秒內到達站點層的請求，均返回同一頁面。

服務層來攔截（反正就是不要讓請求落到數據庫上去）

        對於寫請求，作請求隊列，每次只透有限的寫請求去數據層（下訂單，支付這樣的寫業務）

1w部手機，只透1w個下單請求去db

3k張火車票，只透3k個下單請求去db

若是均成功再放下一批，若是庫存不夠則隊列裏的寫請求所有返回「已售完」。

        對於讀請求，怎麼優化？cache抗，不論是memcached仍是redis，單機抗個每秒10w應該都是沒什麼問題的。如此限流，只有很是少的寫請求，和很是少的讀緩存mis的請求會透到數據層去，又有99.9%的請求被攔住了。

 

總結

上文應該描述的很是清楚了，沒什麼總結了，對於秒殺系統，再次重複下我我的經驗的兩個架構優化思路：

（1）儘可能將請求攔截在系統上游（越上游越好）；

（2）讀多寫少的經常使用多使用緩存（緩存抗讀壓力）；

瀏覽器和APP：作限速

站點層：按照uid作限速，作頁面緩存

服務層：按照業務作寫請求隊列控制流量，作數據緩存

數據層：閒庭信步

而且：結合業務作優化

 

https://mp.weixin.qq.com/s/L6_kw3MInnTLV1Gg5xmZ5w