关于Zookeeper及其客户的主要选举
我很难理解领导者、追随者机制是如何工作的，比如说，我正在构建一个分布式应用程序，其中有2个主节点、6个从节点和3个zookeeper节点，其中一个zookeeper节点是领导者，两个主节点中的1个是活动的，并连接到zookeeper领导者。
我的问题是
>
当管理员节点死亡时，是否会发生领导者选举机制？以及它将如何影响我们的主人，我们的主人是否会与新当选的领导人连接？
如果我们的应用程序的主节点死了，备用主节点是否会被通知，如果它监听主节点的znode，如果是这样，它是否足以让我们的备用节点具有短暂的顺序节点或我们需要做的任何其他事情使其作为主节点处于活动状态？
Zookeeper的文档称，写操作只通过leader进行，它会向其他跟随者节点广播，而读操作则直接由跟随者节点提供服务。这与我的应用程序的读写设计有任何关系吗（即）我打算设计我的写必须通过我的主程序进行，而读必须通过我的从程序进行，zookeeper的广播能力与此有任何关系吗？或者zookeeper的写入与应用程序的写入完全不同。
抱歉，如果我问了什么不合理的问题，请帮我理解。任何能解释这些的资源都会对我很有帮助。
共有1个答案
假设您正在使用Curator来选举master。我将解释Curator Recipe的master选举过程，然后您可以解决所有问题。
主选举使用ZooKeeper的两个特性，短暂节点和顺序节点- 得到最少数量的应用节点将被选为主节点，会话将成为临时所有者
- 在你的主应用节点死亡后，ZooKeeper会删除并注意到所有正在观看该节点的节点
-
主要内容：1.概述,2.接口描述1.概述 在 dubbo-remoting-zookeeper 模块，实现了 Dubbo 对 Zookeeper 客户端的封装。在该模块中，抽象了通用的 Zookeeper Client API 接口，实现了两种 Zookeeper Client 库的接入： 基于 Apache Curator 实现： <dubbo:registry address=“zookeeper://127.0.0.1:2
-
一、基本依赖 Curator 是 Netflix 公司开源的一个 Zookeeper 客户端，目前由 Apache 进行维护。与 Zookeeper 原生客户端相比，Curator 的抽象层次更高，功能也更加丰富，是目前 Zookeeper 使用范围最广的 Java 客户端。本篇文章主要讲解其基本使用，项目采用 Maven 构建，以单元测试的方法进行讲解，相关依赖如下： <dependencies
-
问题内容： 我对t sql的经验很少，我必须写一个存储的。 这是我存储的： 这些是我的问题： 1-是否存在宏观误差？ 2-有人建议使用“ SELECT CASE”，其他人建议使用“ IF … ELSE”，有什么区别？那我的存储的最佳选择是什么？ 3-我不确定使用“ BEGIN … END”语句，特别是结合使用“ IF … ELSE”语句。这是什么意思？是否有必要在“ IF … ELSE”语句中放入
-
本文向大家介绍Zookeeper 如何选举master 主节点？相关面试题，主要包含被问及Zookeeper 如何选举master 主节点？时的应答技巧和注意事项，需要的朋友参考一下 还记得上面我们的所说的临时节点吗？因为 的强一致性，能够很好地在保证 在高并发的情况下保证节点创建的全局唯一性 (即无法重复创建同样的节点)。 利用这个特性，我们可以 让多个客户端创建一个指定的节点 ，创建成功的就是
-
我们有一些SolrCloud 最初，我们使用hostfile条目来识别动物园管理员，但鉴于AWS的性质，确保主机中的条目是最新的变得非常乏味。因此，我们现在通过Route53使用自定义DNS来识别动物园管理员。但我们仍在单独识别ZooKeeper节点，因此，作为一个示例，我们目前在启动客户机时指定了这一点： 主机等只是对每个ZooKeeper EC2实例的DNS进行CNAME。因此，现在如果Ama
-
主要内容：实例,实例本教程使用的 IDE 为 IntelliJ IDEA，创建一个 maven 工程，命名为 zookeeper-demo，并且引入如下依赖，可以自行在maven中央仓库选择合适的版本，介绍原生 API 和 Curator 两种方式。 IntelliJ IDEA 相关介绍： Intellij IDEA 使用教程 Maven IntelliJ <dependency> <groupId>junit</g