zookeeper集群

1、系统架构 Client 1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。 Zookeeper 1 保证任何时候，集群中只有一个master 2 存贮所有Region的寻址入口 3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master 4 存储Hbase的schema,包括有哪些table，每个table有哪些column family Master职责 1 为Region server分配region 2 负责region server的负载均衡 3 发现失效的region server并重新分配其上的region 4 HDFS上的垃圾文件回收 5 处理schema更新请求 Region Server职责 1 Region server维护Master分配给它的region，处理对这些region的IO请求 2 Region server负责切分在运行过程中变得过大的region 可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。 2、整体结构（ 物理存储 ） 1

启动zookeeper bin/zookeeper-server-start.sh config/zookeeper.properties & 启动kafka bin/kafka-server-start.sh config/server.properties & 停止kafka bin/kafka-server-stop.sh 停止zookeeper bin/zookeeper-server-stop.sh 创建topic bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test 展示topic bin/kafka-topics.sh --list --zookeeper localhost:2181 描述topic bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic 生产者： bin/kafka-console-producer.sh --broker-list 130.51.23.95:9092 --topic my-replicated-topic 消费者： bin/kafka-console

zookeeper 是什么？ zookeeper 都有哪些功能？ zookeeper 有几种部署模式？ zookeeper 怎么保证主从节点的状态同步？ 集群中为什么要有主节点？ 集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？ 说一下 zookeeper 的通知机制？ 来源： https://www.cnblogs.com/ldddd/p/11419922.html

系统准备 Centos6.5 Windows10 相关软件包下载： 链接：https://pan.baidu.com/s/1EOLUphwZgzwSX01HsDJM0g 提取码：1tsf 说明 特别说明: 教程用的主机名分别为master,slave1,slave2 所以发现有出现主机名为 ” spark1”的主机名 等同于 “master”如果如果看见配置文件为spark1,一定要修改成master ;有些图片是后面添加的才出现主机名不一致但并不影响理解. 没有特别说明操作都是在 master 机器操作 关闭防火墙 关闭Linux和Windows的防火墙（防止机器之间应为防火墙拦截而不能连通） Windows： window系统: 控制面板 -> 系统和安全 ->Windows Defender 防火墙 -> 启用或关闭Windows Defender 防火墙 -> 关闭Windows Defender 防火墙 //一般只关闭”专用网络设置”的防火墙就行 Linux： 停止防火墙: service iptables stop 启动防火墙: service iptables start 重启防火墙: service iptables restart 永久关闭防火墙: chkconfig iptables off 永久开启防火墙: chkconfig iptables no

用一web应用集群，负载均衡部署实现： 在上图可以看到，变量A在JVM1、JVM2、JVM3三个JVM内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果我们不加任何控制的话，变量A同进都会在JVM分配一块内存，三个请求发过来同时对这个变量进行操作，显然结果不是我们想要的。 如果我们业务中存在这样的场景的话，就需要找到一种方法来解决。 为了保证一个方法或属性在高并发的情况下同一时间只能被同一个线程执行，在传统单机部署的情况下，可以使用Java并发处理相关的API（如 ReentrantLock 或 Synchronized ）进行互斥控制。但是，随之业务发展的需要，原单机部署的系统演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同的机器上，这将原来的单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。 为了解决这个问题，就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！ 分布式锁应该具备哪些条件 在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行； 高可用、高性能的获取锁与释放锁； 具备可重入特性； 具备锁失效机制、防止死锁； 具备非阻塞锁特性，即没有获取到锁直接返回获取锁失败； 分布式锁的实现方式 目前几乎所有大型网站及应用都是分布式部署

Standalone集群构建 基础环境准备 物理资源：CentOSA/B/C-6.10 64bit 内存2GB 主机名 IP CentOSA 192.168.221.136 CentOSB 192.168.221.137 CentOSC 192.168.221.138 [外链图片转存失败(img-l9lPb4wS-1566826494200)(assets/1566785920711.png)] 节点与主机映射关系 主机 节点服务 CentOSA NameNode、ZKFC、Zookeeper、journalnode、DataNode、master、worker、broker CentOSB NameNode、ZKFC、zookeeper、journalnode、DataNode、master、worker、broker CentOSC zookeeper、journalnode、DataNode、master、worker、broker 主机与Ip的映射关系 [ root@CentOSX ~ ] # vi /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6

（一）Zookeeper集群组成结构 Zookeeper由 leader(领导者) 和 learner(学习者) 组成，其中 learner由follower(跟随者)和observer(观察者) 组成。在一个zookeeper集群中， 一般是一个leader节点，多个follower节点 ，observer节点可选。在一个正式的zookeeper环境中，一般由 2n+1（奇数） 台servers组成，主要是为了保证learder的选举能够得到大多数的支持，也就是说 只要n+1台机器支持，那么就可以保证集群的可用性。 （二）Zookeeper角色的作用 1. 领导者(leader)，负责进行投票的发起和决议，更新系统状态 2. 学习者(learner)，包括跟随者（follower）和观察者（observer）。 3. Follower用于 接受客户端请求并向客户端返回结果，在选主过程中参与投票 4. Observer可以 接受客户端请求，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度 。 5. 客户端(client)，请求发起方 （三）Zookeeper读写过程 1. client端连接上zookeeper集群的任何一台机器就可以了 2. 进行 读操作的时候

Zookeeper提供了Java API方便我们来操作zk服务，可以通过maven引入zk的相关依赖包。通过org.apache.zookeeper.Zookeeper类创建连接zk服务器的示例对象，在创建过程中给定zk服务器地址、会话持续时间以及监视器三个参数，当连接创建成功后，通过Zookeeper实例提供的接口来和服务器进行交互。Pom文件依赖内容如下： <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.5</version> （一）创建连接 使用 Zookeeper类 来表示连接，创建的该实例对象有四个构造方法来调用，不过一般最常用的是下面两个构造方法的调用：ZooKeeper(connectString,session-Timeout,watcher)和ZooKeeper(connectString,sessionTimeout,watcher,canBeRead-Only)；其中第一个构造方式底层调用第二个构造方法，只是canBeReadOnly参数设置为false。connectString参数为zk集群服务器的连接url，当给定路径的时候，表示所有的操作都是基于该路径进行操作的(路径只可以添加到最后)。例如: “hh:2181,hh:2182

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

服务器角色 服务器 192.168.58.180 192.168.58.181 192.168.58.182 192.168.58.183 Name CentOSMaster Slvae1 Slave2 StandByNameNode NameNode Yes Yes DataNode Yes Yes Yes journalNode Yes yes Yes ZooKeeper Yes Yes Yes ZKFC Yes Yes Spark Yes Yes hbase Yes Yes Slave2没有zookeeper，所以hbase装在183和181，不过由于hbase.rootdir必须在hdfs上，所以估计还是只能搭载在180和183上。就是不知道zk和hbase必须对应，就是说2个hbase，三个zk不知道行不。备注：我的公钥文件在/home/hxsyl/.ssh下不在/root/hxsyl下，通过 find / -name id_rsa 　　查找 1.分别在每个机器上运行命令zkServer.sh start或者在$ZOOKEEPER_HOME/bin目录下运行./zkServer.sh start命令。然后可以通过命令jps来查看Zookeeper启动的进程QuorumPeerMain。 可通过zkServer.sh status命令来查看Zookeeper状态