場景，秒殺活動，有商品A， 100個，價格0.01元，每人只能購買一個，在中午12:00開放購買，價格實惠，肯定好多人搶著購買。

這樣就涉及到并發，就是說查出庫存后到更新庫存的過程，會存在其它請求修改庫存的情況。

解決方法是在更新庫存的時候，加個條件庫存>0，如果執行sql返回影響的行數是0，就執行回滾，提示已售完。

sql如 update store_table set store_num = store_num - 1 where good_id = 111 and store_num > 0。

這里還有個要控制，一個人只能購買一個，可以加一個表，字段有user_id和good_id，設為唯一索引，在處理時判斷是否存在，存在就回滾，但判斷后另一個請求又有可能插入，那么本次插入就會報錯了，雖然不太友好，便起到控制效果。

?

（非原創）
1. 盡量將請求攔截在系統上游：
2. 讀多寫少，多使用緩存

? 瀏覽器和app：做限速，限制用戶在X秒之內只能提交一次請求（比如雖然你在瘋狂的搖微信，但其實x秒后才向后端發起一次請求）
? 站點層：按照uid做限速，做頁面緩存，這時用uid，一個uid5秒只準透過一個請求。這樣就能攔住99%的for循環請求。
? 服務層：按照業務做寫請求隊列控制流量（每個提供服務的服務器各一個隊列）（每次只透有限的寫請求去數據層，如下訂單，做支付這樣的寫業務）。3k張火車票，只透3k個下單去db
? 數據層：這時已經沒有多少壓力了。全部透到數據庫，100w個下單，0個成功，請求有效率是0%；透3k個請求到數據，全部成功，請求有效率100%

3萬個商品高并發下秒殺有什么方案實現超賣、少賣

轉載于:https://www.cnblogs.com/jimzbom/p/7610039.html

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的秒杀库存的简单控制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。