扣減庫存策略採用訂單是否鎖定庫存方案
在訂單系統中使用者下訂單流程中，有乙個重要環節是「扣減庫存」；而此「扣減庫存」採用的策略是直接在乙個商品庫存欄位中的庫存資料減去訂單商品數量;如：
update productstock set
quantity = quantity -1
where productid = 20034 and quantity >=1
此策略在高併發環境下會產生嚴重的效能問題。
所以本人就想換一種不爭用同一行同乙個欄位的資源來避免竟爭，以解決高併發帶來的效能問題。本人的思路是，先將使用者提交的訂單插入訂單表，然後獲取此商的品原始投入的庫存數，再取此產品已經被鎖定庫存的商品數量，將兩者的資料與新下訂單的商品數量比較，如果還可以再將此新訂單鎖定庫存則更新這個訂單的狀態以表示此訂單已經成功鎖定庫存。
sql 如下:
update [orderinfo]
set [isenabled] = 1
from [orderinfo] a
where a.orderid = 64434398158878 and a.productid = 324285 and [isenabled] = 0 and a.productqty <=(
select sum(qty) from (
select stockqty as qty from [productstock] where productid = 324285
union
select -sum( productqty ) as qty
from [orderinfo]
where productid = 324285 and [isenabled] = 1
) as p
這樣，更新資料的行為是更新每個訂單記錄的狀態，不存在資源的競爭問題，也將大大提高效能。
當然，這要求所有的訂單資料都在乙個表中，這個要求有點高；其實這個問題是可以解決的，在系統不忙時完全可以從這個訂單表中移走老的訂單到另外乙個表中，然後將這些訂單的商品數從商品庫存中扣減出來。有人會說這又回到老的方案中去了，我想說不然，這個處理完全是資料內部處理，完全不需要併發，也就不存在回到老的方案中的說法。
關於庫存扣減問題
昨天面試的時候，被面試官問到庫存扣減問題。估計面試官把我的專案當成秒殺了。怪我自己沒介紹清楚專案，自己挖坑。今天在部落格上看了一些關於庫存扣減問題，主要還是覺得比較合適的方式就是使用redis分布式鎖，這是最簡單的方案,但是如果事務過大,會有效能問題.操作不當,會有死鎖問題 如果兩個執行緒同時執行的...
使用UpdLock來扣減庫存
updlock.updlock 的優點是允許您讀取資料 不阻塞其它事務 並在以後更新資料，同時確保自從上次讀取資料後資料沒有被更改。當我們用updlock來讀取記錄時可以對取到的記錄加上更新鎖，從而加上鎖的記錄在其它的執行緒中是不能更改的只能等本執行緒的事務結束後才能更改，更改庫存 begin tr...
關於電商庫存扣減問題
b2c 庫存扣減方式 1 直接扣減實際庫存 直接採用實際庫存，每次客戶下單扣減實際庫存，容易導致庫存占用，對銷售和運營都不合理。a 如果購買使用者未付款，實際庫存導致庫存被扣減，讓有意願購買的使用者無從下單，對銷售業務有很大影響 b 未付款訂單給予30 40 鐘付款等待時間，未付款自動釋放虛擬銷售庫...