一分鐘了解”秒殺”系統
關於秒殺，第一反應都是實現起來比較複雜。難點在於：並發讀+並發寫+設計兜底方案的實現。
比如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碼等
更多交流，也歡迎您關注我的微信公眾號：
