场景很容易描述,但可能有一个复杂的答案:
想象一下你有一个只写mysql数据库的情况。然后你有大约 5 或 6 个只读数据库。写入数据库具有特定库存的计数。您有成千上万的用户在使用这个特定的库存项目,但数量有限。为了论证的缘故,说 10 个项目。
确保只售出 10 件商品的最佳方法是什么?如果只读从站更新的时间之间甚至有 200 毫秒的增量,计数的完整性是否会过时,从而销售您没有的库存?
你将如何解决/扩展这个问题?
场景很容易描述,但可能有一个复杂的答案:
想象一下你有一个只写mysql数据库的情况。然后你有大约 5 或 6 个只读数据库。写入数据库具有特定库存的计数。您有成千上万的用户在使用这个特定的库存项目,但数量有限。为了论证的缘故,说 10 个项目。
确保只售出 10 件商品的最佳方法是什么?如果只读从站更新的时间之间甚至有 200 毫秒的增量,计数的完整性是否会过时,从而销售您没有的库存?
你将如何解决/扩展这个问题?
并发用户的基本解决方案可能也会涵盖这一点。在“购买”交易的某个时刻,您需要减少库存(在写入服务器上)。通过任何方法,强制库存不能低于零。
如果剩下一件物品,而有两个人想买它,那么一个人就倒霉了。
复制延迟是完全一样的。两个用户看到可用的产品,但当他们尝试购买时,它已经消失了。该场景的一个很好的解决方案包括复制延迟和用户简单地从另一个用户下抢夺最后一个项目。
这完全取决于您决定锁定主表以进行更新的时间和窗口。
A. 如果您必须 100% 确定某件商品只有在确实可用时才会尝试购买。一旦您向特定用户列出该项目,您就必须为他锁定该项目(这意味着您将暂时减少库存)
B. 如果您可以展示“抱歉,我们刚刚缺货”的信息。您应该在结帐之前锁定该项目(好吧,您可以在交易完成后这样做。但代价是非常愤怒的客户)
我会选择方法 A 进行锁定,并且可能会针对剩余库存非常少的物品标记“即将售罄”警告。(如果这是一个非常频繁的情况,您还可以计算同时点击该项目的用户数量并给出更准确的警告)
从业务角度来看,您不希望库存如此之低(低于同时购买者的数量)这当然是在“圣诞节”时期是不可避免的,因为它可以缺货:)