文章的思路主要**於：
解決方案（以下方案都是基於分布式的redis快取）：
1.用佇列解決大併發
建立一條佇列，將每個請求加入到佇列中，然後非同步獲取佇列資料進行處理，把多執行緒的事情變成單執行緒，處理完乙個就從佇列中刪除乙個。但是會出現乙個現象，請求特別多的時候，一瞬間將redis佇列記憶體撐爆，導致系統異常，又或者佇列記憶體足夠大，也是一種方案，但是，系統處理完乙個佇列內請求的速度根本無法和瘋狂湧入佇列中的數目相比。也就是說，佇列內的請求會越積累越多，最終web系統平均響應時候還是會大幅下降，系統還是陷入異常。
2.利用redis中基於cas的樂觀鎖
採用計數器的方式，用乙個集合，存放每個商品以及其對應的數量，如果只是單純的decr函式或者是incr函式，不能解決秒殺這種問題。因為有可能在併發的情況下，兩個請求取到的數都是0，然後都加1，結果為1，實際上應該是2。那麼這個時候建議利用樂觀鎖，實現自己的decr函式。
樂觀鎖的機制如同版本控制，如果修改的時候，要修改的value在redis中的值已經跟取出來時不一樣，則修改失敗。
def incr($key)
watch $key
$value=get $key
if not $value
$value=0
$value=$value+1
multi
set $key,$value
$result=exec
return result[0]
電商 如何防止商品超賣
怎麼導致超賣？多個使用者同時購買同一件商品 相同sku 產生高併發多執行緒。如果商品的個數僅有1個,a執行緒獲取到結果時因為剩餘數量大於0,生成訂單 使用者付款。此時若在a執行緒生成訂單的途中,b執行緒獲取的商品剩餘數量是大於0的，也會生成訂單 使用者付款。導致結果只有一件商品賣了兩次,超賣了。解決...
商品庫超賣的樂觀鎖
商品庫存的樂觀鎖實現。出現場景 避免商品出現超賣 即成功下單的訂單中商品的庫存數量大於商品現有的庫存量，則稱為商品超賣 的問題，核心技術是利用資料庫的事務鎖機制，即不允許同一商品的庫存記錄在同一時間被不同的兩個資料庫事務修改。功能實現 在前柔性事務介紹中所提到的，使用者在進行商品下單操作中，會進行一...
如何解決秒殺的效能問題和超賣的討論
最近業務試水電商，接了乙個秒殺的活。之前經常看到 的同行們討論秒殺，討論電商，這次終於輪到我們自己理論結合實際一次了。ps 進入正文前先說一點個人感受，之前看 的ppt感覺都懂了，等到自己出解決方案的時候發現還是有很多想不到的地方其實都沒懂，再次驗證了 細節是魔鬼 的理論。並且乙個人的能力有限，只有...