【问题标题】:A distributed algorithm to assign a shared resource to one node out of many一种将共享资源分配给多个节点中的一个节点的分布式算法
【发布时间】:2012-09-09 04:20:42
【问题描述】:

我尝试实现多播通信来分配一些资源。我为此使用jGroups,所以我有可靠的多播和FIFO-Ordering。通过这样做,我想意识到使用分布式解决方案,这意味着没有充当协调器的主节点。

每个节点都能够启动分发,因此有可能两个或多个节点同时启动分发。当一个节点收到一个分发消息时,它会回答这个问题。回答消息和来自初学者的消息之间没有区别。它仅包含有关资源名称(例如 resourceA)以及该节点是否能够处理它的信息。 当 Member1 开始分发时,它将发送如下消息:

Member1, resourceA, OK

Member2 没有该资源的空间并发送如下回复消息:

Member2, resourceA, NOT_OK

在这种情况下很容易,因为现在 Member1 知道他可以获取资源 A。当多个节点能够处理资源时,其他属性将决定谁获取资源(例如,具有最高 ID 的成员)。

我的问题是:当两个或多个节点同时开始关于同一主题(resourceA)的分发时,如何处理?

有没有人发现这样做有问题: Member1 和 Member2 同时开始分发。在这一点上,双方都在期待对方的回应。由于在响应消息或启动消息中没有区别这一事实,两者都认为他们刚刚收到的消息是应答者。因此 Member1 向多播组发送一个起始消息,而 Member2 向多播组发送一个起始消息(在接收到来自 Member1 的消息之前)。现在 Member1 正在接收来自 Member2 的 starter-message 并认为这是响应。

通过保证每个节点每个主题只发送一条消息(作为启动器或响应),我会说即使有两个以上的节点,这样做也没有问题。

【问题讨论】:

  • 如何让这些请求和确认消息不同?它们必须相同吗?
  • 通过使用不同类型的消息,我需要进行碰撞检测。因为可能会发生 Member1 开始分发 resourceA 并且同时 Member2 开始相同的分发。 Member3 向 Member1 发送应答,Member4 向 Member2 发送应答。现在 Member3 正在接收 Member2 的消息并且必须检测碰撞。之后,他必须向所有人发送中止消息。会更复杂。

标签: java networking network-programming distributed-computing multicast


【解决方案1】:

根据您的描述,可以得出以下结论:

  • 假定所有成员从一开始就在运行,一旦此系统运行,将不会添加新成员,也不会删除任何成员
  • 所有成员都知道系统中的成员总数

如果这些结论之一不正确(或两者都错误),那么我看不出您的算法是如何工作的,因为无法知道所有成员何时都响应了启动消息并得出结论哪个成员具有最高 ID。

如果两个结论都是正确的,那么我认为算法的功能没有问题,并且您的方法似乎有效。然而,由此产生的系统对于失败或不响应的成员将是容易出错的。如果一个成员没有响应启动消息,那么您最终可能会遇到无法决定谁将获取资源的情况,因为它可能是也可能不是那个不响应的成员。

很遗憾,其中一位成员很可能在某个时候不会做出回应——尽管您没有提供任何有关正常运行时间要求的信息。为了避免仅仅因为一个成员没有响应而导致算法完全崩溃,您必须在算法中设计预防措施,例如通过添加超时并在成员没有响应时从“已知成员列表”中删除该成员及时。

但即使有这样的内置容错,您应该意识到,根据定义,没有某种协调主机的完全分布式解决方案将遇到难以处理的情况。例如,在分布式环境中,网络问题可能导致一半网络看不到另一半的情况。由于没有协调主人得出任何最终结论,网络的两半都认为“他们了解世界”,并将继续做他们的事情。为了决定如何解决这个问题,您必须更清楚自己的要求并更好地了解可能的故障情况......

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-12-08
    • 2018-09-06
    • 2019-03-17
    • 2021-11-10
    • 2019-09-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多