電商秒殺系統可能遇到的坑及思路

電商秒殺系統設計：
秒殺系統分爲2個部分，一個是靜態的HTML等內容，另外一個參與秒殺的Web後臺請求接口。
靜態HTML等內容，直接上cdn，壓力通常不會大，瓶頸基本在後臺請求接口上，必須可以支持高併發請求。

高併發下的數據安全問題：
假設只剩下一件商品狀況，高併發請求致使多讓一我的得到了商品。

1.悲觀鎖
在修改數據的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。

在「高併發」場景下，會不少的修改請求，每一個請求都須要等待「鎖」，某些線程可能永遠都沒有機會搶到這個「鎖」，請求就會死在那裏。
這種請求會不少，瞬間增大系統的平均響應時間，容易使可用鏈接數被耗盡，系統陷入異常。

2.FIFO隊列
直接將請求放入隊列中的，採用FIFO（先進先出），這樣就不會致使某些請求永遠獲取不到鎖。
可是高併發場景下請求不少，可能一瞬間將隊列內存「撐爆」，而後系統又陷入到了異常狀態。囧

那麼就得設計一個極大的內存隊列。
可是，隊列請求的速度根本沒法和瘋狂涌入隊列中的數目相比。隊列內的請求越積累越多，最終Web系統平均響應時候仍是會大幅降低，系統仍是陷入異常。囧

3.樂觀鎖
全部請求都有資格去修改數據，但會得到一個該數據的版本號，只有版本號符合的才能更新成功，其餘的返回搶購失敗。
這樣的話，就不須要考慮隊列的問題。我的建議這個方案。
缺點：它、會增大CPU的計算開銷。

做弊的手段：進攻與防守

1.同一個帳號，一次性發出多個請求
應對方案：
在程序入口處，一個帳號只容許接受1個請求，其餘請求過濾。
同一個uid，限制訪問頻度，作頁面緩存，x秒內到達站點層的請求，均返回同一結果。

2.多個帳號，一次性發送多個請求
應對方案：
(1).彈出驗證碼，分辨出真實用戶。
(2).直接禁止IP，簡單粗暴實用,可能會有「誤傷「。

3.多個帳號，不一樣IP發送不一樣請求
經過木馬黑掉普通用戶的電腦，不影響電腦正常運行，只是轉發IP包，普通用戶電腦被變成了IP代理出口。這種作法，黑客就拿到了大量的獨立IP，而後搭建爲隨機IP服務，就是爲了掙錢。

應對方案：
和真實用戶的行爲，已經基本相同，只能設置業務門檻過濾。

前端層設計1.瀏覽器層請求攔截用戶點擊「搶購「後，按鈕置灰。2.JS限制用戶在x秒以內只能提交一次請求。