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

问题描述

我们想设计一个电子商务应用程序，我们的精神有关的 consitent股票数字。我们不希望我们的客户发现了，他们买了一个项目后，即该项目是脱销，这是这里大的事。在平均这里为了有大约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）客户C1开网上商店，并找到他/她想要购买的产品;

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）客户C1把1项的篮子;

3) Customer C1 puts 1 item in the basket;

4）客户C2进入该网站，并选择同一项目（放在篮子里），这仍然是标记为库存（股票仍为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）客户C1去结帐，并确认他的购买和应用减少当前的股票该项目为0;

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

6）客户C2保持购买物品，比方说35等不同项目（花了20分钟，客户C2来选择他想要的物品）;

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）客户C2去结帐，并证实了这一收购，但现在，他买的第一项是不再可用（我们不能卖）;

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）客户C2被激怒并关闭浏览器不买东西。

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

第二方案（但我认为这是不必要的复杂和马车）：

1）客户C1开网上商店，并找到他/她想要购买的产品;

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）客户C1把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）客户C2离开网站;

5) Customer C2 leaves the website;

6）客户C1保持购买物品（股票降低了它这些物品）;

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

7）客户C1关闭浏览器;

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?

任何帮助将非常AP preciated。

Any help will be much appreciated.

干杯

推荐答案

首先，退一步，你真的需要解决在前端的库存管理问题？因为你卖大容量相对较小的一套产品，它应该是比较容易的，这样你永远不会缺货，或者，如果你管理你的库存，它不会从履行订单prevent你。有文献以及与计算安全库存处理的例子了很大的要求只是有点统计数据可循。它将使远远更有意义，我要你的注意力集中于使该公司的工具（如果它已经没有它们）来管理自己的库存，以prevent断货的情况，而不是试图prevent他们从销售门户网站发生的事情。

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.

话虽这么说，我不是很确定，我按照你的问题，两个方案你的轮廓。即使数据库的性能非常完美，如果你只有A项1的股票，如果它不是在股票，那么这两个客户之一，你不能卖一个项目，顾名思义，这两个潜在的客户之一是怎么回事被淘汰出局。如果在第一个场景C2是要离开不买任何东西，如果他的任何35项目的股票（这似乎不太可能，如果他花了20分钟填补他的车）都没有，还有什么是你可以在数据库中做prevent这一点。您的界面可能有一些AJAX可以提醒他们，而他们是购物，在他们的购物车中的项目之一是断货很像StackExchange通知您，当你进入别人已经进入一个答案的答案。这不是完全清楚对我来说，讲述早期问题C2将是beneficial--，如果他是怎么回事，如果他不能买在一个事务中所有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屋！