這篇文章原文是庫存扣多了，到底怎麼整 ，後面還有一篇對網友回覆的解答庫存扣減還有這麼多方案？
第一篇文章中著重描述了扣減庫存的併發問題如何解決，如何保證冪等。
文章首先解決的是如何做到冪等，因為「扣減」庫存一定是乙個非冪等的操作，那麼可以通過「設定」庫存來解決，因為設定庫存是乙個冪等操作。
第二個解決的是冪等之後的併發問題，因為「設定」庫存雖然做到了冪等但是並沒有解決併發時帶來的一致性問題，當兩個使用者同時「設定」庫存是會造成資料的不一致。
緊接著就引出了csa（「compare and set」），csa本質上就是一種樂觀鎖方式---先比較再設定。每次扣減庫存時都做比較，如果「當前庫存」總數和「原庫存」總數一致時才執行「扣減」，否則「扣減執行失敗」，那麼失敗後只有兩種辦法，要麼事務回滾，要麼自動重試，如果重試後發現扣減後總數小於0那麼就需要返回給使用者錯誤了。
這兩個思路非常的nice，分別解決了「冪等」和「一致」，但是沒有引出「高併發」這個話題，因為高併發下這種方法失敗的概率很大，會頻繁失敗給使用者不好的體驗。
後來很多網友就在後面引出了另外的一些觀點，例如redis，利用了redis的「快」，redis的快有幾個原因，第一是記憶體讀取，第二是非阻塞io，第三是單執行緒loop，避免了物理鎖，減少執行緒上下文切換時間，第四是hash結構儲存。因此雖然是單執行緒，但是redis帶來非常高效率的讀取，並且天然支援「高併發」，因為單執行緒操作不加任何鎖。但是redis的另外乙個風險就是資料儲存在記憶體中，有丟失的風險。因此，使用時還需結合業務場景來看。
第一篇文章後面還有網友提到了使用佇列來非同步「扣減」，這實際上就和redis單執行緒一樣了，這種方法思路挺好的，但是本菜鳥覺得會損失掉很多效能，是一種時間換空間的方案，可能會帶來使用者體驗問題。
著重要提到的是後面一篇文章有乙個答覆思路非常新穎，因為這個問題的併發點實際上就是「庫存」，所有的請求都在這個單點上操作，因此採用分布式的思路就是把這個「單點」均衡開，如果庫存總數是m，那麼將同乙個key下的庫存分成n組，k1...kn，每組的庫存數為m/n，扣減時可以將請求均分到k1到kn上，這樣就減少了衝突的機率，又是一種空間換時間的好方法！
最後本菜鳥想說的是，庫存扣減這個問題往深了說在每一層可能都有不同的解決方案，在應用場景中應該按照具體的場景來看，是多讀場景還是多寫場景，使用者的要求也不一定相同，因此業務場景決定了技術選型。這個話題還是非常值得**的，各種思路產生了火花，希望博主今後能多發些這種好文^_^
讀《架構漫談》系列有感
讀了這一系列博文，我對架構也有了大致的了解。在簡單的閱讀之後，我解決了幾個問題。第乙個問題，什麼是架構？要學習架構，首先要知道架構。那麼，什麼是架構呢？引用 架構漫談 一 裡的話就是把乙個整體切割成不同的部分，由不同的角色來完成這些分工，並通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為...
讀程式設計師網遊專題雲風的文章有感
1.勇於承認失敗 國內的遊戲廠商，讓人覺得能有大家風範的少之又少，炒作 隨意誇大遊戲品質，好象不吹牛就沒人知道他遊戲作得爛似的。由於網遊市場漸顯的各種風險增加，資本市場從2004年底開始，對網遊的投入漸趨理性化。在這樣乙個群雄逐鹿的時代，唯有靠品質才能最終取勝，小的遊戲廠商會逐漸被市場淘汰或邊緣化。...
讀程式設計師網遊專題雲風的文章有感
1.勇於承認失敗 國內的遊戲廠商，讓人覺得能有大家風範的少之又少，炒作 隨意誇大遊戲品質，好象不吹牛就沒人知道他遊戲作得爛似的。由於網遊市場漸顯的各種風險增加，資本市場從2004年底開始，對網遊的投入漸趨理性化。在這樣乙個群雄逐鹿的時代，唯有靠品質才能最終取勝，小的遊戲廠商會逐漸被市場淘汰或邊緣化。...