zookeeper集群

一、 ZooKeeper 简介 顾名思义 zookeeper 就是动物园管理员，他是用来管 hadoop（大象）、Hive(蜜蜂)、pig(小 猪)的管理员， Apache Hbase 和 Apache Solr 的分布式集群都用到了 zookeeper；Zookeeper: 是一个分布式的、开源的程序协调服务，是 hadoop 项目下的一个子项目。他提供的主要功 能包括：配置管理、名字服务、分布式锁、集群管理。 二、 ZooKeeper 的作用 1.1 配置管理 在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都 是使用配置文件的方式，在代码中引入这些配置文件。当我们只有一种配置，只有一台服务 器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多， 有很多服务器都需要这个配置，这时使用配置文件就不是个好主意了。这个时候往往需要寻 找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的 都可以获得变更。Zookeeper 就是这种服务，它使用 Zab 这种一致性协议来提供一致性。现 在有很多开源项目使用 Zookeeper 来维护配置，比如在 HBase 中，客户端就是连接一个 Zookeeper，获得必要的 HBase 集群的配置信息，然后才可以进一步操作。还有在开源的消 息队列 Kafka 中，也使用

接着上篇 选举流程 。当zk选举成功后，zk会进行(Leader-Follower)数据同步，数据同步成功后，整个集群才开始正常运作。这篇我们就来分析下数据同步流程。 首先我们还是回到org.apache.zookeeper.server.quorum.QuorumPeer的run方法为主入口 @Override public void run ( ) { // ....省略一些无关紧要的代码 try { /* * 主循环 */ while ( running ) { switch ( getPeerState ( ) ) { // 根据zk的状态，执行对应的逻辑 case LOOKING : // LOOKING，会触发选举逻辑，这个我们上篇已经说过了。 LOG . info ( "LOOKING" ) ; // ... 省略一些无关紧要的代码 /* * 当选举结束后。 * 会然后break跳出switch，然后会继续循环，根据选举后的状态 * 执行对应角色的逻辑 */ break ; case OBSERVING : // OBSERVING，Observer需要执行的逻辑。我们主要说Leader、Follower // ... 省略一些无关紧要的代码 break ; case FOLLOWING : // FOLLOWING，Follower需要执行的逻辑 try { LOG

这可能是把ZooKeeper概念讲的最清楚的一篇文章 相信大家对 ZooKeeper 应该不算陌生，但是你真的了解 ZooKeeper 是什么吗？如果别人/面试官让你讲讲 ZooKeeper 是什么，你能回答到哪个地步呢？ 作者：SnailClimb来源： 51CTO技术栈 |2018-09-12 09:34 收藏 分享 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心，另外在搭建 Solr 集群的时候，我使用到了 ZooKeeper 作为 Solr 集群的管理工具。 前几天，总结项目经验的时候，我突然问自己 ZooKeeper 到底是个什么东西？ 想了半天，脑海中只是简单的能浮现出几句话： Zookeeper 可以被用作注册中心。 Zookeeper 是 Hadoop 生态系统的一员。 构建 Zookeeper 集群的时候，使用的服务器最好是奇数台。 可见，我对于 Zookeeper 的理解仅仅是停留在了表面。所以，通过本文，希望带大家稍微详细的了解一下 ZooKeeper 。 如果没有学过 ZooKeeper，那么本文将会是你进入 ZooKeeper 大门的垫脚砖；如果你已经接触过 ZooKeeper ，那么本文将带你回顾一下 ZooKeeper 的一些基础概念。 最后，本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及

1、zookeeper一致性原理 一致性概念：强一致性、弱一致性、最终一致性 为了保证主从节点的数据一致性，Zookeeper 采用了 ZAB 协议 ，这种协议非常类似于一致性算法 Paxos 和 Raft 什么是 ZAB Zookeeper Atomic Broadcast，有效解决了 Zookeeper 集群崩溃恢复，以及主从同步数据的问题。 # ZAB 协议定义的三种节点状态 Looking ：选举状态。 Following ：Follower 节点（从节点）所处的状态。 Leading ：Leader 节点（主节点）所处状态。 # 最大 ZXID 最大 ZXID 也就是节点本地的最新事务编号，包含 epoch 和计数两部分。epoch 是纪元的意思，相当于 Raft 算法选主时候的 term。 # ZAB 的崩溃恢复 假如 Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复。ZAB 的崩溃恢复分成三个阶段： Leader election 选举阶段，此时集群中的节点处于 Looking 状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器 ID 和最新事务 ID（ZXID）。 接下来，节点会用自身的 ZXID 和从其他节点接收到的 ZXID 做比较，如果发现别人家的 ZXID 比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的 ZXID

在进行kafka集群搭建前需要准备环境： 1.jdk的本版 jdk8(zk,kafka官网文档有要求) 2.kafka版本kafka_2.12-2.4.0 ( 如果为其他本版，请查看对应的libs下对应的 zk的版本，本版不一致可能会导致环境问题 ) 3.zk版本 zookeeper-3.5.6（源码方式，不喜欢看的绕过，麻烦尊重一下文章发表者，毕竟你要是撸出来了也就用不着看这个文章；不足之处敬请指正待后续更改） 4.maven环境(zookeeper-3.5.6使用，打包一下，不然启动不了;maven镜像设置， 报错解决办法文中有描述 ，此文超长超臭，请原谅我这个中文占五渣的！！！！！！) 5.虚拟机上建的服务器列表规划(本文只用三个，集群可参考zk官网) #####################001软件版本(部分去掉前缀)##################### [root@localhost apps]# ll 总用量 189612 drwxr-xr-x. 6 root root 99 1月 18 08:03 apache-maven-3.6.3 drwxr-xr-x. 7 10 143 245 10月 5 06:13 jdk1.8.0_231 -rw-r--r--. 1 root root 194151339 1月 12 03:17 jdk-8u231-linux

　　在第一篇 读书笔记 中，了解到了 Service Registry ，它是整个“微服务架构”中的核心，不仅提供了 Service Registry（服务注册）功能，同时也为 Service Discovery （服务发现）提供了支持。 　　 服务注册 ，指的是在服务启动后，将服务的相关配置信息注册到服务注册表中。 　　 服务发现 ，可以理解为当客户调用这些服务时，将通过 Service GateWay （服务网关）从服务注册表中获取这些服务配置，然后通过反向代理的方式去调用具体的服务接口，从服务注册表中获取服务配置的过程。 　　同时，服务注册表会定期检查已经注册的服务，若发现某服务无法访问了，将其从服务注册表中移除掉，这种定期检测的过程叫作 “心跳检测” 。因此，服务注册表对 “分布式数据一致性” 的要求相当高，即，服务注册表中的服务配置一旦变更了，通知机制必须要做到高性能，且服务注册表本身还需要具备高可用。 　　那么，谁才能担当服务注册表的重任呢？我们认为 ZooKeeper 是服务注册表的最近解决方案之一。 目标 ： 认识 ZooKeeper，并学会使用 Zookeeper，最后基于 ZooKeeper 实现服务注册表的核心功能，同时，我们将使用 Node.js 搭建一个高可用的服务网关。 1. 什么是 ZooKeeper（What） 　　ZooKeeper

当你安装好 Zookeeper 集群后，迫不及待的用启动命令 zkServer.sh start 启动集群，用命令 zkServer.sh status 查看集群状态时，看到集群正常启动并运行，心里是不是美滋滋，不过当你查看安装目录时，可以看到在你运行启动命令的目录里，生成了 zookeeper.out 日志文件，心情一下就不爽了。 那么问题来了，这个目录是否可以自定义设置呢？答案当然是可以的，需要修改两个文件。 修改 ZK_HOME/conf/log4j.properties 文件： 注释掉的是原有路径，下方修改了本地路径。当前前提是 logs 目录自己已经创建。 本以为这样修改后，启动集群，日志就可以放到对应文件夹，可结果还是和修改前一样无变化，日志还是在运行启动命令的目录，所以还需要修改一个脚本配置。 修改 ZK_HOME/bin/zkEnv.sh 文件： 修改后再次启动集群，可以看到日志已经生成到了自定义文件目录，在运行启动命令的目录再没有日志文件生成。 当然，修改上面的配置文件是在一个节点机器上修改的，修改后别忘了把文件同步到 Zookeeper 集群的其它节点机器上。 来源： CSDN 作者： 计算机视觉小白之旅 链接： https://blog.csdn.net/qq_34246778/article/details/103915016

zookeeper原理 角色划分 客户端（client） 服务端（server）：领导者（leader，可读可写可监听）+追随者（follower，可读可监听）+观察者（observer，不参与选举投票和提议投票，可读可监听） zookeeper server状态 LOOKING：正在选举leader LEADING：当前节点就是leader FOLLOWING：当前节点是follower OBSERVING：当前节点是observer leader发送给follower消息类型 PING：心跳消息 PROPOSAL：发起提议消息 COMMIT：提交提议消息 follower发送给leader消息类型 PING：心跳消息 REQUEST：请求消息（转发写请求） ACK：确认提议消息 znode znode大小限制：1MB znode删除限制：如果znode有子节点，则无法删除它 znode类型 PERSISTENT：持久化目录节点 PERSISTENT_SEQUENTIAL：持久化顺序目录节点 EPHEMERAL：临时目录节点 EPHEMERAL_SEQUENTIAL：临时顺序目录节点 zab协议 zab协议包含恢复模式和广播模式。 集群启动、leader崩溃、leader重启或leader失去多数follower时进入恢复模式，恢复模式完成后进入广播模式。 恢复模式

本文转发自 技术世界 ， 原文链接 　 http://www.jasongj.com/2015/01/02/Kafka深度解析 背景介绍 Kafka简介 　　Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输 同时支持离线数据处理和实时数据处理 为什么要用消息系统 解耦 在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束 冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。 扩展性 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的

1.ZooKeeper 面试题？ ZooKeeper 是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。 Zookeeper 保证了如下分布式一致性特性： 顺序一致性 原子性 单一视图 可靠性 实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求，这些请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功。因此，随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。 有序性是 zookeeper 中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为 zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper 最新的 zxid。 2. ZooKeeper 提供了什么？ 文件系统 通知机制 3. Zookeeper