電商秒殺系統設計：
秒殺系統分為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秒之內只能提交一次請求。