[轉自](https://mp.weixin.qq.com/s/UwtsQLBgBMvDlC0SljHmeQ)
1.秒殺業務流程上的考慮 ：採用下單減庫存的方案，下單時扣減庫存，然後再進行支付。假如真有個別訂單不付款怎麼辦？沒關係，秒殺好活動最主要的目的是吸引流量，個別訂單不支付對秒殺活動本身影響不大。況且，沒支付剩下的庫存還可以做為普通商品繼續售賣。不過要注意對機器人和自動指令碼的防禦
2.秒殺頁面靜態化 放到CDN上預熱
3.請求攔截 前端頁面，相關按鈕點選後置灰，防止重複提交
閘道器（zuul，nginx）放行與庫存數量一致的請求數目
4.後端服務設計
建立訂單可以走非同步訊息佇列。後端服務接到下單請求，直接放進訊息佇列，監聽服務取出訊息後，先將訂單資訊寫入Redis，每隔100ms或者積攢100條訂單，批量寫入資料庫一次。前端頁面下單後定時向後端拉取訂單資訊，獲取到訂單資訊後跳轉到支付頁面。用這種**批量非同步寫入資料庫**的方式大幅減少了資料庫寫入頻次，從而明顯降低了訂單資料庫寫入壓力
5.隔離
6.網路 秒殺前要和網路運營商、CDN服務商提前申請頻寬

還有哪些細節要考慮

如何避免超賣？如果在redis中扣減庫存，可以利用decr命令扣減庫存，decr是原子操作，在分散式環境下也不會有併發問題，decr扣減庫存後，判斷返回值，如果返回值小於0，扣減庫存失敗，秒殺也就失敗了；如果在資料庫中扣減庫存可以在where後面加上庫存大於0的條件，來避免庫存被減成負值。這樣就可以避免超賣情況發生了。

介面防刷，前面已經提到過，在閘道器層對下單等介面按userID限流。

閘道器層除了對userID做限流外，還要做整體限流。在實際訪問量超過預估訪問量時，整體限流可以起到保護作用，避免系統被壓垮。

防止重複下單，按userID限流已經起到了防止重複下單的作用。假如限制同一個使用者10分鐘能下一次單，一般情況下10分鐘內，商品早已經被搶光了，使用者也就沒有再次下單的機會了。

可以結合風控系統，在閘道器層把羊毛黨等有問題的使用者請求直接拒掉。

可以在閘道器層上面再加一層防火牆或者高防服務，來防禦DDos等分散式網路攻擊。

本文來自部落格園，作者：up~up，轉載請註明原文連結：https://www.cnblogs.com/soft-engineer/p/14985842.html