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

 

比如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碼等

 

更多交流，也歡迎您關注我的微信公眾號：

相關推薦