系統設計

參考：

秒殺設計

• 一、什麼是流量削峯？如何解決秒殺業務的削峯場景
  
• 二、雙11秒殺系統如何設計？
  
• 三、電商網站秒殺與搶購的系統架構
  
• 四、高併發場景下秒殺系統的設計思路
  
• 五、電商「秒殺系統」設計思路和實現方法
  
• 六、秒殺系統架構分析與實戰
  

系統設計

1. 高併發解決方案
   
2. java服務器雪崩的場景與解決方案
   

秒殺系統的設計方案

1、常見的互聯網分層架構

（1）客戶端層：手機或PC端操做的客戶端頁面，域名經過DNS解析路由到Nginx

（2）反向代理層：通常經過Nginx做爲反向代理，將客戶端請求均衡路由到後端站點服務，Nginx 也能夠水平擴展爲多實例，且每一個實例可單獨部署爲主從的高可用方案。

（3）站點層：站點層可水平擴展爲多個實例部署，以此來均衡來自客戶端請求產生的高併發負載，多個web server之間的session信息可集中存儲於分佈式緩存服務（Redis，MemCache）中。

（4）服務層：服務層也可水平擴展爲多個實例部署，即時下最火的微服務方式

（5）數據庫層：數據庫層的常見部署方式，如讀寫分離，分庫分表等

2、秒殺架構設計思路：

（一）、前端設計方案

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

（二）、後端設計方案

• 服務端控制器層(網關層)
• 限制uid（UserID）訪問頻率：咱們上面攔截了瀏覽器訪問的請求，但針對某些惡意攻擊或其它插件，在服務端控制層須要針對同一個訪問uid，限制訪問頻率。
• 服務層

上面只攔截了一部分訪問請求，當秒殺的用戶量很大時，即便每一個用戶只有一個請求，到服務層的請求數量仍是很大。好比咱們有100W用戶同時搶100臺手機，服務層併發請求壓力至少爲100W。

1. 採用消息隊列緩存請求：既然服務層知道庫存只有100臺手機，那徹底沒有必要把100W個請求都傳遞到數據庫啊，那麼能夠先把這些請求都寫到消息隊列緩存一下，數據庫層訂閱消息減庫存，減庫存成功的請求返回秒殺成功，失敗的返回秒殺結束。
2. 利用緩存應對讀請求：好比雙11秒殺搶購，是典型的讀多寫少業務，大部分請求是查詢請求，因此能夠利用緩存分擔數據庫壓力。
3. 利用緩存應對寫請求：緩存也是能夠應對寫請求的，好比咱們就能夠把數據庫中的庫存數據轉移到Redis緩存中，全部減庫存操做都在Redis中進行，而後再經過後臺進程把Redis中的用戶秒殺請求同步到數據庫中。

（三）、數據庫層

數據庫層是最脆弱的一層，通常在應用設計時在上游就須要把請求攔截掉，數據庫層只承擔「能力範圍內」的訪問請求。因此，上面經過在服務層引入隊列和緩存，讓最底層的數據庫高枕無憂。