1

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

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

Member1, resourceA, OK

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

Member2, resourceA, NOT_OK

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

我的问题是：当两个或多个节点同时开始关于同一主题（resourceA）的分发时，如何处理它？

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

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

4

1 回答 1

1

根据您的描述，可以得出以下结论：

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

如果其中一个结论不正确（或两者都不正确），那么我看不出您的算法是如何工作的，因为无法知道所有成员何时都响应了启动消息并得出结论哪个成员具有最高 ID。

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

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

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

于 2012-09-16T23:02:11.543 回答