秒殺存在的問題：
1、短時間內大量請求發送到服務器，很可能會造成服務器崩潰；
2、商品超賣；
3、服務器響應時間過久（頻繁讀寫數據庫，耗時長），用戶體驗性差。
解決思路：
1、為解決頻繁讀數據庫問題以及減輕數據庫壓力，使用 Redis ，項目初始化時先將商品信息緩存起來，請求過來時先查Redis，根據商品庫存做進一步處理。
2、使用 Redis 解決超賣問題；
3、使用RabbitMQ 實現 流量削峰 和 異步調用，即當我們從 Redis 中知道庫存充足時即可給用戶返回success，然后將請求以消息的形式存入隊列，之后由消費者端進行 修改商品庫存和生成訂單操作；
具體的實現我就不在這里贅述了！！
項目的測試結果：
1秒發100次請求：
分析：
平均響應時間：42ms
QPS：91.1/sec 平均每秒可處理91次請求
疑問之處： 當1m 請求140次或200次時，QPS 就變得很低。
思考：
1、這樣的架構能很大程度提升系統處理高並發請求的能力，與此同時系統架構也會更復雜。
2、雖然 RabbitMQ 能很好的解決系統高耦合問題，但如果 RabbitMQ 掛掉也會讓系統崩掉。這時可以考慮一下 RabbitMQ 集群。
3、對 Redis 的數據頻繁寫會影響Redis的查詢性能。
我個人代碼：https://github.com/LvDonglin/GoodsSecKill/tree/master
https://download.csdn.net/download/rexueqingchun/12087061?utm_medium=distribute.pc_relevant_t0.none-task-download-OPENSEARCH-1.control&dist_request_id=24ae2e96-c0d6-42c7-bbb7-bf9074795d7e&depth_1-utm_source=distribute.pc_relevant_t0.none-task-download-OPENSEARCH-1.control
參考項目：https://gitee.com/gitee__wsq/seckill