有没有库存管理设计模式? [英] is there any stock management design pattern?

问题描述

我们想要设计一个电子商务应用程序，并且我们很关心持续库存的数量.我们不希望我们的客户在购买商品后发现该商品缺货，这是一件大事.这里的平均订单有大约 60 种不同的商品，这会让事情变得更加棘手.

We want to design an e-commerce application, and we are mental about consitent stock numbers. We don't want our customers finding out, after they have bought an item, that that item is out of stock, that's a big thing here. The average order here has about 60 different items, which will makes things even trickier.

让我们想象一下这两种情况:

Let's imagine these two scenarios:

第一种情况:

1) 客户 C​​1 打开网上商店并找到他/她想购买的产品；

1) Customer C1 opens the online store and find a product he/she wants to buy;

2) 该产品显示为有货"(但当前库存为 1)；

2) That product is shown as "in stock" (but the current stock is 1);

3) 客户 C​​1 将 1 件商品放入购物篮；

3) Customer C1 puts 1 item in the basket;

4) 客户C2进入网站并选择相同的商品(放入购物篮)，该商品仍标记为in stock"(库存仍为1)；

4) Customer C2 gets into the website and select the same item (put in the basket), which is still marked as "in stock" (stock is still 1);

5) 客户 C​​1 去结帐并确认他的购买，应用程序将该项目的当前库存减少到 0；

5) Customer C1 goes to checkout and confirms his purchase and the application decreases the current stock for that item to 0;

6) 客户 C​​2 一直在购买商品，比方说其他 35 种不同的商品(客户 c2 花了 20 分钟选择了他想要的商品)；

6) Customer C2 keeps buying items, let's say 35 other distinct items (it took 20 minutes to customer c2 to select the items he wanted);

7) 客户 C​​2 去结帐并确认购买，但现在，他购买的第一件商品不再可用(我们不能出售)；

7) Customer C2 goes to checkout and confirms this purchase, but now, the first item he bought is no longer available (and we CAN NOT sell it);

8) 应用程序警告客户 C2 第一个项目不再可用，他必须检查他的篮子；

8) The application warns customer C2 that the first item is no longer available and that he has to check his basket;

9) 客户 C​​2 生气了，没有买任何东西就关闭了浏览器.

9) Customer C2 gets pissed and close the browser without buying anything.

第二种情况(但我认为它不必要地复杂且有问题):

1) 客户 C​​1 打开网上商店并找到他/她想购买的产品；

1) Customer C1 opens the online store and find a product he/she wants to buy;

2) 该产品显示为有货"(但当前库存为 1)；

2) That product is shown as "in stock" (but the current stock is 1);

3) 客户 C​​1 将 1 件商品放入篮子中(应用程序将该商品的当前库存减少到 0)；

3) Customer C1 puts 1 item in the basket (and the application decreases the current stock for that item to 0);

4) 客户C2进入网站，看到他/她想要的商品缺货；

4) Customer C2 gets into the website and see the item he/she wanted is out of stock;

5) 客户 C​​2 离开网站；​​

5) Customer C2 leaves the website;

6) 客户 C​​1 不断购买商品(这些商品的库存减少)；

6) Customer C1 keeps buying items (the stock decreases for it of these items);

7) 客户 C​​1 关闭浏览器；

7) Customer C1 closes the browser;

8) 每隔一段时间就会启动一些批处理程序，以删除那些减少库存但没有被购买/确认的项目.

8) Every now and then some batch routine kicks in to remove the items which had decreased the stock but didn't get bought/confirmed.

我们只有几个不同的产品，但我们通过电话销售了大约 30.000.000 件商品，有些产品每天的销量高达 2.000.000 件，因此该行的并发性负责该产品的库存可能会同时获得许多更新，因此获得良好的性能很重要.

We have just a few distinct products, but we have been selling about 30.000.000 items by phone, some products get sold as much as 2.000.000 every day, so the concurrency in the row responsible for the stock of that product might get many updates at the same time, so it's important we get a good performance.

这些都是常见的场景，但是否有任何设计模式可以在保持库存数量一致的同时为用户提供更好的体验并产生出色的应用程序性能?

Those are usual scenario, but is there any design pattern which gives the user a better experience while keeping the stock numbers consistent and yet yield a great application performance?

任何帮助将不胜感激.

干杯

推荐答案

首先，退一步，你真的需要解决前端的库存管理问题吗?由于您销售大量相对较少的产品，因此管理库存应该相对容易，这样您就不会缺货，或者，如果缺货，也不会阻止您完成订单.有大量关于计算安全库存的文献和例子，只需要一些统计数据即可.对我来说，将您的注意力集中在为公司提供工具(如果它还没有的话)来管理他们的库存以防止缺货情况而不是试图防止它们在销售门户中发生会更有意义.

First off, taking a step back, do you really need to solve the inventory management problem on the front end? Since you're selling large volumes of a relatively small set of products, it should be relatively easy to manage your inventory so that you are never out of stock or, if you are, it doesn't prevent you from fulfilling orders. There is a great deal of literature and examples that deal with calculating safety stock which requires just a bit of statistics to follow. It would make far more sense to me to focus your attention on giving the company the tools (if it doesn't already have them) to manage their inventory to prevent stock-out situations rather than trying to prevent them from happening in the sales portal.

话虽如此，我不太确定我是否在您概述的两个场景中解决了您的问题.即使数据库性能完美无缺，如果您只有 1 个 A 产品库存并且您无法出售没有库存的产品，那么两个客户之一，根据定义，两个潜在客户之一将输掉.如果在第一种情况下，如果 C2 的 35 件商品中的任何一件没有库存(如果他花了 20 分钟装满购物车，这似乎不太可能)，C2 将不买任何东西就离开，那么您无法在数据库中做任何事情来防止这种情况发生.您的界面可能有一些 AJAX，可以在他们购物时提醒他们购物车中的一件商品缺货，就像 StackExchange 在您输入其他人输入的答案时通知您一样.我一点也不清楚，早点告诉 C2 这个问题会有好处——如果他不能在一次交易中购买所有 35 件物品，他就会离开，不管你什么时候告诉他他都会离开C1 购买了该物品.实际上，在这种情况下，没有办法设计系统以免让两个客户中的一个失望.

That being said, I'm not quite sure that I follow your problem with the two scenarios you outline. Even if the database performance was flawless, if you have only 1 of item A in stock and you can't sell an item if it's not in stock, then one of the two customers, by definition, one of the two potential customers is going to lose out. If in the first scenario C2 is going to go away without buying anything if any of his 35 items are not in stock (which seems unlikely if he spent 20 minutes filling his cart), there is nothing you can do in the database to prevent that. Your interface could potentially have some AJAX that alerts them while they're shopping that one of the items in their cart is out of stock much like StackExchange notifies you while you're entering an answer that someone else has entered an answer. It's not at all clear to me, that telling C2 about the problem earlier is going to be beneficial-- if he's going to leave if he can't buy all 35 items in one transaction, he's going to leave no matter when you tell him that C1 bought the item. Realistically, there is no way to design the system so as not to disappoint one of the two customers in that case.

如果您能多解释一下为什么您的应用程序和您的客户对缺货情况如此敏感，这可能会有所帮助.大多数客户和大多数零售商都相对习惯于这样一个事实，即有时在下订单后，他们会收到通知，零售商将无法​​像他们预期的那样迅速完成订单，并且可以选择取消该部分他们的订单、整个订单(假设剩余商品尚未发货)，或等待商品重新入库.假设您在客户浏览库存时通知他们库存相对较低(即，如果您查看的商品只剩下少量库存，亚马逊会告诉您有 N 件商品")，大多数客户在结账时会合理地理解 20 分钟，并被告知该商品现在缺货，因为他们事先知道他们需要快速订购.大多数零售商都认为，即使最受欢迎的商品缺货，他们仍然可以满足比手头库存更多的需求，因为他们无疑会在接下来的一两天内收到新的库存，或者他们可以匆忙下单新库存.

It might help if you can explain a bit more about why your application and your customers are so sensitive to stock-out situations. Most customers and most retailers are relatively accustomed to the fact that sometimes after placing an order they get notified that the retailer isn't going to be able to fulfill the order as quickly as they had expected and are given the option to cancel that part of their order, the whole order (assuming the remaining items haven't shipped yet), or to wait for the item to come back in to stock. Assuming that you do something to notify customers while they're browsing that inventory is relatively low (i.e. Amazon will tell you "N items in stock" if you're looking at an item for which they only have a handful of stock left), most customers are reasonably understanding 20 minutes when they get to the checkout and are told that the item is now out of stock since they knew in advance that they needed to order quickly. And most retailers are comfortable that even if they run out of stock of most popular items, they can still satisfy more requests than they have inventory in hand because they undoubtedly have new inventory arriving in the next day or two or they can rush an order for new inventory.

这篇关于有没有库存管理设计模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！