前端
1，在瀏覽器端肯定要防止用戶重複點擊，而且不能使用靜態URL，防止內部作弊；
2，一般都是簡單網頁，商品介紹啥的放在其他常規頁面，讓客戶提前瞭解即可，專門的秒殺頁面用cdn緩存起來；
3，轉到機房的NGINX上時，NGINX做出限流配置，例如總併發數肯定不能超過秒殺商品的總數太多；
消息隊列
1，NGINX過後就到了後端了，第一個就是要查詢庫存，沒有庫存了，後續操作沒有意義；
2，有庫存之後要加入MQ消息隊列，把流量高峯削掉；
3，後端微服務從MQ中消費消息；
服務端
方案一，服務端收到請求後，生成訂單，訂單支付，支付完成後更新庫存（redis）
方案二，生成訂單之後就減庫存，在規定的時間內完成支付，沒有完成則取消訂單，庫存增加。
這個可以和放開秒殺的時候分時間段結合起來，例如每5分鐘放10w進來。
數據庫
1，傳統RDBMS，到數據庫這一層應該是不能存在問題了，否則系統肯定就宕機了。
2，新思路：
能否把用戶，商品，訂單狀態，支付狀態，庫存狀態都存在redis中？
key value
用戶id：商品id爲key
幾個狀態爲value，完成的標記爲1，未完成的標記爲0
例如：zhang:iphone11 ->1 0 0
客戶zhang秒殺的iPhone 11完成訂單生成，未支付，庫存未減
這樣完成一輪秒殺後，我們統計狀態不需要再查數據庫，直接在redis中完成，性能應該能提升。
總結：
高併發，秒殺把握的原則只有一條：一層層的過濾掉無效請求就是性能！！！
