关于领导人选举的一些想法

问题描述

| 我正在尝试进行领导人选举。这些天来,我一直在考虑使用键值存储来实现这一点,但是我不确定这个想法在可伸缩性和一致性问题上是否可靠。真正的部署将具有数千个节点,并且选举应该在没有任何中央机构或服务(如Zookeeper)的情况下进行。 现在,我的问题是: 我可以使用键值存储(最好是Ria这样的C-A可调参数)来执行领导者选举吗?利用KV商店进行领导人选举有哪些利弊? 谢谢! 编辑: 我对欺负算法方法不再感兴趣。     

解决方法

不保证一致性的键值存储(例如Riak)是执行此操作的一种不好方法,因为您可能会得到两个都(有理由!)认为它们是新领导者的节点。保证一致性的键值存储不会在出现问题时保证可用性,并且当您遇到可能导致节点丢失的问题时,可用性将受到损害。 我建议对数千个节点执行此操作的方法是,从具有数千个节点的直接对等方安排到分层安排。因此,有一个大师和几个小组。每个传入节点都分配给一个组,该组将其分配给一个子组,再将其分配给一个子子组,直到您发现自己在足够小的对等组中为止。然后,仅在小组领导人之间举行大师选举,获胜者将成为该小组的领导人。如果某个组的负责人离开(可能是由于晋升),则其子组的各负责人之间的主选举将选举新的负责人。等等。 如果对等方组变得太大,例如26,则其主节点将其随机分为5个较小的组,每组5个对等方,并随机分配领导者。同样,如果一个对等组太小,例如3个,则它可以请其领导者与其他人合并。如果领导者注意到跟随者太少,例如3,那么它可以告诉其中一个将其子小组提升为完整小组,并加入其中一个小组。您可以使用这些数字,具体取决于所需的冗余度。 这将导致更多的选举,但是您将大大减少每次选举的开销。这应该是一个非常重要的整体胜利。首先,随机混乱的节点不会立即开始轮询数千个对等节点,从而导致网络流量激增。     

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...