秒殺系統設計

考慮因素：當QPS達到極限時，CPU使用率是否超過95%(鎖限制、I/O阻塞)，不然還有待提高空間。

 

架構原則：(4要1不要)

    1.數據要儘可能少(請求數據與響應數據)。減小數據的壓縮與編碼消耗CPU以及網絡傳輸

   2.請求數要儘可能少。CSS與JS請求合併，後臺請求數也要少(每次請求3次握手4次揮手)

   3.後臺服務路徑要短。後臺微服務鏈接要少，能夠加強可用性,同時提高性能(減小節點數據交互序列化及網絡傳輸損耗)

   4.依賴要儘可能減小。降級非必要信息(優惠券，成交列表，商品推薦等),減小頁面複雜度。

   5.不要有單點。

 

設計方案：

   先作數據的動靜分離：數據中是否含有和訪問者相關的個性化數據，頁面html、CSS、JS、圖片等靜態信息由nginx來處理，CDN來抗峯值

    將靜態數據頁面信息緩存到用戶瀏覽器中

    將動態請求的讀數據Cache在Web端，將商品相關信息cache起來。每次請求加載商品信息直接緩存讀取。

    對讀數據不作強一致性校驗

    對寫數據進行基於時間的合理分片：秒殺答題

    對寫請求作限流保護,多餘的請求用RateLimiter、Semaphore 限流過濾

    對寫數據進行強一致性校驗

 

　　　　

 

頁面靜態化：將活動頁面上的全部能夠靜態的元素所有靜態化，並儘可能減小動態元素。經過CDN來抗峯值。 
禁止重複提交：用戶提交以後按鈕置灰，禁止重複提交 
用戶限流：在某一時間段內只容許用戶提交一次請求，好比能夠採起IP限流

限制IP訪問頻率：咱們上面攔截了瀏覽器訪問的請求，但針對某些惡意攻擊或其它插件，在nginx限制訪問頻率。

 

削峯方案：

一個是經過隊列來緩衝請求，即控制請求的發出；

一個是經過答題來延長請求發出的時間，在請求發出後承接請求時進行控制，最後再對不符合條件的請求進行過濾；

最後一種是對請求進行分層過濾。

 

一、將動態請求的讀數據緩存（Cache）在 Web 端，過濾掉無效的數據讀；

二、對讀數據不作強一致性校驗，減小由於一致性校驗產生瓶頸的問題；

三、對寫數據進行基於時間的合理分片，過濾掉過時的失效請求；

四、對寫請求作限流保護，將超出系統承載能力的請求過濾掉；

五、對寫數據進行強一致性校驗只保留最後有效的數據。

 

 

 

限流方案：

    1.令牌桶限流：可以限制數據的平均傳輸速率外，還容許某種程度的突發傳輸，RateLimiter(側重於速率)  Semaphore(側重於線程個數)。

    2.漏捅算法：固定速率傳輸，資源沒法最優化處理。

    例如：RateLimiter limiter=RateLimiter.create( 5);