zookeeper集群

ooKeeper是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 前文已介绍了ZNode,

转：http://blog.csdn.net/xinguan1267/article/details/38422149 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是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 前文已介绍了ZNode,

1. Zookeeper的基本操作 　　zookeeper中的节点可以持久化/有序的两个维度分为四种类型： 　　PERSIST：持久化无序（保存在磁盘中） 　　PERSIST_SEQUENTIAL：持久化有序递增 　　EPHEMERAL：非持久化的无序的，保存在内存中，当客户端关闭后消失。 　　EPHEMERAL_SEQUENTIAL：非持久有序递增，保存在内存中，当客户端关闭后消失 　　每个节点都可以注册Watch操作，用于监听节点的变化，有四种事件类型如下： 　　Created event: Enabled with a call to exists 　　Deleted event: Enabled with a call to exists, getData, and getChildren 　　Changed event: Enabled with a call to exists and getData 　　Child event: Enabled with a call to getChildren 　　Watch的基本特征是客户端先得到通知，然后才能得到数据，Watch被fire之后就立即取消了，不会再有Watch后续变化，想要监听只能重新注册； 使用原生Zookeeper创建节点和监听节点变化代码如下： 　　1. 引入依赖，pom.xml <dependency>

本文来自 网易云社区 作者： 方金德 “咚咚”，接连收到好几个报警短信，显示线上集群的几个tomcat应用的接连端口异常。不好，线上可能出状况了，访问网站，果然已经显示为维护中了。赶紧登陆到服务器，但服务器的cpu，load，内存，io等基本指标都还是挺正常的，应用日志端也没有明显异常信息，不过nginx的访问日志的确显示后端服务器都已基本为504请求超时了。不管那么多了，距离上次发布已经有几个小时了，应该不是新版本bug直接导致的问题，先尝试不回滚重启吧。于是火速重启了集群中一个节点，很快线上应用访问正常了。然后把另外两个节点的jvm的stack和memory信息导出来后，也重启后加回到线上。 线上是正常了，但我们其实并没有找到问题的原因。没有找到问题的诱因，也就意味着这个问题可能还会再发生。和相关的同事们再一起排查了一遍线上应用日志和tomcat容器日志，也没有发现什么可挖掘的异常点。再跑到网易的监控平台看历史的监控数据，系统层面的cpu、load、 中断、 memory、 swap、 ioutil、网络流量等都没有特别的异常；jvm层面的gc、thread数也都没有什么明显异常。gc没有问题，直接放弃了memory dump信息的查看。再简单地看了下jstack信息，好像也没有什么异常，统计了下线程数，跟线上的线程数也差不多，猜测应该也不是属于并发超限吧。。。

ZooKeeper集群分布式协调服务 1.ZooKeeper概述 1.1.ZooKeeper分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题，提供分布式、高可用性的协调服务能力。 1.2.安全模式下ZooKeeper依赖于Kerberos和LdapServer进行安全认证，非安全模式则不依赖于Kerberos与Ldap。ZooKeeper作为底层组件广泛被上层组件使用并依赖，如Kafka，HDFS，HBase，Storm等。 1.3.在FusionInsight集群中主要用途是保存上层组件的元数据，并保证其主备倒换。 2.ZooKeeper简介 2.1.ZooKeeper基于开源Apache ZooKeeper作为底层组件为上层组件提供服务,主要用于解决分布式应用中经常遇到的一些数据管理问题。 3.ZooKeeper在FusionInsight中的位置 3.1.ZooKeeper基于开源Apache ZooKeeper作为底层组件为上层组件提供服务,主要用于解决分布式应用中经常遇到的一些数据管理问题 4.ZooKeeper服务架构 - 模型 4.1.ZooKeeper集群由一组Server节点组成，这一组Server节点中只存在一个Leader的节点，其他节点都为Follower。 4.2.启动时选举出leader。 4.3

Eureka与Zookeeper都是目前主流的服务注册中心，关于这两个注册中心如何去选择？我们就需要明白什么是CAP原则了。 首先来看一张图： CAP定理： 指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得，但是三者又会存在交集。 Consistency(C)：在分布式系统中的所有数据备份，在同一个时刻是否同样的值(也就是所有的节点在同一时间的数据完全一致，因此节点越多，数据同步的时间就越久) Availability(A):当负载压力过大时，集群整体是否还能够响应客户的请求(服务一直可用，而且响应时间是正常的) Partition tolerance(P):分区容错性，也就是高可用性，一个节点崩了，并不会影响其他节点的使用(100个节点，挂了几个，不会影响服务，而且节点越多容错性越高) 我们了解了C、A、P的定义后那我们来分析分析为什么不能同时满足三者： 1.C和A同时满足： C要保证数据一致，也就是需要同步数据到各个节点需要时间，但是也要保证在正常的响应时间内(A),那么就只能减少节点因此P无法满足。 2.C和P同时满足： C要保证数据一致，也就是需要同步数据到各个节点需要时间，但是节点(P)也多,因此数据（C）同步需要时间，那么就不能保证正常响应(A)请求了

【一、Zookeeper中的角色】 ①领导者（leader） Leader服务器为客户端提供读写服务。它是集群工作机制的核心，事务请求唯一调度者和处理者，保证集群事务请求处理的顺序性。 ②学习者（learner） ，学习者又分为跟随者和观察者： 跟随者（follower） Follower服务器为客户端提供读服务，参与Leader选举过程，参与写操作“过半写成功”策略。处理非事务请求，转发事务请求给领导者，同时参与投票。 观察者（observer） Observer服务器为客户端提供读服务，不参与Leader选举过程，不参与写操作“过半写成功”策略。用于在不影响写性能的前提下提升集群的读性能。该服务不参与投票，可有可无的。 ③客户端（client） 服务请求发起方。 【二、Zookeeper选举】 上面提到的服务器角色是怎么产生的呢，就是通过选举。 我这里，以一个例子的来形象说明选举的过程： 1、咱们现在有10台服务器，刚刚上线的服务器没有任何数据，崭新的。咱们给它编个号：1,2,3,4,5,6,7,8,9,10，咱们呢把这10个服务器逐个都开机了哈。 2、在服务器启动的时候啊，选举就开始了。1号服务器启动，先给自己投票，然后把自己的信息发出去，让别的也投。但是呢其他服务器还没有启动啊，于是1号服务器就收不到反馈。心情很是失落，像笔者那年一样，此时1号服务器就开始处于选举状态了

大家好，我是AC，下面是关于zookeeper的一个案例，供练习 关于zookeeper，请看上一篇文章 文章目录 （1）服务器端代码 （2）客户端代码 1）需求：某分布式系统中，主节点可以有多台，可以动态上下线，任意一台客户端都能实时感知到主节点服务器的上下线 2）需求分析 3）具体实现： （0）先在集群上创建/servers节点 [ zk : localhost : 2181 ( CONNECTED ) 10 ] create / servers "servers" Created /servers （1）服务器端代码 package com . bigdata . anli ; import org . apache . zookeeper . CreateMode ; import org . apache . zookeeper . WatchedEvent ; import org . apache . zookeeper . Watcher ; import org . apache . zookeeper . ZooDefs . Ids ; import org . apache . zookeeper . ZooKeeper ; public class RegistServer { private ZooKeeper client = null ; String

1.下载Zookeeper安装包 https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.4.10/ 2.zookeeper集群规划 主机名称 IP 部署软件 node01 192.168.183.100 zookeeper node02 192.168.183.101 zookeeper node03 192.168.183.102 zookeeper 一共部署三台机器，每台机器启动一个zookeeper进程 3.使用root用户分别登录三台机机器 切换到hadoop用户 su hadoop 进入到hadoop用户的家目录下 cd /home/hadoop 创建apps目录用于存放所有以后需要安装的软件 mkdir apps 进入到apps目录 cd ./apps 4.上传zookeeper安装包 使用rz命令上传zookeeper安装包 5.解压安装包 tar -zxvf zookeeper-3.4.10.tar.gz 退出hadoop用户切换到root用户，输入exit按回车 6.创建软连接 使用root用户操作 语法：ln -s 源路径 软连接路径 ln -s /home/hadoop/apps/zookeeper-3.4.10 /usr/local/zookeeper 7.修改环境变量