zookeeper集群

本文转载自：https://www.cnblogs.com/felixzh/p/5869212.html Zookeeper的功能以及工作原理 1.ZooKeeper是什么？ ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户 2.ZooKeeper提供了什么？ 1)文件系统 2)通知机制 3.Zookeeper文件系统 每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。 有四种类型的znode： 1、PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后，该节点依旧存在 2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 3、EPHEMERAL-临时目录节点 客户端与zookeeper断开连接后，该节点被删除 4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

本文基于Docker搭建一套单节点的Kafka消息队列，Kafka依赖Zookeeper为其管理集群信息，虽然本例不涉及集群，但是该有的组件都还是会有，典型的kafka分布式架构如下图所示。本例搭建的示例包含Zookeeper + Kafka + Kafka-manger #获取镜像 · zookeeper镜像：zookeeper:3.4.9 · kafka镜像：wurstmeister/kafka:0.10.2.0 · kafka-manager镜像：kafka-manager:latest # 建立Zookeeper容器 这里我们用最简单的方式创建一个独立的Zookeeper节点，如果要考虑zookeeper的高可用，可以将其做成一个集群，最好是能有多台机器。 docker run --name some-zookeeper \ --restart always \ -p 2181:2181 \ -d zookeeper 默认的，容器内配置文件在，/conf/zoo.cfg，数据和日志目录默认在/data 和 /datalog，需要的话可以将上述目录映射到宿主机的可靠文件目录下。 参考： https://hub.docker.com/_/zookeeper/ # 建立kafka节点 这里同样只做一个简单的单点kafka docker run --name kafka \ -p

Zookeeper 选举机制和脑裂问题 之前刚接触的时候对这两个概念有所了解，因为用不到，隔一段时间就忘了。网上的解答又鱼龙混杂，由于各人理解不同，工作/学习环境不同，结果良莠不齐。每次搜索回忆都需要很长时间。在此特地将我个人的理解记录下来。 如果文章内容有问题，欢迎评论或与我进行讨论（请注明原因）： mail: wgh0807@qq.com 微信: hello-wgh0807 qq: 490536401 zookeeper选举 zookeeper 集群中包含的角色： leader，领导人，负责投票发起和决议；更新系统状态；分配用户请求到跟随者；不实际处理业务。在集群中也被称为master。 follower，跟随者，接收客户请求，想客户返回结果，在集群中也被称为slave。选举时参与投票。 observe，观察者，将请求转发给leader，不参与投票。 tip: 只要有leader 存在，就不进行选举 核心：ZAB (Zookeeper Atomic Broadcast, zookeeper原子广播，用于保证server同步) ZAB的两种工作模式： 恢复模式（选主） 广播模式（同步） zookeeper集群的配置： 提前在其配置文件中配置集群中机器的ip和端口 (这点很重要，不是自主发现，未配置的zk无法混入集群中) 选举前提： 半数可用机制（半数以上个zk服务器可用才执行选举

原文链接： http://www.studyshare.cn/software/details/1176/0 一、预备环境 Kafka是java生态圈中的一员，运行在java虚拟机上，按Kafka官方说明，java环境推荐Java8；Kafka需要Zookeeper保存集群的元数据信息和消费者信息。Kafka一般会自带Zookeeper，但是从稳定性考虑，应该使用单独的Zookeeper，而且构建Zookeeper集群。 jdk1.8下载安装教程： http://www.studyshare.cn/software/details/1143/0 zookeeper下载安装教程： http://www.studyshare.cn/software/details/1169/0 二、下载 官网下载： 下载地址 百度网盘： 下载地址 提取码：vow8 java开发工具下载地址及安装教程大全，点 这里 。 更多深度技术文章，在 这里 。 三、安装 1、将下载好的kafka安装文件上传至linux系统，可以使用ftp工具或者在窗口使用alt+p快捷键打开上传窗口。拖拽kafka文件上传。 2、解压 tar -zxvf kafka_2.11-2.3.0.tgz 3、移动到/usr/local/， 并改名kafka mv kafka_2.11-2.3.0 /usr/local/kafka 4

1.1. 一致性协议概述 前面已经讨论过，在分布式环境下，有很多不确定性因素，故障随时都回发生，也讲了 CAP 理论， BASE 理论 我们希望达到，在分布式环境下能搭建一个高可用的，且数据高一致性的服务，目标是这样，但 CAP 理论告诉我们要达到这样的理想环境是不可能的。这三者最多完全满足 2 个。 在这个前提下， P （分区容错性）是必然要满足的，因为毕竟是分布式，不能把所有的应用全放到一个服务器里面，这样服务器是吃不消的，而且也存在单点故障问题。 所以，只能从一致性和可用性中找平衡。 怎么个平衡法？在这种环境下出现了 BASE 理论： 即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性； BASE 由 Basically Avaliable 基本可用、 Soft state 软状态、 Eventually consistent 最终一致性组成，一句话概括就是：平时系统要求是基本可用，除开成功失败，运行有可容忍的延迟状态，但是，无论如何经过一段时间的延迟后系统最终必须达成数据是一致的。 其实可能发现不管是 CAP 理论，还是 BASE 理论，他们都是理论，这些理论是需要算法来实现的，今天讲的 2PC 、 3PC 、 Paxos 算法， ZAB 算法就是干这事情。 所以今天要讲的这些的前提一定是分布式，解决的问题全部都是在分布式环境下

一、Zookeeper的角色 » 领导者（leader），负责进行投票的发起和决议，更新系统状态 » 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票 » Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度 » 客户端（client），请求发起方 ObServer： Observers：在不伤害写性能的情况下扩展Zookeeper 尽管通过Client直接连接到Zookeeper集群的性能已经非常好了，但是这种架构如果要承受超大规模的Client，就必须增加Zookeeper集群的Server数量， 随着Server的增加，Zookeeper集群的写性能必定下降，我们知道Zookeeper的Znode变更是要过半数投票通过，随着机器的增加，由于网络消耗等原因 必然导致投票成本增加，从而导致写性能的下降。 Observer是一种新型的Zookeeper节点，可以帮助解决上述问题，提供Zookeeper的可扩展性。Observer不参与投票，只是简单的接收投票结果，因此我们 增加再多的Observer，也不会影响集群的写性能。除了这个差别

在虚拟机安装centos7，要提前安装好jdk环境 工作流程： 在 ZooKeeper 中管理多个 Broker 节点，根据 Master 选举策略让其中一个 Broker 选举为 Master （只有 Master 才具备对外提供服务的能力），剩下 Broker 为 slave 。 编码时， client 端（消费者）通过 failover 协议来连接 ActiveMQ 集群。 一、zookeeper 安装配置 服务端口 投票端口 选举端口 zk1 2181 2887 3887 zk2 2182 2888 3888 zk3 2183 2889 3889 在/Tools/zookeeper下复制3个zookeeper服务，并分别配置它们的文件conf/zoo.cfg: zk1. # /home/admin/Tools/zookeeper01 虚拟机zookeeper安装路径 dataDir=/home/admin/Tools/zookeeper0 1 /data dataLogDir=/home/admin/Tools/zookeeper0 1 /log #服务端口 clientPort=2181 # zk集群之间的通信地址 server.1= 192.168.23.129 :2887:3887 server.2= 192.168.23.129 :2888:3888 server

由于Hbase的非结构化特性，把她看成是一个存储系统比看成是数据库更加容易让人接受。 Hbase 是一个存储系统，不需要预定义很严格的矩阵结构，提供松散的组织数据的能力。而作为存储，她其实需要借助其他的文件系统支持，实际上并不一定限定于HDFS（在官方文档教程中，Hbase standalone 就是基于本地文件系统作为存储，也有厂商支持的较为稳定的Hbase + GPFS 的方案），只是因为来源于google 的Bigtable也是apache项目，因此两者结合有天然优势，支援也十分丰富。 本次测试的Hbase用的是官方推荐的稳定版本：hbase-1.4.10。 这个测试环境采用一种完全分布式 fully-distributed 部署方法（区别于 standalone 和 伪分布式部署），采用外部zookeeper，也就是和原来的hadoop 共用一套zookeeper。 （hbase程序包中实际上包含了zookeeper进程，可以启动一个独立的zookeeper去管理hbase，这里不采用这个方式） （1）创建系统用户并配置在集群之间的免密互访 为了管理的便利性，通过一个脚本start-hbase.sh 就启动其他几台机的进程，那么就需要配置免密码rsh于 host007, host003, host001,host002 上。 创建hbase用户：useradd -d

1. zookeeper的由来 　　Zookeeper 最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。 　　所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。 　　关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目)，雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家 Raghu Ramakrishnan 开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧，因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了。 　　而 Zookeeper 正好要用来进行分布式环境的协调，于是，Zookeeper 的名字也就由此诞生了。 2. zookeeper概览 　　ZooKeeper 是一个开源的分布式协调服务。ZooKeeper 框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 　　后来，Apache ZooKeeper 成为 Hadoop，HBase 和其他分布式框架使用的有组织服务的标准。 　

====================================== ZooKeeper 背景 ====================================== ZooKeeper 是一个非常优秀的开源项目, 可以为软件系统提供非常重要的基础特性: 1. 分布式锁. 使用场景有: 比如我们有一套系统, 为了保证HA, 在多台需要在多台服务器上部署, 该服务程序有一些定时任务需要执行, 我们需要确保同一个定时任务不会在多台机器上被同时执行. 分布式锁可以使用 redis/RDBMS实现, 但都不如 ZooKeeper 更适合. 2. 比如要开发一套Master-Slave集群系统, Leader选举是必需的. 3. 服务发现. 在服务发现场景中, 我更推荐 consul. ZooKeeper 数据结构 zk 提供类似于文件系统命名空间(name space), 我们可以采用路径的方式创建节点, 在节点上可以保存业务数据(2MB字节), 节点除了保存业务数据外, ZooKeeper还保存着版本号/时间戳等信息. 节点分为: 永久节点: 创建后一直保存着, 除非被删除 临时节点: 创建节点的会话存在, 节点就存在, 会话一旦结束, 节点就被删除. 顺序节点: 创建节点的时候, 自动为节点增加一个序列号, 多个客户端创建同一个节点, 序列号自增. 另外, zk