zookeeper原理

原文链接: http://www.jasongj.com/zookeeper/fastleaderelection/ Zookeeper是什么 Zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。 这一切的基础，都是Zookeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。 既然是一个文件系统，就不得不提Zookeeper是如何保证数据的一致性的。本文将介绍Zookeeper如何保证数据一致性，如何进行领导选举，以及数据监控/通知机制的语义保证。 Zookeeper架构 角色 Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种 Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。 Follower 一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理

#0 系列目录# Zookeeper系列 【Zookeeper系列一】Zookeeper应用介绍与安装部署 【Zookeeper系列二】ZooKeeper典型应用场景实践 【Zookeeper系列三】ZooKeeper Java API使用 【Zookeeper系列四】ZooKeeper 分布式锁实现 【Zookeeper系列五】ZooKeeper 实时更新server列表 【Zookeeper系列六】Zookeeper 工作原理 Zookeeper源码 【Zookeeper源码一】Zookeeper 源码环境搭建 【Zookeeper源码二】Zookeeper 客户端创建连接过程分析 【Zookeeper源码三】Zookeeper 单机版服务器介绍 【Zookeeper源码四】Zookeeper 集群版服务器介绍 【Zookeeper源码五】Zookeeper 集群版建立连接过程 Zookeeper应用 基于ZooKeeper的分布式Session实现 #1 Zookeeper概述# ZooKeeper是一个为分布式应用所设计的分布的、开源的协调服务，它主要是 用来解决分布式应用中经常遇到的一些数据管理问题，简化分布式应用协调及其管理的难度，提供高性能的分布式服务 。ZooKeeper本身可以 以Standalone模式安装运行 ，不过

　　关于zookeeper的原理解析，可以参见 zookeeper核心原理详解 ，本文所述大多数实践基于对zookeeper原理的首先理解。 　　Curator是Netflix公司开源的一个Zookeeper客户端，目前是apache顶级项目。与Zookeeper提供的原生客户端相比，Curator的抽象层次更高，简化了Zookeeper客户端的开发量，相当于netty之于socket编程。提供了一套易用性和可读性更强的Fluent风格的客户端API框架。官网为http://curator.apache.org/ 　　除此之外，Curator中还提供了Zookeeper各种应用场景（Recipe，如共享锁服务、Master选举机制和分布式计算器等）的抽象封装。 所以说啊，不管是做底层库还是应用，用户体验真的很重要。 关于zookeeper的java客户端 　　Zookeeper的 官方客户端 提供了基本的操作，比如，创建会话、创建节点、读取节点、更新数据、删除节点和检查节点是否存在等。但对于开发人员来说，Zookeeper提供的基本操纵还是有一些不足之处。典型的缺点为： （1）Zookeeper的Watcher是一次性的，每次触发之后都需要重新进行注册； （2）Session超时之后没有实现重连机制； （3）异常处理繁琐，Zookeeper提供了很多异常

1、Zookeeper 的由来 在Hadoop生态系统中，许多项目的Logo都采用了动物，比如 Hadoop 和 Hive 采用了大象的形象，HBase 采用了海豚的形象，而从字面上来看 ZooKeeper 表示动物园管理员，所以大家可以理解为 ZooKeeper就是对这些动物（项目组件）进行一些管理工作的。 对于单机环境多线程的竞态资源协调方法，我们一般通过线程锁来协调对共享数据的访问以保证状态的一致性。 但是分布式环境如何进行协调呢？于是，Google创造了Chubby，而ZooKeeper则是对于Chubby的一个开源实现。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。它被设计为易于编程，使用文件系统目录树作为数据模型。 2、ZooKeeper集群模式典型架构 2.1 角色 Zookeeper服务自身组成一个集群(2n+1个服务允许n>=1个失效)。Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种 Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader

1 zookeeper原理 Zookeeper虽然在配置文件中并没有指定master和slave 但是，zookeeper工作时，是有一个节点为leader，其他则为follower Leader是通过内部的选举机制临时产生的 1.1 zookeeper的选举机制（全新集群paxos） 以一个简单的例子来说明整个选举的过程. 假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么. 1) 服务器1启动,此时只有它一台服务器启动了,它发出去的包没有任何响应,所以它的选举状态一直是LOOKING状态 2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态. 3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader. 4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3

zookeeper 注册中心 Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 [1]。 流程说明： 服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址 服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址 监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。 支持以下功能： 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息 当注册中心重启时，能自动恢复注册数据，以及订阅请求 当会话过期时，能自动恢复注册数据，以及订阅请求 当设置 时，记录失败注册和订阅请求，后台定时重试 可通过 设置 zookeeper 登录信息 可通过 设置 zookeeper 的根节点，不配置将使用默认的根节点。 支持 * 号通配符 ，可订阅服务的所有分组和所有版本的提供者 使用 在 provider 和 consumer 中增加 zookeeper

监控zookeeper来自网上，大家一搜就可搜到了，只是zabbix版本和zookeeper有点出入，自行修改一下就可以了。 zookeeper监控要点 系统监控 这个监控linux系统以及修改linux服务器参数即可 内存使用量 ZooKeeper应当完全运行在内存中，不能使用到SWAP。Java Heap大小不能超过可用内存。 Swap使用量 使用Swap会降低ZooKeeper的性能，设置vm.swappiness = 0 网络带宽占用 如果发现ZooKeeper性能降低关注下网络带宽占用情况和丢包情况，通常情况下ZooKeeper是20%写入80%读入 磁盘使用量 ZooKeeper数据目录使用情况需要注意 磁盘I/O ZooKeeper的磁盘写入是异步的，所以不会存在很大的I/O请求，如果ZooKeeper和其他I/O密集型服务公用应该关注下磁盘I/O情况 ZooKeeper监控 zk_avg/min/max_latency 响应一个客户端请求的时间，建议这个时间大于10个Tick就报警 平均延迟/最小延迟/最大延迟 zk_outstanding_requests 排队请求的数量，当ZooKeeper超过了它的处理能力时，这个值会增大，建议设置报警阀值为10 堆积请求数 zk_packets_received 接收到客户端请求的包数量 收包数 zk_packets

环境：centos7 、JDK8 一、Zookeeper原理简介 ZooKeeper是一个开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 Zookeeper设计目的 最终一致性：client不论连接到那个Server，展示给它的都是同一个视图。 可靠性：具有简单、健壮、良好的性能、如果消息m被到一台服务器接收，那么消息m将被所有服务器接收。 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。 原子性：更新只能成功或者失败，没有中间状态。 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。 Zookeeper工作原理 1、在zookeeper的集群中，各个节点共有下面3种角色和4种状态： 角色：leader,follower,observer 状态

无论是公司的生产环境，还是自己搭建的测试环境，Zookeeper集群的节点个数都是奇数个。至于为什么要是奇数个，以前只是模糊的知道是为了满足选举需要，并不知道详细的原因。最近重点学习zookeeper，了解到其中的原理，现将其整理记录下来。 首先需要明确zookeeper选举的规则：leader选举，要求 可用节点数量 > 总节点数量/2 。注意 是 > , 不是 ≥。 注：为什么规则要求 可用节点数量 > 集群总结点数量/2 ？ 如果不这样限制，在集群出现脑裂的时候，可能会出现多个子集群同时服务的情况（即子集群各组选举出自己的leader）， 这样对整个zookeeper集群来说是紊乱的。 换句话说，如果遵守上述规则进行选举，即使出现脑裂，集群最多也只能回出现一个子集群可以提供服务的情况（能满足节点数量> 总结点数量/2 的子集群最多只会有一个）。所以要限制 可用节点数量 > 集群总结点数量/2 。 采用奇数个的节点主要是出于两方面的考虑： 1、防止由脑裂造成的集群不可用。 首先，什么是脑裂？集群的脑裂通常是发生在节点之间通信不可达的情况下，集群会分裂成不同的小集群，小集群各自选出自己的master节点，导致原有的集群出现多个master节点的情况，这就是脑裂。 下面举例说一下为什么采用奇数台节点，就可以防止由于脑裂造成的服务不可用： (1) 假如zookeeper集群有 5

ZooKeeper是Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeeper典型的应用场景。 ZooKeeper基本原理 1. 数据模型 如上图所示，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识，比如上图中第三层的第一个ZNode, 它的路径是/app1/c1。在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)，这个特性非常有用，在后面的典型应用场景中会介绍到。另外，每个ZNode上还存储了其Acl信息，这里需要注意，虽说ZNode的树形结构跟Unix文件系统很类似，但是其Acl与Unix文件系统是完全不同的，每个ZNode的Acl的独立的， 工控机 子结点不会继承父结点的，关于ZooKeeper中的Acl可以参考之前写过的一篇文章《说说Zookeeper中的ACL》。 2.重要概念 2.1 ZNode