【问题标题】:Distributed Architecture - How to Architect for Data Consistency分布式架构 - 如何构建数据一致性
【发布时间】:2022-01-27 01:13:38
【问题描述】:

我在一次采访中遇到了这个问题,我很难弄清楚。

问题:有一个分布式系统运行不同的服务。假设有一个库存服务,有 10 个数量可用。将 9 件商品放入购物车(订购服务)的用户,同时另一个用户进来并尝试订购 2 部手机,因为数量超过了可用的数量,他是不允许的。但后来用户 1 没有继续下订单,用户 2 将结帐 1 部可用的手机。如何进行架构设计以确保解决这种情况并且不影响用户体验。

【问题讨论】:

  • 理想情况下,添加到购物车不应阻止其他用户添加或购买。因此,无论谁先购买/结帐,都应该得到该商品,而后来的用户应该得到错误。

标签: api microservices arch


【解决方案1】:

这实际上是一个基于意见的问题(或者,根据所提供的信息,这是一个无法回答的问题),因为它取决于企业和用户体验的价值。

您可以追求绝对一致性并在库存中实施某种租赁系统,在购物车中添加物品会保留它们,如果有人长时间无人看管购物车,系统会清除购物车并释放租赁。好处是你可以向某人做出更强有力的承诺,将手机放入购物车意味着他们会得到一部手机(可能对用户体验和客户信任有好处),坏处是当有人对购物车犹豫不决并且手机是显示为其他人不可用(可能不利于用户体验和客户信任)。您可以通过在取消购物车之前缩短超时时间来缓解这种情况,但您认为如果客户将手机添加到购物车并不得不回复紧急消息然后回来发现购物车已清空,您会有何感受?

租赁方式也不能保证绝对的承诺:库存服务表明有 10 部手机库存并不意味着实际有 10 部可售手机。您如何解释有人将手机放在购物车中,而您仓库中的叉车司机驶入存放这 10 部手机的货架部分并销毁它们的情况?您并没有逃避有一个流程来处理接受结果证明没有库存的订单的义务。

诚然,您可以通过在人工挑选商品并将商品放入购物车之前不实际将商品添加到购物车来增加承诺的绝对性:尽管可能不希望出现延迟和额外成本。

或者,可以围绕恢复过程进行构建。允许有冲突的订单,但在拣选商品之前不要尝试收费。如果订单多于商品,则您向未获得商品补偿的人提供某种形式的补偿(“很抱歉,我们现在无法交付此商品。这是您下次购买的半价优惠券” ),或者您可以有效地参加拍卖,看看哪个客户会接受最少的补偿,以换取稍后获得产品。您可以将缺货状态异步传达给显示产品目录和管理购物车的服务,以减少出现不一致的窗口。

【讨论】:

    猜你喜欢
    • 2015-02-09
    • 1970-01-01
    • 2020-08-05
    • 2011-08-15
    • 2016-03-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-01-21
    相关资源
    最近更新 更多