一.前端層 1.將秒殺系統獨立部署，甚至`使用獨立域名，使其與網站完全隔離` 2.重新設計秒殺商品頁面，不使用網站原來的商品詳細頁面，`頁面內容靜態化，用戶請求不需要經過應用服務` 3.**動靜分離，將靜態資源放到第三方云服務中進行CDN加速，減輕秒殺時的帶寬壓力，比如阿里云、七牛云等等。** 實踐證明，CDN加速的效果十分明顯，對于一些響應不是很快的網站而言，靜態資源做了CDN加速后會變得很快，前后響應速度截然不同，是生產中必不可少的一種方式 4.（1）**產品層面**，用戶點擊“查詢”或者“購票”后，按鈕置灰，禁止用戶重復提交請求;（2）**JS層面**，限制用戶在x秒之內只能提交一次請求; 5.**使用驗證碼惡意防刷**如：秒殺專用驗證碼，電視公布驗證碼，秒殺答題 6.已超過秒殺商品總數，返回已結束頁面給用戶； 未超過秒殺商品總數，提交到子訂單系統； 7.臨時增加帶寬 二.站點層設計 訂單頁面 1）**`同一個uid，限制訪問頻度`**，做頁面緩存，x秒內到達站點層的請求，均返回同一頁面 （2）**`同一個item的查詢，例如手機車次`**，做頁面緩存，x秒內到達站點層的請求，均返回同一頁面 三.服務層設計 **`對于寫請求，做請求隊列，每次只透過有限的寫請求去數據層，如果均成功再放下一批，如果庫存不夠則隊列里的寫請求全部返回“已售完”`** **`對于讀請求，還用說么？cache來抗`**，不管是memcached還是redis，單機抗個每秒10w應該都是沒什么問題的； 四： 1.倒計時 出于性能原因這個一般由js調用客戶端本地時間，就有可能出現客戶端時鐘與服務器時鐘不一致，另外服務器之間也是有可能出現時鐘不一致 采用客戶端定時和服務器同步時間 2.**減庫存超賣** 用戶購買數量不做限制，需要判斷庫存是否足夠 1>嘗試扣減庫存，扣減庫存成功才會進行下單邏輯 2>采用樂觀鎖,數據庫自帶的行鎖機制