《zookeeper》专题

使用Zookeeper依赖关系 Spring Cloud Zookeeper可以让您提供应用程序的依赖关系作为属性。作为依赖关系，您可以了解Zookeeper中注册的其他应用程序，您可以通过Feign（REST客户端构建器）以及Spring RestTemplate呼叫。 您还可以从Zookeeper依赖关系观察者功能中受益，这些功能可让您控制和监视依赖关系的状态，并决定如何处理。 如何激活Zoo

Spring Cloud Zookeeper实现ServiceRegistry接口，允许开发人员以编程方式注册任意服务。 ServiceInstanceRegistration类提供builder()方法来创建可以由ServiceRegistry使用的Registration对象。 @Autowired private ZookeeperServiceRegistry serviceRegistr

Spring Cloud Netflix提供有用的工具，无论使用哪种DiscoveryClient实现。Feign，Turbine，Ribbon和Zuul均与Spring Cloud Zookeeper合作。 Ribbon与Zookeeper Spring Cloud Zookeeper提供Ribbon的ServerList的实现。当使用spring-cloud-starter-zookeeper

服务发现是基于微服务架构的关键原则之一。尝试配置每个客户端或某种形式的约定可能非常困难，可以非常脆弱。策展人（一个用于Zookeeper的java库）通过服务发现扩展提供服务发现服务。Spring Cloud Zookeeper利用此扩展功能进行服务注册和发现。 如何激活 包括对org.springframework.cloud:spring-cloud-starter-zookeeper-dis

请参阅安装文档获取有关如何安装Zookeeper指令。

该项目通过自动配置并绑定到Spring环境和其他Spring编程模型成语，为Spring Boot应用程序提供Zookeeper集成。通过几个简单的注释，您可以快速启用和配置应用程序中的常见模式，并使用基于Zookeeper的组件构建大型分布式系统。提供的模式包括服务发现和配置。智能路由（Zuul）和客户端负载平衡（Ribbon），断路器（Hystrix）通过与Spring Cloud Netfl

为了对如何使用Zookeeper工作有一个预先的理解，我们使用zkCli工具来访问Zookeeper服务器，并执行请求。我们使用这个工具来展示master-worker例子中大部分操作。当实现一个真实的Zookeeper应用时，你不应该使用这个工具。它大部分是用于调试和监控的目的。相反的，你应该使用Zookeeper提供的一种语言的绑定实现。在下一章中，我们使用Java来实现我们的例子。

master-worker模型有三个角色： worker向系统注册它们自己的信息，确保master能“看见”它们并能执行任务，同时监视新的任务。 让我们来过一遍不同的角色，了解每个角色需要执行的步骤。

幸运的是，即使我们只有一台机器也能运行多个服务器。我们只需要建立一个更高级的配置文件。 为了让服务器之间相互联系，它们需要一些联系人的信息。理论上服务器可以通过多播协议来发现对方，但是我们支持除了单一网络外运行Zookeeper集合分散在多个网络中以支持多个Zookeeper集合。 图2-7 客户端重连接例子 initLimit=10 dataDir=./data server.2=127.0.0

大部分会话的状态字如其名：连接中（CONNECTING)、已连接（CONNECTED)、已关闭（CLOSED)和未连接（NOT_CONNECTED)。状态转化依赖于客户端和服务器间发生的不同事件。 图2-6 会话状态和转化 有一个重要的参数你要设置的是当创建会话时的超时时间，它是Zookeeper服务允许一个会话宣称它过期的时间。如果服务在时间t内没有收到指定会话相关的消息，它就会宣称会话过期了。

假设你下载并解压了一个Zookeeper的发行版，打开一个shell，切换目录(cd)到工程的根目录，重命名示例配置文件： 虽然是可选的，但最好把data目录从\/tmp移出避免zookeeper填满你的根分区。你在zoo.cfg中可以改变它的位置： dataDir=/users/me/zookeeper 最后启动服务器，执行以下命令： # bin/zkServer.sh start JMX en

为仲裁模式选定足够的服务器是很重要的。无论系统延迟和奔溃，仲裁者必须保证任何的更新请求Zookeeper都会积极的响应并保存，直到另外一个请求取代它。 这个例子就是在第一章提到过的脑裂场景之一。为了避免这个问题，这个例子中仲裁者的数量不得低于三个，这是五台服务器的大多数。为了继续运行，整个Zookeeper集合必须保证三台服务器可用。为了确认更新请求已经成功的完成了，Zookeeper集合需要至少

图 2-2 在同一个znode上执行多次读 图2-3 利用通知来告知znode的变化 当使用通知时，有些事情需要注意。因为通知是一次性操作，有可能新的变化正好发生在接收通知和设置监视器之间（放心，你不会错过状态的变化）。让我们看一个例子来了解它是如果工作的。假设以下事件按顺序发生： 通知一个重要的保证是在任何发生在znode上的变化生效之前它会传递到客户端。如果一个客户端在一个znode上设置了监

持久化的和临时的 一个znode节点要么是持久化的要么是临时的。一个持久化的znode节点只能通过调用delete方法来删除。相对的，一个临时的znode节点会在创建它的客户端奔溃或者断掉与zookeeper的连接时自动删除。 临时zode节点的心智是只有当会话的创建者工作正常时，应用的某些部分必须存在。比如，master-worker例子中的master节点就是临时的。它的存在暗示着现在有一个m

delete \/path 删除路径为\/path的znode节点 setData \/path data 设置路径为\/path的znode的节点数据为data getChildren \/path 获取路径为\/path的znode节点的孩子节点