場景，秒殺活動，有商品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%