一分鐘瞭解"秒殺"系統

關於秒殺，第一反應都是實現起來比較複雜。難點在於：併發讀+併發寫+設計兜底方案的實現。

 

好比QQ，雖然數據量很大，可是多數的數據都是細粒度的數據查詢，鎖衝突比較少；但12306涉及到大量的讀寫操做，對可用性，高性能，數據一致都有要求。

 

在開始前，先說一些基本概念，一般互聯網的應用包含了：

nginx代理層

tomcat站點層

rpc service服務層

數據層（cache和db）

方向上，下降數據層鎖衝突，具體兩大要點：

• 緩存降讀

• 下降寫的頻率，將請求攔截在系統上游

因此，優化的方向，也是從上面幾層展開。

 

一：優化方案：

 

1：端上的請求攔截（瀏覽器/app）

好比經過答題延長請求發出時間

js作一些基本性的校驗等

 

2：站點層的請求攔截

同一個uid xxS內才能夠請求，好比計數和限速

這裏能夠看到，站點層可能承擔了大部分的流量和壓力，因此站點層須要設計成無狀態服務，經過水平擴展的方式，分擔壓力；

可是站點層如何限速呢？

• 若是使用redis，那麼redis須要作proxy切分

• 固然，也能夠經過nginx七層路由，相同的id落地到相同的tomcat站點上，作內存計數

   

3：服務層的請求攔截

流量削峯，好比根據你的數據庫抗壓能力，計算出tps，或者經過業務庫存計算等

流量削峯解決了什麼問題：

• 服務端處理變得更加平穩

• 節省服務器的資源成本

 

如何削峯：

• 排隊：經過消息隊列來緩衝瞬時流量

4：數據庫處理

分庫分表，熱點數據隔離，讀寫分離等等

 

二：12306產品方案：

• 對於秒殺系統來講，下單與支付能夠分離，因此支付系統基本上能夠不用特殊處理

• 不一樣的地域分時售票等

 

三：兜底方案

1：降級

好比當秒殺流量達到5W/s時，把一些可有可無的查詢記錄從以前的100條，下降爲10條，這個能夠直接由參數來控制

2：拒絕服務

當系統達到必定的閾值時，設置過載保護，好比在nginx層上作限制，直接返回503 code碼等

 

更多交流，也歡迎您關注個人微信公衆號：