【问题标题】:How to handle race conditions in distributed programming?如何处理分布式编程中的竞争条件?
【发布时间】:2020-02-10 14:24:10
【问题描述】:

我似乎无法在网上找到很多关于此的内容。在分布式编程中,存在竞争条件带来风险的许多场景。例如,如果我有一个聊天系统,我想将每个房间中的用户数限制为 100。由于竞争条件,许多并发加入可能会导致单个房间中的用户超过 100 个。我能想到的唯一解决方案是使用分布式锁。但是,我觉得有更清洁的方法来解决这个/这些问题。是否有任何关于此的在线指南或资源?

【问题讨论】:

  • 为什么会投反对票?

标签: design-patterns distributed-computing distributed race-condition distributed-system


【解决方案1】:

这一切都归结为您想要采用的一致性模型。 如果您想要系统中的强一致性(系统中的每个节点在任何时间点都看到相同的计数器值并且该值始终是“有效的”) - 您无法使用分布式共识算法来逃避(分布式锁是这种alg的情况)。

但是你可以通过改变你的期望来克服它。例如,您可能会接受计数器值最终将是“有效”(“最终一致性”模型)并使用 CRDT 作为计数器并“稍后”解决事务冲突。

【讨论】:

  • 感谢您的回复。对于我在问题中提到的场景,您会亲自使用分布式锁吗?
  • 如果我真的不想要超过 100 个用户,并且我希望他们中的很多人几乎同时加入聊天(高流量服务) - 可能。问题是 - 如果您的聊天室很小(最多 100 个用户),这意味着任何聊天室都可能适合单个服务器,您可以假设系统不是分布式的(至少对于那个特定的房间)并且用户本地存储或关系数据库来跟踪加入的用户。
  • 但是如果您想要高可用性,您真的不能做出这样的假设吗?我进行分发的主要原因是避免单点故障。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2019-06-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-11-12
  • 1970-01-01
相关资源
最近更新 更多