【今日話題】

電商專案的庫存設計，如何不賣超，取消訂單把庫存加回去，不能多加 - 沈括號

1. 這個說一個之前處理併發的經驗哈，情況應該是類似的，寫sql的時候多加一個條件，用update tbl set col = col - num where col ≥ num,這樣子吧 - 騎馬爬樹

2. 再加個定時任務去檢查使用者是否下單 沒有的話 update col=col+1 - sky

3. 這種庫存問題之前討論過吧，我碰到這種庫存或者併發問題都是用快取鎖解決的，屢試不爽 - lwPan

4. 事務加鎖。不會賣超，所以不存在加回去的情況。 - 周志

5. 資料庫鎖扛不住的 - tiyee

回: 可以結合佇列 - sky

6. 佇列加update tbl set col = col - num where col ≥ num，已經一年多了，絕對沒問題 - null

7. cache + db 吧，最保險的 - 踏雪無痕

8. 這樣的問題主要還是看場景，不同量級的請求量需要不同的方案。量級小的資料庫加鎖，量級大的就是佇列

回: 上面的說法不太贊同，佇列、快取什麼的，是非常常見且價效比極高的優化手段，在不影響進度的前提下，能做到90分，為什麼要拿60分來要求自己；萬一有一天產品火了，這時候才吭哧吭哧的改和重構，自己累不說，還影響產品；一開始設計的全面一些，後續能更好的支撐業務發展，節省業務發展的時間成本和伺服器上的資金成本 - 廖強

9. 其實控制庫存扣取返回不超賣不是很大問題，問題在於經過多個系統互動後，庫存一致性就出問題了 - 泉-June

10. 只要有transcation log 都不怕啊

每個replication一直apply transcation log就好了 - Ragnarok

11. 如果返回多了，就會超賣

關鍵是有方案控制庫存的整個流向保持一致 - 泉-June

回: 處理到賣完的時候 就每次返回失敗就好啦？

嗯 這個只要用分散式的檔案系統就好了把。。 - 亞楠哥

回: 那要看是下單扣還是加購物車扣 - 泉-June

回: 加購物車可以分為幾個transcation Lock(1) ... Buy(1) ... 之類的 只要保證資料流向正確就好了 - 亞楠哥

12. 電商不是那麼簡單的，前端平臺也不是一家兩家，比如天貓京東唯品會等等，每個平臺店鋪對應的倉庫其實都是一個，平臺和電商系統之間的延時要考慮，還有的平臺，比如貝貝，付款半小時後訂單才能同步到商家，這個庫存同步就有半小時時差 - 徐剛

回: 這個存量應該有一個大概的估計。。。感覺後面檢查庫存的時候才能正式確定訂單 - 亞楠哥

13. 我認為，如果有不同平臺的銷售，那倉庫資料就應該分倉，再過段時間調整一下，賣得慢的倉庫劃撥賣得快的倉庫，同時更新到銷售平臺。銷售平臺庫存與倉庫資料一致，就不怕超賣了。 - 李三 ??

14. 加購物車、確認頁都會檢查庫存，最後提交訂單時實際減扣庫存。所以運氣不好的話會遇到能新增購物車，但是提交訂單失敗的情況。提交訂單是事物操作，如果失敗就庫存回滾；訂單取消的話庫存也會回退 - rao

15. 分倉會影響銷售，有的平臺賣的好，沒貨了，有的平臺的倉還有貨，賣不動

一般是給各個平臺一個比例，平時比例和可以超一點，畢竟各平臺銷售情況不一樣，庫存報警的貨比例和調小一點，個別平臺遇到促銷活動，提前鎖定一部分貨 - 徐剛

回: @徐剛 所以我才說過段時間調整，劃撥倉庫。又不是分完就不動了。

先按預估各平臺銷售情況來分配，然後再及時按實際情況調整。 - 李三 ??

回: 分倉對物流人員來講，也是問題，多分一個就增加一倍工作量 - 徐剛

回: 邏輯分倉，不是物理分倉。

除非你各平臺的物理倉庫也是分開好遠的，那如果要先調撥就麻煩了。 - 李三 ??

回: 那和分比例沒區別 - 徐剛

回: 是沒什麼區別，但是不能因為比例高就可以超一點吧，萬一其它平臺也賣完了，你就沒貨了。所以還是嚴格按存量來賣。再根據庫存報警來及時調整。 - 李三 ??

回: 看貨品和個別平臺活動情況了，平時基本都是超比例分配，加活動期鎖倉，實踐經驗，供參考 - 徐剛

16. redis inc - a斌

17. 在網速特別慢的時候，多次重新整理會有機率觸發同訂單多次減庫存，取消訂單時將庫存加回去也會一樣，如何保證庫存增加減少時同一個訂單隻成功一次？ - 沈括號

回: 我之前做過的經驗是: 在第一次進入頁面生成一個唯一的token。表單提交的時候帶上，校驗下這個token是否已經完成，完成了就忽視，沒完成就插表或者其他操作。 - 如末

18. 在快取裡面設一個標誌位，每個訂單號存一個，setnx成功才執行db的加減操作 - 騎馬爬樹

19. 電商的設計得不超賣還是很好做的吧，下訂單的時候開啟事務，庫存減少時只需where條件中校驗一下，建立訂單；訂單超時或者取消訂單的時候，再開啟事務，更新訂單狀態，將庫存再加回去即可。下訂單或者取消訂單的時候，同一個訂單號根據訂單的狀態進行處理即可

前面說在快取裡面設定標誌位的方法不太好，如果標誌位設定成功，但是db執行加減操作失敗，會有問題 - 廖強

回: 高併發的情況下，where檢查如果主從不同步及時獲知主從延時過慢，還是容易導致問題，如果直接where主庫，也容易帶來寫入效能問題，靠事務比較妥當，但是效能也是問題，使用redis設定事務鎖來替代MySQL的事務鎖會好些。但是如果redis不可靠，那也容易出現問題，所以我們這邊redis作為重要的邏輯使用，會雙寫2個redis，只讀一個redis，一個redis壞了，直接切到另一個redis - carlsonlin

回: Update中帶where條件，不是直接select - 廖強

回: update是最恐怖的，一個update的完成得先read再write。比select還多一步。

當然了，如果不是高併發場景，一些都是浮雲啊，把所有邏輯都扔資料庫裡面完成就行了，開發超快 - carlsonlin

回: 還更恐怖....,mysql更新前都是要拿到資料再更新。有沒有where的區別不大，前提是已經主鍵更新了

另外，依靠redis 做mysql 的事務鎖，acid很難保證，除非用mysql 的xa - 廖強

回: update前MySQL需要定址更新節點，還是會涉及到磁碟定址的，其實和select差不多的道理，找到之後，才寫入。所以說還是蠻恐怖的。

acid只能靠程式+redis了，儘量做好程序掛掉的回退方法，不管是cgi還是redis還是其他原因

http://www.cnblogs.com/wenxiong/p/3954174.html

這篇文章大家可以看看，關於redis做分散式鎖的 - carlsonlin

回: 你需要再瞭解一下mysql，首先，mysql的update本身就會從磁碟去拿資料，和那個where條件沒有關係；其次，innodb buffer本身就把很多資料裝進了記憶體，很多時候除了事務提交以及刷髒頁以外不設計io

你說的那個文章是非常簡單的分散式鎖，建議你讀一下mysql事務的相關文章。舉個例子，一個事務中涉及2個sql語句，第一個sql語句執行成功後，第二個sql語句執行失敗，第一個sql語句需要回滾，這不是redis鎖能解決的 - 廖強

回: 好吧，我承認我對MySQL瞭解不深入，但有一些問題。1、update不需要查資料麼？不然咋知道update哪個點？如果查資料不靠update的where來檢索咋檢索的？2、redis分散式鎖不能涵蓋所有場合啊，肯定不能取代DB的事務啊，比如你說的幾條sql包括roll back。。 - carlsonlin

回: 嗯，你說的1這個問題，可能我們溝通理解不一致。我前面說那個更新的時候，是說在主鍵更新的基礎上加上一個and 庫存>=訂單中的資料，這麼一個限制條件。

用來確保不會超賣的

2. 在電商訂單和庫存的設計中，redis鎖幾乎沒有作用

redis還是不錯的，也不要太過否定

我們用得很多啊，feed和社交關係鏈都是用的redis

要會運維，redis還是有一定成本和門檻的 - 廖強

回: 首先，redis 不是個好東西，第二，redis 不適合做這個

用多了你就知道坑了

是 redis 自身的問題。通過運維修修補補不靠譜。不如直接用靠譜的東西

redis 只適合做單機臨時儲存 - 塔克斯

回: 我可以用redis鎖來保證一個最大粒度的操作啊，包括涵蓋的多個sql。比如這麼個場景。1、使用者因為網路問題或者伺服器延遲導致多點了兩下，重複下單，每個下單的操作（特別是股票，下單前的N多查詢和計算，最後才能寫入）。如果redis的事務鎖在前期生成就能擋住這部分的下單操作的前期工程，省了不少事情。。2、還有更多的場合、、

我覺得還是看場景吧，redis我們這邊用在很多過億的訪問場景 - carlsonlin

回: 第一個問題，為什麼要用鎖呢，你快取裡面放一個標誌位就搞定了

redis不止單機的cache，很多場景下都有用，我們目前有不少redis伺服器

那隻能說我們對鎖的理解不一致，前面他的需求是去重的功能 - 廖強

回: 鎖本來就是一個標誌位 - 塔克斯

回: 是啊，如果站在各自的場合就可能不太一樣了

反正解決問題的方法很多 - carlsonlin

回: 鎖的原語是lock和unlock，跟是不是標誌位什麼的，可能關係不大 - 廖強

回: 我的場合裡面就需要lock和unlock，這裡的標誌位具體是啥意思？ - carlsonlin

回: 標誌位是他自己實現了一個鎖。。。 然後他還不認為那是鎖。。。 - 塔克斯

20. 看你是常規銷售還是秒殺

合理一些的話，可以採用佇列的方式，來接受增減，確保資料一致 - 喬楚

21. 秒殺可以用快取，每臺前端機儲存屬於自己產品的數量，把100份產品分別分擔到十臺機器。前端也用快取，把部分使用者請求請求到失效的伺服器（黑洞）或者在lvs時丟棄請求或返回正在搶購（未搶到）

小米的預約不就是這麼幹的麼？我猜…預約完了就知道自己能不能搶到??如果來搶

還能光明正大的過濾掉未預約使用者

最後秒殺變成取獎步驟，光讀redis就能抗住

??不這麼做，怎麼抗住請求，誰讓中國人那麼多，何況還有機器刷 - Moses