本專案的超賣類似於電商的秒殺超賣現象
1.不同使用者在讀請求的時候，發現商品庫存足夠，然後同時發起請求，進行秒殺操作，減庫存，導致庫存減為負數。
2.同乙個使用者在有庫存的時候，連續發出多個請求，兩個請求同時存在，於是生成多個訂單。
對於第一種超賣現象;
(1)最簡單的方法，更新資料庫減庫存的時候，進行庫存限制條件，
update miaosha_goods set stock_count = stock_count - 1 where goods_id = # and stock_count >0可以簡單的解決超賣的情況
但是不能完全避免；
（2）究其深層原因，是因為資料庫底層的寫操作和讀操作可以同時進行，雖然寫操作預設帶有隱式鎖（即對同一資料不能同時進行寫操作）但是讀操作預設是不帶鎖的，所以當使用者1去修改庫存的時候，使用者2依然可以都到庫存為1，所以出現了超賣現象。
解決方案：
可以對讀操作加上顯式鎖（即在select ...語句最後加上for update）這樣一來使用者1在進行讀操作時使用者2就需要排隊等待了
但是問題來了，如果該商品很熱門併發量很高那麼效率就會大大的下降，怎麼解決？
解決方案：
我們可以有條件有選擇的在讀操作上加鎖，比如可以對庫存做乙個判斷，當庫存小於乙個量時開始加鎖，讓購買者排隊，這樣一來就解決了超賣現象。
（3）應用乙個佇列快取，將多執行緒變為單執行緒讀寫。
2.第二種現象，將userid和商品id 加上唯一索引，可以解決這種情況。插入失敗。
超賣現象之解決方案
行級鎖定是目前各大資料庫管理軟體所實現的鎖定顆粒度最小的,所以發生鎖定資源爭用的概率也最小，能夠給予應用程式盡可能大的併發處理能力而提高一些需要高併發應用系統的整體效能。但是由於鎖定資源的顆粒度很小，所以每次獲取鎖和釋放鎖消耗的資源也更多，帶來的消耗自然也就更大了。此外，行級鎖定也最容易發生死鎖。1...
電商超賣現象的解決思路
在進行電商平台開發的時候，我們必定需要考慮到商品的超賣現象或者是秒殺模組功能的實現，因此不得不考慮到高併發所帶來的問題，綜合網上的各類部落格文章，我對商品超賣這樣的問題處理進行了從淺到深的逐步分析。秒殺和搶購功能類似 我們先從原先的方法來談論可能會出現什麼問題？原始方法就是直接查詢請求是否符合庫存數...
電商超賣現象的解決思路
在進行電商平台開發的時候，我們必定需要考慮到商品的超賣現象或者是秒殺模組功能的實現，因此不得不考慮到高併發所帶來的問題，綜合網上的各類部落格文章，我對商品超賣這樣的問題處理進行了從淺到深的逐步分析。秒殺和搶購功能類似 我們先從原先的方法來談論可能會出現什麼問題？原始方法就是直接查詢請求是否符合庫存數...