購物車下單不是一個簡單的添加商品然後下單的功能，這背後涉及的內容非常複雜複雜，它與會員系統、商品系統、庫存系統、訂單系統等緊密結合，設計購物車下單功能時要考慮到與其他系統產生的關聯關係，尤其是訂單系統、庫存系統。在電子商務系統中，訂單處理時，優先要考慮的核心的環節就是庫存設計，然後圍繞庫存展開一系列的業務邏輯。那如何減去庫存，該在何時減庫存就成了首要問題，目前普遍採用的有以下幾種方案。
常見扣減庫存的幾種方式分析
1、放進購物減去庫存： “添加進購物車減庫存”實際上是“拍下減庫存”的衍生出來的新方式，本質上依然是拍下減庫存，特點是 將減庫存鎖定時間縮短，加快了流動速度。唯品會這類特賣網站，一個特賣活動很可能只有3小時，如果還按照淘寶的做法“拍 下後減庫存，72小時內不成交，系統才自動關閉交易”，顯然不可取，因爲整個特賣活動可能也就3小時呀。
特賣的時候大量消費者同一時間湧入，如果消費者拍下後，給很長的思考時間是否購買，特賣根本沒法玩，所以得給拍下減 庫存增加更敏感的時間限制。
2、下單減庫存：通常採用的都是下單減庫存，即當買家提交訂單後，在商品的總庫存中減去買家購買數量。下單減庫存是最簡單的、最常用的方式的減庫存方式，也是控制最精確、最符合常規邏輯的，下單時可以通過數據庫的事務機保證庫存的一致性、完整性和正確性嚴格制控制商品庫存，這樣基本可以保證一定不會出現超賣的情況。但這樣做也有個問題，你要知道有些人下完單可能並不會付款，有些是無意的有些是惡意的，還有些就是想先下單，過一會再買，這“一會”可能是一個小時或幾個小時、半天、好幾天，還有可能不買了。
拍下減庫存的方案無法規避商品惡意被拍的風險。如果商家的商品大量被拍下，但用戶一直不付款，就會導致其他真正想買的用戶因庫存不足而無法下單購買。等到未付款訂單到過期時間系統自動取消時，可能會因大量庫存被佔用而一件商品也沒有賣出去。這種事情曾經淘寶真的發生過，前幾年淘寶中小商家大鬧天貓，狂刷韓都衣舍等大店就是出現了這種的情況，中小商家們瘋狂拍下商品，造成韓都衣舍大量商品庫存爲零被迫下架，導致大量需要正常消費者無法購買。
3、 付款成功後減庫存：即買家下單後，並不立即減庫存，而是等到有用戶付款後才真正減庫存，否則庫存不減，視爲未購買。就算庫存只有一個，其他用戶仍然可以繼續下單，此方案只將付款訂單視爲真正的商品訂單。但高併發時可能會出現超賣的情況，因爲付款時才減庫存，併發下單查的時候都是庫存充足，儘管三個人買一個庫存爲1的商品，待三個人都付款成功庫存會變爲-2，這種超賣情況在促銷活動的時候最容易出現。
付款之後減庫存，很容易付完錢後，庫存不足，因爲這個付款的過程可能比較慢，因爲要輸入密碼，調第三方支付之類的。就算發現庫存不足後用事務回滾，也行不通：此時買家已經付款了，那麼立刻在買家剛剛付過來的錢再退回去嗎？這顯然是無意義、不可行的。
還有一種情況，就是出現買家下了單卻付不了款，因爲可能商品已經被其他先付款的人買走了。付款後再減庫存這種機制，如果在用戶點擊支付後，在調起支付之前先去查一下庫存，其實也能在很大多數時候上避免超賣的現像，但就怕超高的併發。
4、預扣庫存，這種方式相對複雜一些，買家下單後，庫存爲其保留一定的時間（如 10 分鐘），超過這個時間，庫存將會自 動釋放，釋放後其他買家就可以繼續購買。在買家付款前，系統會校驗該訂單的庫存是否還有保留：如果沒有保留，則再次嘗 試 預扣；如果庫存不足（也就是預扣失敗）則不允許繼續付款；如果預扣成功，則完成付款並實際地減去庫存。
關於未支付訂單實效時間和
綜合以上來看，第二種下單後扣庫存是幾個方式中最可行辦法之一，只不過我們做一些改進、配合一些機制來解決庫存被有意、無意、佔用的問題，例如我們可以配合第四種預扣庫存的機制。
在用戶下單後的若干分鐘內如果不進行系統就自動取消用戶的訂單，釋放庫存。具體多少分鐘這個值可以根據自己實際業務來定。如果未付款訂單失效時間太長無法解決庫存佔用問題，未付款訂單失效時間太短會讓用戶惱火，降低轉化率，用戶原意本來想購買的只是晚了一些訂單就被取消了。
關於訂單失效時間這個，我參考了目前最火的三大電商平臺的做法：
- 京東：一般訂單都是需要在24小時內支付，否則訂單自動取消；搶購活動要在2小時內支付，充值需要在12小時內支付。
- 拼多多：提交訂單後24小時未支付自動取消。
- 淘寶：未支付訂單保存三天的，三天還爲支付自動取消，同時商家可以手動取消未付款訂單來釋放庫存，不過這裏有小地方需要注意：淘寶商家是可以在後臺設置【付款後減庫存】or 【下單後減庫存】。淘寶普通商品的支付時長是最久的將近3天，平臺大，用戶量和商家比較多，商品豐富，貨比三家，用戶可能猶豫時間比較久。
2016年11月，淘寶增加了商品減庫存的方式，商家可以自主選擇拍下減庫存和付款減庫存兩種方案。
淘寶網一直採用拍下減庫存的方式，即用戶下單後，商品的線上顯示的庫存就會減少。但這種方式存在一系列弊端，給買賣雙方帶來了一定程度的不便。由於用戶下單後有72小時的付款時間，在這段時間可能會由於一些原因導致交易取消，這時顯示庫存的減少會影響其他用戶的購買，尤其是一些定量產品。而且採用拍下減庫存的方案無法規避商品惡意被拍的風險。如果商家的商品大量被拍下，但一直未付款，造成其他用戶無法購買，就會給商家造成經營上的損失。
爲解決和規避存在的問題，淘寶網增加了付款減庫這一方案。付款減庫存即買家提交訂單付款以後，商家商品顯示的庫存數量纔會相應減少。但選擇付款減庫存也存在一定風險：如果選擇付款減庫存的方式，在商品促銷或者有買家同時購買時會出現超賣情況。淘寶網表示，超賣的訂單需和用戶協商好補貨或者退款，如果因超賣問題用戶發起投訴，建議買賣雙方自行協商處理，投訴做完結處理。
我們可以設計的靈活一點，在庫存緊張的時候把未付款訂單失效時間縮短，在庫存充足的時候把未付款訂單失效時間延長長， 以彈性的機制來緩解商品庫存問題，還可以對未付款的訂單進行庫存緊張支付提醒：
1）用戶未在線：
提醒時間：一出現庫存緊張就提醒
提醒文案:"庫存告急，請及時支付“（具體運營優化）
提醒方式：短信和消息推送
2）普在用戶在線的情況時以每分
提醒時間 ：30分鐘，60分鐘兩個時間段 （後期有用戶行爲數據在具體分析提醒時間的策略）
提醒文案：還有xx分鐘，交易即將關閉，請及時支付 （具體文案運營優化）
那用下單減庫存+未付款訂單在若干小時、指定時間內失效的方法，如何應對在庫存緊張的情況下併發下單這樣的應用場景呢，倘若10個人同時下單購買一個庫存只有3個的商品，程序該如何設計？
下單減庫存”在數據一致性上，主要就是保證大併發請求時庫存數據不能爲負數，也就是要保證數據庫中的庫存字段值不能爲負數，一般我們有多種解決方案：一種是在應用程序中通過事務來判斷，即保證減後庫存不能爲負數，否則就回滾；另一種辦法是直接設置數據庫的字段數據爲無符號整數，這樣減後庫存字段值小於零時會直接執行 SQL 語句來報錯；再有一種就是使用 CASE WHEN 判斷語句，例如這樣的 SQL 語句：
UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END
在交易環節中，“庫存”是個關鍵數據，也是個熱點數據，因爲交易的各個環節中都可能涉及對庫存的查詢，我們可以把庫存放在redis緩存中，因爲redis是非關係型內存數據庫，所以Redis的讀寫能力遠勝於任何關係型數據庫，因此在Redis中保存商品庫存數據並完成扣減操作。
還有就是用隊列來處理併發下單。
還有一個經常遇見的應用場景：如果有一個商品被很多人下單卻未付款，佔着庫存，此時庫存很十分的低又有大量的用戶湧進來要購買，而佔着庫存的那一批人他們的訂單又未達到系統設定的失效時間，那該怎麼辦？
此時就真正遇到了上面提到的庫存佔用問題，我們可以應用以下幾種方案，或則結合來用：
庫存量低時，大幅度縮短未付款訂單有效時間，及時地時間及時釋放庫存，商家也可以手動取消很長時間未付款的用戶訂單，把庫存讓給急等着購買的用戶。
應用虛擬庫存概念，將超過n分鐘未付款的訂單爲視爲潛在庫存，在其他用戶下單時直接剝奪超過n分鐘未付款的訂單庫存，當然，如果其他用戶下單也長時間未付款的話，同樣會被列爲“潛在庫存”的行列。這就需要我們每次都在訂單列表查一下庫存，如果之後庫存補上了，他的訂單會被自然的爲正常訂單，可正常付款，訂單上一切東西不變。
虛擬庫存的概念看上去和付款後減庫存有點像，實際上和付款後減庫存這種方式相差甚遠 ，它結合了下單減去庫存的方案和預扣庫存 又配合他的一些調度策略和超限機制來完成業務需要，同時保證庫存數據的一致性和正確性。又加入了許多條件，達到既定的某些條件才能觸發這個應急機制。
只有達到條件纔會啓用，在庫存緊缺而購買這個商品的人數非常多的時候、且下單後超過N分鐘未付款纔會觸發這個機制，主要是看購買和人數和商品庫存的比例。且如果庫存補上後，會自動棄用這套機制，走正常流程。
虛擬庫存比付款後減庫存要更加複雜、智能與靈活，實現了隨機應變，它它結合了下單減去庫存的方案和預扣庫存 又配合他的一些調度策略和超限機制來完成業務需要，程序根據當前的場景變化自動調整減庫存機制、切換應對策略，使程序更具前瞻性和預見性，其實就是我們爲設想到的極限應用場景預留了一套備用扣庫存機制。簡單的說就是在特殊情況下把某些超過一定時間未付款的訂單轉爲庫存，或者說視爲庫存
虛擬庫存在電商領域的應用(延伸閱讀)
虛擬庫存 > 實際庫存：賣家做促銷活動時，面向消費者顯示的庫存實際上並不存在，或數量上遠大於賣家的庫存。賣家可以集中超額部分的訂單向供應商要貨，向供應商議價，能做到先賣貨再進貨，降低成本。同時集中運輸，降低物流成本。
虛擬庫存 < 實際實庫：買家易生搶購心理，促進買家下單。在某品類的商品中，虛擬庫存也爲賣家提供漲價的機會，如茅臺、紅酒。某些酒品類商品會隨時間的推移而漲價，能提高利潤。虛擬庫存是用來賣貨的，實際庫存是用來盤貨的。
在實際應用中， 淘寶的某些店鋪也是這麼做的，我們經常會遇到拍下某個商品後沒付款，第二天去付款的時候訂單變灰色，提示庫存不足，等過幾天你再去看的時候你又可以發起罰款了，因爲庫存補上來了。還有就是即使你付了款，商家依然沒貨依然沒關係，因爲有一個承諾發貨時間，商家可以利用這幾天來調貨、補貨。
其實在電商領域還有另一種虛擬庫存的概念，電商賣家行業一般稱爲“搬貨”，指的通過電商oa軟件把別人店鋪的商品上到自己店鋪，價格標的比原價高一點，當有人下單時再去原商品店鋪去下單，也就是上家，這就是傳說中的無貨源模式。
當然上面有點扯遠了，這篇文章主要探討了極端環境下如何保證庫存數據的一致性和完整性、正確性，解決問題的思路和解決問題思維至關重要，它會引領你找到任何問題的解決方案。