ZooKeeper 配置演练：分步指南，打造健壮可靠的集群 (zookeeper)

ZooKeeper 是一个分布式协调服务，在分布式系统中扮演着至关重要的角色。在本文中，我们将循序渐进地指导您配置一个健壮可靠的 ZooKeeper 群集，以满足您特定的需求。

步骤 1：安装 ZooKeeper

• 从 Apache ZooKeeper 网站下载最新的稳定版本。
• 解压缩下载的文件到您选择的目录中，例如 /usr/local/zookeeper 。
• 将 ZooKeeper 添加到您的 PATH 环境变量中，以便您可以从任何位置访问 zookeeper 命令。

步骤 2：创建配置文件

• 在 ZooKeeper安装目录中创建一个名为 conf/zoo.cfg 的配置文件。
• 将以下内容添加到配置文件中：

tickTime=2000 initLimit=10 syncLimit=5 dataDir=/var/lib/zookeeper clientPort=2181

• tickTime ：ZooKeeper 服务器之间同步的时间间隔（以毫秒为单位）。
• initLimit ：Leader 选举期间服务器等待接收过半数 quorum 确认的时间限制（以 ticks 为单位）。
• syncLimit ：Leader 超时并启动新的选举前等待过半数 quorum 确认的时间限制（以 ticks 为单位）。
• dataDir ：存储 ZooKeeper 数据的目录。
• clientPort ：ZooKeeper 客户端连接的端口。

步骤 3：创建 MyID 文件

• 在 ZooKeeper 安装目录中的 dataDir 中创建一个名为 myid 的文件。
• 将每个 ZooKeeper 服务器的唯一 ID 写入文件。服务器 ID 应介于 1 到集群中的服务器数量之间。

步骤 4：启动 ZooKeeper 服务器

• 导航到 ZooKeeper 安装目录。
• 对于每个 ZooKeeper 服务器，运行以下命令：

zookeeper-server start conf/zoo.cfg

步骤 5：验证集群

• 使用以下命令连接到 ZooKeeper 服务器：

zookeeper-cli

• 输入以下命令以验证集群状态：

ls /

• 您应该看到集群中所有服务器的列表。

步骤 6：配置客户端

• 在您的应用程序中，使用以下格式配置 ZooKeeper 客户端：

zookeeperConnectionString = "server1:2181,server2:2181,..."

• server1 、 server2 等是 ZooKeeper 服务器的主机名或 IP 地址。
• 2181 是 ZooKeeper 客户端端口。

高级配置

• Quorum 投票：ZooKeeper 依靠 quorum 协议来保持一致性。您可以在 zoo.cfg 文件中配置 quorum 投票，方法是设置 quorumSize 和 electionAlg 参数。
• 快照频率：ZooKeeper 可以定期创建集群状态的快照。您可以在 zoo.cfg 文件中配置快照频率，方法是设置 autopurge.snapRetainCount 参数。
• 事务日志大小：ZooKeeper 在内存中维护一个事务日志。您可以通过在 zoo.cfg 文件中设置 autopurge.purgeInterval 参数来配置日志大小。

故障排除

• Leader 选举超时：如果 Leader 选举过程超时，请检查 initLimit 和 syncLimit 参数是否设置得太低。
• 服务器断开连接：如果服务器断开连接，请检查网络连接和防火墙配置。
• 数据丢失：如果数据丢失，请检查快照配置和事务日志大小。

结论

通过遵循本文中的步骤，您已经配置了一个健壮可靠的 ZooKeeper 群集，它将为您的分布式系统提供坚实的基础。记得根据您的特定需求定制配置，并定期监控集群以确保其正常运行。通过仔细规划和实施，您可以创建一个在各种情况下都能保持高可用性和一致性的 ZooKeeper 群集。

---

【Zookeeper系列】基本介绍

在学习一样技术之前，咱们需要先想一下，为什么需要学这一门技术？

许多分布式系统都是基于ZK作为底层核心组件对外提供服务，比如Kafka中，将Broker注册到ZK中，此时ZK充当着多重角色，比如注册中心、选举等；再比如说，我公司目前很多项目都是Dubbo，都是需要基于ZK实现服务发现和注册。

另外，ZK内其实也有很多优秀的算法和设计思想，熟悉ZK源码，也可以提升自己的“内功”。

如何快速入门Zookeeper呢？最简单的方式就是直接看Zookeeper官网啦！建议读者多参考官方文档和博客内容一起食用，效果更佳噢～

Zookeeper的 Logo 看起来就像个“铲屎官”，服务动物园内的动物们。

“A Distributed Coordination Service for Distributed Applications”，这是摘取官方的解释，我们可以得知Zookeeper 是一个为 分布式框架 提供协调服务的东东。

举些例子，有哪些分布式框架使用Zookeeper：

ZK的作用不止上面几个，其实还可以做到负载均衡、统一配置、分布式队列等，但使用场景相对少，企业级系统中，会使用其他更加专业的框架组件。

分布式锁、注册中心、Leader选举将会是ZK系列中，重点分享的内容，敬请期待哈~

在ZK中，需要先了解一些专业名词的概念，但不会一下子都列出来，当之后遇到的时候，再重点分析...

在ZK集群中，会分为 Leader 、 Follower 和 Observer 角色。

Leader作为集群的大佬，承担写请求和部分读请求；Follower作为Leader的小弟，将会承担部分读请求，当接收到写请求的时候会转发给Leader，由Leader处理写请求；Observer就有点特殊，Observer节点不参与选举和消息过半机制，这个不清楚的读者可以暂时有个记忆就行，之后遇到会重点说明。

实际上，节点只分为持久节点和临时节点，但有些场景需要保证顺序，所以就会在持久或临时节点的基础上，添加序号（递增的方式），形成持久顺序节点和临时顺序节点。</br> 那么什么是持久节点，什么是临时节点呢？最直观的一个现象就是，每个ZK客户端连接ZK集群后，都会产生一个节点，如果ZK客户端下线后，节点还存在的就是持久节点，若ZK客户端下线后节点也随着消失，那么该节点就是临时节点。

在ZK客户端启动前，可以自定义监听回调函数，这个有什么作用呢？客户端启动后会将监听事件发送给Zookeeper集群，Zookeeper集群中有一个用于记录监听事件的列表，当客户端监听的目录节点发生变化，如节点数据变更、节点增删等，就会通过ZK集群的监听列表，找到对应的客户端回调监听函数，那么客户端这边就可以根据业务场景，做出相应的动作。

ZAB协议的全称是：ZooKeeper Atomic Broadcast。ZAB是Zookeeper保证数据一致性的核心算法。借鉴了Paxos算法的思想，特地为Zookeeper设计的支持崩溃恢复的原子广播协议。其包括两种基本模式： 消息广播 和 崩溃恢复

消息广播指的是，集群中只有一个Leader处理写请求，并将写请求的事件广播给所有Follower，且能够保证数据不丢失。（也就是说，消息的写入是原子性的，因为只能有leader写入）

崩溃恢复指的是，当ZK集群刚启动还没选举出Leader或Leader因故障、重启、网络等原因的时候，ZAB协议会进入崩溃恢复模式，其目的就是为了选举新的Leader，且保证新Leader的数据是最新的，这样就能够避免因为Leader故障而导致单点丢失消息的情况，至于ZAB具体的原理，各位可以先看下以下参考文章，后续有机会我再专门写一篇关于 ZAB 协议的文章~

ZAB 协议参考文章

ZK内的数据模型结构和Unix文件系统非常相似，是一个有层级关系的树形数据结构。在ZK内，树形的数据结构使用称为ZNode节点保存数据，ZNode是ZK中数据结构最小单元，不仅能够保存数据，还能挂载子节点，形成一个有层次关系的树。

值得注意的是，ZNode的创建是纯内存操作的，所以速度很快，然后在ZK内部会定期将ZNode的数据持久化到磁盘上。

众所周知，在实际的企业应用，面对高并发的场景下，肯定是不能单节点部署，而是通过集群部署保证 高并发、高性能、高可用 （简称三高）。

高性能 ：由于ZNode节点是纯内存操作，只要ZK部署在高配置的服务器中，三台ZK服务器抗住每秒几万的请求都是没问题的。 高可用 ：只要部署奇数的服务器集群（比如3台、5台、11台机器），只要不超过一半的服务器宕机，都能保证ZK集群可用。 高并发 ：因为ZNode是纯内存操作，所以在写数据的时候，速度是很快；而ZK集群中Leader和Follower节点都能处理读请求，所以ZK集群高并发能力是很强的。

基于ZAB协议，写请求统一由Leader服务器处理，然后由Leader将写数据的请求广播给其他Follower。

但会不会由于种种原因，如网络波动、Leader脑裂、Follower宕机等，导致消息不一致？

实际上，在ZK中采用2PC两阶段提交的思想，结合ZAB消息广播保证数据一致性。值得注意的是，Zookeeper只能保证最终一致性，并不能保证强一致性

那么具体是怎么保证数据最终一致性的呢？感兴趣的读者可以看下我另外一篇拙作【TODO...】

参考资料：

《从Paxos到Zookeeper分布式一致性原理与实践》

如果觉得文章不错的话，麻烦点个赞哈，你的鼓励就是我的动力！对于文章有哪里不清楚或者有误的地方，欢迎在评论区留言~

ZooKeeper 的功能和原理初探

在公司核心系统的开发过程中用到了ZooKeeper，简称zk，用于搭建分布式核心环境，开发过程中也经常会遇到zk出现的问题，看了几篇博客了解和总结一下zk的基本原理。 ZooKeeper主要有几个重要的概念，简单总结下： ZooKeeper中主要有三种角色：Leader、Follower、Observer 一个 ZooKeeper 集群同一时刻只会有一个 Leader，其他都是 Follower 或 Observer。 ZooKeeper 集群的所有机器通过一个 Leader 选举过程来选定一台被称为『Leader』的机器，Leader服务器为客户端提供读和写服务。 Follower 和 Observer 都能提供读服务，不能提供写服务。 两者唯一的区别在于，Observer机器不参与 Leader 选举过程，也不参与写操作的『过半写成功』策略，因此 Observer 可以在不影响写性能的情况下提升集群的读性能。 每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。 Session 是指客户端会话。 在ZooKeeper 中，一个客户端连接是指客户端和 ZooKeeper 服务器之间的TCP长连接。 ZooKeeper 对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的 Watch 事件通知。 Session 的 SessionTimeout 值用来设置一个客户端会话的超时时间。 当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。 zookeeper的结构其实就是一个树形结构，leader就相当于其中的根结点，其它节点就相当于follow节点，每个节点都保留自己的内容。 zookeeper的节点分两类： 持久节点 和 临时节点 持久节点：所谓持久节点是指一旦这个 树形结构上被创建了，除非主动进行对树节点的移除操作，否则这个 节点将一直保存在 ZooKeeper 上。 临时节点：临时节点的生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。 有四种类型的znode： 1、PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后，该节点依旧存在 2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 3、EPHEMERAL-临时目录节点 客户端与zookeeper断开连接后，该节点被删除 4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 每个 节点除了存储数据内容之外，还存储了 节点本身的一些状态信息。 用 get 命令可以同时获得某个 节点的内容和状态信息 在 ZooKeeper 中，version 属性是用来实现乐观锁机制中的『写入校验』的（保证分布式数据原子性操作）。 Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。 实现这个机制的协议叫做Zab协议。 Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。 状态同步保证了leader和Server具有相同的系统状态。 在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。 一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。 对应每一个事务请求，为了保证事务的顺序一致性，ZooKeeper都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。 每一个 ZXID对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序。 ZooKeeper允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去。 该机制是 ZooKeeper 实现分布式协调服务的重要特性。

ZooKeeper简介与协议

ZooKeeper 是一个开放源码的分布式协调服务，提供类似UNIX文件系统、通知机制 分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能，另一篇文章介绍 Zookeeper 提供一个多层级的节点命名空间（节点称为 znode）。 与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。 Zookeeper 为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得 Zookeeper 不能用于存放大量的数据，每个节点的存放数据上限为1M。 （1）PERSISTENT-持久节点 除非手动删除，否则节点一直存在于 Zookeeper 上 （2）EPHEMERAL-临时节点 临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。 （3）PERSISTENT_SEQUENTIAL-持久顺序节点 基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。 （4）EPHEMERAL_SEQUENTIAL-临时顺序节点 基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。 Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。 工作过程： watcher的特点： 注意事项： Zookeeper选择了CAP理论中的CP zookeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务，这个时候就说明了服务不可用，但是在选举成功之后，因为一主多从的结构，zookeeper在这时还是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性 服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。 （1）LOOKING：寻 找 Leader 状态。 当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。 （2）FOLLOWING：跟随者状态。 表明当前服务器角色是 Follower。 （3）LEADING：领导者状态。 表明当前服务器角色是 Leader。 （4）OBSERVING：观察者状态。 表明当前服务器角色是 Observer。 ZAB 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。 基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。 ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。 消息广播主要用于集群之间的数据同步，采用类似分布式事务中的2PC协议： （1）Leader将客户端的request转化成一个Proposal（提议） （2）Leader为每一个Follower准备了一个FIFO队列，并把Proposal发送到队列上。 ‘ （3）leader若收到follower的半数以上ACK反馈 （4）Leader向所有的follower发送commit。 当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader 服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式 为了保证事务的顺序一致性,zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal（提议）都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是 epoch（ 时期; 纪元; 世; 新时代）用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增，低 32 位用来递增计数事务。 当选举出Leader后，该Leader具有全局最大的ZXID，所以同步阶段的工作就是根据Leader的事务日志对Follower节点进行数据同步：

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！