你怎么看待这件事?
在不了解您的需求细节的情况下,很难完全评估您的算法的有效性。总的来说,它看起来是一种有效的方法,但我认为有一些问题值得关注。
您的问题与将共享资源分配给多个节点中的一个节点的分布式算法有一些相似之处。因此,我在回答这个问题时提出的一些论点也适用于这个问题。
当需要选举主节点时,所有从节点将(同时)向其他 4 个节点发送请求成为主节点的消息,但只有该主节点将被选举,并由所有从节点以确认消息确认。
这种方法假设所有从站都知道在任何时候有多少从站存在——否则假定的主站在收到所有从站的确认时永远无法得出结论。隐含地,这意味着没有奴隶可以在不破坏算法的情况下离开和加入系统。
但实际上,由于崩溃、重启、网络中断等原因,这些从站会来来去去。这种情况的机会随着从站的数量而增加,但这是否是一个问题取决于您的要求。您的系统必须具备多大的容错能力?
顺便说一句,由于您提到有很多从站,我假设您正在使用多播或广播来发送请求消息。否则,根据许多对您的意义,您的设置在管理所有从属服务器所在的位置时可能容易出错。
如果自己的“Promotion Priority”低于请求节点,或者如果具有较高优先级的请求节点超时发出拒绝消息,则从节点将发送确认消息。
与前面的评论类似:如果某个从站由于某种原因出现响应问题,则从站可能会得出错误的结论。事实上,如果一个从站宕机或有网络问题,所有其他从站都会得出相同的(很可能是错误的)结论,即没有响应的从站是主站。
这个算法应该更快,因为所有的从设备将并行选举一个主设备
这个答案中提出的问题几乎是以分布式方式进行主选择所固有的,并且如果不引入某种集中式决策者就很难解决。你得到一些,你失去一些……
是否存在其他具有优先级的大师提升算法?
另一种方法是让系统中的所有从属设备不断维护有关谁是当前主设备的管理。这可以通过让每个从属设备通过某种心跳消息定期多播/广播其优先级来完成(以一些网络带宽为代价)。这样一来,每一个奴隶都会意识到其他每一个奴隶,并且在需要选择一个主人的那一刻,每个奴隶都可以立即做到这一点。由于丢失了心跳,将检测到网络问题或其他“系统健康”问题。该算法对于从属系统加入和离开系统是灵活的。心跳频率越高,您的系统对拓扑变化的响应就越快。但是,由于网络断开,您可能仍然会遇到从站运行得出独立结论的问题。