秒殺系統的設計,你值得擁有

常見的解決方案：

1.将秒殺系統獨立部署，甚至使用獨立域名，使其與網站完全隔離。實體業務隔離

2. 重新設計秒殺商品頁面，不使用網站原來的商品詳細頁面，頁面内容靜态化， 使用者請求不需要經過應用服務   3. 因為秒殺新增的網絡帶寬，必須和營運商重新購買或者租借。為了減輕網站服 務器的壓力，需要将秒殺商品頁面緩存在 CDN ，同樣需要和 CDN 服務商臨時租借新增的出 口帶寬。  

秒殺架構原則

1.盡量将請求攔截在系統上遊，傳統秒殺系統之是以挂，請求都壓到了後端資料層，資料 讀寫鎖沖突嚴重，并發高響應慢，幾乎所有請求都逾時，流量雖大，下單成功的有效流量甚小

2.讀多寫少的場景多使用緩存這是一個典型的讀多寫少的應用場景

秒殺架構設計

1.秒殺系統為秒殺而設計，不同于一般的網購行為，參與秒殺活動的使用者更關心的是如何 能快速重新整理商品頁面，在秒殺開始的時候搶先進入下單頁面，而不是商品詳情，是以秒殺系統的頁面設計應盡可能簡單 2.下單表單也盡可能簡單，購買數量隻能是一個且不可以修改，送貨位址和付款方式都使用使用者預設設定，沒有預設也可以不填，允許等訂單送出後修改；隻有第一個送出的訂單發送給網站的訂單子系統，其       餘 使用者送出訂單後隻能看到秒殺結束頁面

秒殺前端設計

1.靜态資源存放到各 CDN 節點，把靜态資源緩存到各 CDN 節點，使用者可以就近訪 問，加快通路速度 2.使用者點選秒殺後，按鈕置灰 3.js 限制 x 秒内隻能送出一次  

秒殺站點設計

1.nginx 層做針對同一 ip 的通路頻率限流

2.同一查詢在站點層限制通路頻率

秒殺服務層設計

服務層核心設計思想，盡量把大量的請求不要瞬時落到資料庫層

1.讀請求，cache 來扛，memcached，redis 單機扛 10W+應該沒問題

2.寫請求，用隊列，由并行轉串行，每次隻放有限的寫請求去資料庫

高并發要吞吐量 or 系統保護

其實在正常非高并發的請求裡面，也有類似的問題存在，業務請求接口異常響應極慢，久 而久之就會把整個伺服器的可用連接配接數占滿了，然而越是這種情況，越是系統不可用使用者 點選越頻繁，這台伺服器有題，分流軟體把流量導到其他伺服器，導緻其他伺服器也崩 潰，将整個 web 系統拖垮，産生服務雪崩。   流量過大處理不過來的時候，就必須要有過載保護機制 例如秒殺場景，流量往往大到跟我們當初設計的不在一個量級，如果出現這種情況，可以 将流量攔截在站點層，比如在 nginx 層面就攔截掉，盡量不要把災難引到服務層。  

系統安全的矛和盾

1.同一賬号發送多次請求 這種加鎖就可以解決， redis 鎖，如果其中一個請求擷取鎖成功就允許秒殺，其他都拒絕   2.多個賬号發送多次請求 黃牛黨，僵屍号在秒殺開始的時候瘋狂請求 可以做 ip 限制，如果某個 ip 請求頻率過高，可以彈驗證碼或者實名驗證，其實就是判斷是否是活人。   3. 多個賬号，不同 ip 這種必須要做業務限制，提高秒殺的參與門檻，比如隻有星級使用者、賬号等級等等業務手段 來做限制。而僵屍賬号往往賬号等級和活躍度都不高