庫存控制的並發控制

Question

有很多與我的問題相關的類似問題。 但我沒有找到任何令人滿意的答案。 所以我把這個問題放在這個論壇上。

我對庫存管理系統中的並發控制有疑問。 假設我有數量為 2、3、4 的產品 A、B、C。 我的應用程序是多用戶的。

我有產品頁面，用戶可以在其中查看產品列表和可用數量。 我有結帳和付款頁面，在產品頁面之后可能需要一些時間才能到達。

現在，如果是多用戶 Web 應用程序，並且說用戶 1 訂購了 2 個數量的產品 A 但尚未下訂單，則用戶 2 仍然可以看到有 2 個數量的產品 A。

我是否應該暫時（可配置時間）鎖定 2 個數量的產品 A 直到下訂單？ 是不是很好的設計。 如果是，我應該鎖定 java 還是數據庫？

Answer 1

不，這不是一個好的設計，因為它容易導致濫用和問題。 如果用戶（競爭對手？）在整個月內鎖定了您的所有產品怎么辦？ 如果另一個人在他/她的購物車中裝滿了產品，然后認為這太貴了，然后關閉了他/她的設備怎么辦？

最好的選擇是：

1) 告訴用戶每種產品的可用性有多少，但也告訴他/她如果不盡快下訂單可能會消失。 這也應該激勵銷售。 在付款頁面之后鎖定/解鎖您的產品，即當有業務承諾進行操作時。 如果可用數量不再足夠，請向用戶返回上一頁，更新數量以使其可用。

2) 與 1) 類似，但您也可以不時更新可用性。 或者發送諸如“您購物車中某些商品的庫存不足”之類的警告。 同樣，這也可以促進銷售。

3) 在將物品移至購物車時保留（“鎖定”）物品，但不會永遠保留。 鎖定一定時間后釋放項目。 隨時通知用戶。 超時可以是整個購物車或每個項目。

需要注意的是，上面提到的任何“鎖”都是“業務鎖/保留”。 它不需要以鎖或任何其他特定技術解決方案的形式實現。 例如，上面的 3) 可以通過添加字段locked_by和locked_until來實現。 當您檢查/更新/操作這些字段時，您可能需要在“技術鎖”內進行。 完成檢查/更新后，將釋放技術鎖定。 但是，“業務鎖”可能仍然存在，因為locked_until尚未結束，任何其他代碼將檢查此字段以考慮產品是否可用。 為什么？ 因為業務規則如此要求（不是因為存在技術鎖定，實際上並非如此）。

“技術鎖”應該很快。 “業務鎖”可以更長（但永遠不會永遠；總是為它們定義時間限制）。

很難判斷是否應該使用您提供的很少信息將“在 Java 中”鎖定在“在數據庫中”。 例如，您是否在使用實體 Bean？ 您的容錯要求是什么？ 等等。

也就是說，在一般情況下，最好在數據庫中保留鎖（只要它們是“業務鎖”），主要有以下原因：

• 持久性（在電源故障的情況下）。 您還應該提供一種機制來恢復購物車。 也許也將它們存儲在數據庫中？
• 能夠與其他環境（即企業 ERP 或配送系統）交互。

Answer 2

我是否應該暫時（可配置時間）鎖定 2 個數量的產品 A 直到下訂單？ 是不是很好的設計。

這取決於您網站的對話率，即結帳次數/付款次數。 如果您的會話率很高，您可以預先鎖定數量以獲得更好的用戶體驗。

如果是，我應該鎖定 java 還是數據庫？

你需要一個全局鎖來保證正確性。 如果您有多個應用服務器，則必須將鎖放在數據庫中。

Answer 3

庫存管理應由從頭開始構建的自定義系統進行處理。 出於性能原因，您不能簡單地依賴 ACID 合規性。 在訂單期間實施庫存交易是一個非常糟糕的主意，而且不可擴展。 我提出以下解決方案。

1. 一個庫存管理后端應用程序，可在新項目進入時更新庫存。使用行鎖更新庫存。
2. 庫存管理微服務應用程序將庫存提供給訂單管理系統，因為它需要庫存來完成訂單並跟蹤超時。 一種。 如果訂單完成確認，給定的庫存已經被管理系統扣除。 我們很好。 灣如果訂單未完成且未收到確認，則在超時（通常為 2 - 3 分鍾）后將給定庫存添加回庫存系統。 C。 如果訂單失敗並且收到訂單失敗的確認，則將給定的庫存添加回庫存系統。

因此，在訂單完成之前您不會鎖定產品行。 相反，如果訂單因異常/應用程序故障而未成功或失敗，您可以對庫存和發布進行軟鎖定。