ZooKeeper 配置优化指南：提高性能、可靠性和可用性 (zookeeper)

ZooKeeper 是一款分布式协调框架，广泛用于在分布式系统中提供协调和配置管理。优化 ZooKeeper 配置对于确保高性能、可靠性和可用性至关重要。本文将提供一个全面的指南，介绍如何优化 ZooKeeper 配置以获得最佳结果。

性能优化

tickTime 和 initLimittickTime: 控制 ZooKeeper 状态更新的频率。较低的值会导致更频繁的更新，从而提高性能，但也可能增加开销。对于大多数应用程序，建议将 tickTime 设置为 2000 到 5000 毫秒。initLimit: 控制 ZooKeeper 允许服务器之间进行会话的次数。较高的值允许更多会话，从而提高并发性，但也可能导致性能问题。建议将 initLimit 设置为 10 到 20。syncLimitsyncLimit: 控制 ZooKeeper 每台服务器更新其磁盘快照的频率。较高的值会导致更频繁的同步，从而提高故障转移速度，但也可能影响性能。对于大多数应用程序，建议将 syncLimit 设置为 10 到 20。maxClientCnxnsmaxClientCnxns: 控制每台 ZooKeeper 服务器允许的最大客户端连接数。较高的值允许更多客户端连接，但可能导致资源争用。对于大多数应用程序，建议将 maxClientCnxns 设置为 1000 到 2000。

可靠性优化

dataDirdataDir: 指定 ZooKeeper 存储其数据的目录。建议将 dataDir 设置为专用磁盘或 SSD，以确保数据完整性和快速访问。transactionLogDirtransactionLogDir: 指定 ZooKeeper 存储其事务日志的目录。与 dataDir 相同，建议将 transactionLogDir 设置为专用磁盘或 SSD。tickTime 和 initLimit在可靠性方面，tickTime 和 initLimit 的设置也至关重要。较低的 tickTime 值和较高的 initLimit 值可以提高故障转移速度，从而在服务器故障时减少数据丢失的风险。autopurge.snapRetainCountautopurge.snapRetainCount: 控制 ZooKeeper 保留的事务日志快照的数量。较高的值可以减少数据丢失的可能性，但也会占用更多磁盘空间。对于大多数应用程序，建议将 autopurge.snapRetainCount 设置为 3 到 5。

可用性优化

ensembleSizeensembleSize: 指定 ZooKeeper 集群中服务器的数量。偶数的 ensembleSize（例如，2、4、6）提供更好的可用性，因为在发生故障时，集群仍可以正常工作。clientPortclientPort: 指定 ZooKeeper 服务器公开的客户端端口。建议将 clientPort 设置为一个已知端口，例如 2181，以便客户端可以轻松连接到集群。leaderServesleaderServes: 控制当 ZooKeeper 领导者服务器可用时，集群是否应该允许客户端连接到领导者。将 leaderServes 设置为 true 可以提高可用性，因为客户端可以在领导者可用时直接连接到它。followerForwardingfollowerForwarding: 控制当领导者服务器不可用时，集群是否应该允许客户端连接到从属服务器。将 followerForwarding 设置为 true 可以提高可用性，因为客户端可以在领导者不可用的情况下仍能够与从属服务器进行交互。

其他优化技巧

启用 SSL/TLS: 启用 SSL/TLS 加密可以保护客户端和服务器之间的通信，从而提高安全性。使用 JMX 监控: 启用 JMX 监控可以让你密切监视 ZooKeeper 集群的性能和健康状况。进行基准测试和调整: 定期进行基准测试和调整 ZooKeeper 配置以满足特定应用程序的需求非常重要。升级到最新版本: 保持 ZooKeeper 软件的最新版本对于获得最新功能和错误修复至关重要。

结论

通过优化 ZooKeeper 配置，你可以显着提高其性能、可靠性和可用性。通过遵循本指南中给出的建议，你可以确保你的 ZooKeeper 集群以最佳状态运行，从而支持你的分布式系统的高效和可靠运营。

---

zookeeper主流应用场景有哪些

zookeeper主流应用场景有：数据同步，配置管理。

1、数据同步

ZooKeeper可以帮助分布式应用程序实现数据同步功能。例如，在一个分布式系统中，多个节点需要对同一份数据进行读写操作，那么可以使用ZooKeeper来实现数据的协调和同步。

2、配置管理

ZooKeeper还可以用于实现配置管理功能。例如，在一个分布式系统中，多个节点需要共享同一份配置信息，那么可以使用ZooKeeper来存储和更新配置信息，并且可以通过监视机制及时通知其他节点更新。

ZooKeeper的特性：

1、高可用性，ZooKeeper使用了分布式存储和多副本机制来确保高可用性。当一个节点出现故障时，其他节点会自动接管其工作，从而保证系统的运行不受影响。此外，ZooKeeper还提供了基于Paxos算法的Leader选举机制，确保在任何时候都有一个可用的Leader节点来处理客户端请求。

2、可靠性，ZooKeeper使用了事务和版本号机制来确保数据的可靠性。在写入数据时，ZooKeeper会为每次写操作生成一个唯一的事务ID，并记录该事务ID的版本号。

当其他节点读取该数据时，ZooKeeper会比较版本号，如果发现版本不一致，则说明该数据已经被修改过，需要重新获取最新的数据。

以上内容参考：网络百科-zookeeper

客户端的Watcher

String就是节点的path，有三大类。 dataWatches：数据watcher existWatches：节点是否存在的watcher childWatches：节点的子节点个数变化，包括：0->1，1->2等等，只要数量变化就触发。

对于zk的watcher机制，有几个疑问？

三、ZK的通信协议 分两类：请求和响应协议。是基于TCP/IP的应用层协议，其实就是规定了应用层报文的格式，以及每个字段的含义。客户端和服务端双方都遵守这种约定，脱离了ZK，其他框架是无法识别这种通信协议的。

请求和响应报文格式，网上搜一下一大堆。这里不再赘述

那么回到什么是分布式协调呢？我们就以RPC这种场景来说： 比如我们可以理解上面的图，一半client是service角色，一半client是consumer角色，然后zk提供了这些client之间的协调 -- 充当consumer角色的client必须依赖于充当service角色提供的服务，这可不就是分布式协调的一种嘛（协调其中一半的client依赖另一半）。当然我们可以继续扩展：分布式配置中心Disconf，有个client它的角色可以是管理员(配置员)，它是一个进程。它向zk某一个节点配置了XX数据，然后其他所有client同时收到最新配置。这可不就是另外一种协调了嘛（其他client依赖这个配置的值执行业务）。

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能

乍一看这个定义挺抽象的，一时半会没理解。其实举个例子就容易理解的多，比如你有个资源，我们先简单把该资源当做一个本地文件或本地电影。你为了保证该资源的可靠性，你需要把该资源copy到3台机器上。那么这三个资源，在互联网上就会有三个url地址：机器1/xxx/xxx/，机器2/xxx/xxx/，机器3/xxx/xxx/。请求方为了访问该资源，肯定不会把这三个地址硬编码到自己本地，这样不易拓展。所以这个时候，就需要一个统一命名服务来封装该资源的三个真实地址，对外只提供一个地址并且永远可以不变。那么这个统一命名服务，我们当然可以用http协议来实现，也可以用zk协议(ZAB协议)来实现。 现在理解了上面的内容，那么我们就容易拓展这个资源的定义了。上面所说的资源，我们可以拓展为一个服务 ，该服务的提供方可以有很多个，但是为了封装真实提供方，我们只能对外暴露一个地址那就是。是不是很熟悉？Dubbo的ZK注册中心，就是这么干的。

理解定义我们就不说了，这个很好理解。实际案例咱们可以参考Dubbo的ZK，提供者发布或修改服务真实地址后，消费者可以实时收到变化的通知，然后再去ZK拉取最新数据。这可不就是ZK的发布与订阅嘛，通过Listener观察者模式来实现。应用场景很多：RPC服务发现，配置中心的配置分发等等。

所谓集群管理无在乎两点：是否有机器退出和加入、选举 Master。 不就是ZK的发布订阅嘛，没啥好说的。

这里的maser选举，可不是ZK内部的master选举（两者相差十万八千里）。这里的master选举，是指业务调用方，属于client角色的进程，进行选举。 业务master选举其实很简单，完全没必要像ZK内部选举那样，还要实现一套可靠的选举算法(paxos算法包含了一个提案选举，paxos算法可不止一个选举算法)。ZK本身提供了一个可靠创建唯一节点的API接口，这个接口保证了并发调用只会有一个成功。那么业务master选举，是不是可以转化为多个业务进程并发调用该API接口，谁创建唯一节点成功了，谁就是master了，其他进程就是slave。怎么感觉这么像分布式锁的实现呢？除了少了释放锁的通知操作。。。

软负载均衡也没啥好说的，就是注册与发现的变种，或者说发布与订阅的变种。获取统一命名服务的所有提供者列表，然后通过负载均衡算法在这一堆列表中选择一个，策略可以是随机选择，轮训选择，Hash一致性选择等等。。。Dubbo的负债均衡是实现在消费者调用逻辑里面的，并不在获取列表接口里面，ZK不做负载均衡，基于ZK的应用可以做。

和上面的数据发布与订阅 一模一样 ，不在赘述。

和上面说的Master选举很像，都是一堆client角色的业务调用方，调用创建某唯一节点的API。谁创建成功，谁就拿锁。只不过ZK的底层实现是严格按照顺序来的，所以必然是ZK接收请求的时候，谁第一个谁拿锁。注意可不是client谁先请求谁拿锁。client请求还要经过网络，同时请求是没法确定哪个client先到达的。 但是光创建唯一节点成功还不叫锁，锁天然包含了两个功能：可重入和释放锁唤醒其他等待的client节点。可重入ZK是实现不了，需要业务方自己实现。释放锁的唤醒ZK是通过Listener的通知唤醒的。

我们看下上面的所有应用场景，其实本质上都是调用zk的两个最核心的接口：创建节点和监听节点变化。

ZooKeeper 将数据保存在内存中，这也就保证了高吞吐量和低延迟 （但是内存限制了能够存储的容量不太大，此限制也是保持 znode 中存储的数据量较小的进一步原因）。ZK集群加机器可不能增加内存，为啥呢？因为ZK集群里面的所有数据，都是每台机器保存一份副本。整个集群内存最小的机器，决定整个集群的内存大小。

ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其的高性能 ，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）

ZooKeeper 底层其实只提供了两个功能：

Zookeeper原理解析

微信公众号: Spark大数据一、Zookeeper介绍 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务： 分布式锁服务 。 分布式应用可以基于它实现更高级的服务，实现诸如同步服务、配置维护和集群管理或者命名的服务。 Zookeeper服务自身组成一个集群，2n+1个（奇数）服务允许n个失效，集群内一半以上机器可用，Zookeeper就可用。 假设 3台机器组成的集群，可以有允许一台失效，如果有2台失效，这个集群就不可用，1<1.5，一般的搭建zookeeper集群时，以奇数台机器来搭建。 目的：是为了提高容错能允许多损失一台。 1.1 数据模型 1）ZooKeeper本质上是一个 分布式的小文件存储系统 ； 2）Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点）， 每个节点可以存少量的数据（1M左右） 。 3）每个节点称做一个ZNode。 每个ZNode都可以通过其路径唯一标识 。 4）ZooKeeper中的 每个节点存储的数据要被原子性的操作 。 也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。 5）在zookeeper创建顺序节点（create -s ），节点路径后加编号，这个计数对于此节点的父节点来说是唯一的。 /app/ /s1 /s2 6）ZooKeeper中的节点有两种，分别为 临时节点和永久节点 。 节点的类型在创建时即被确定，并且不能改变。 ① 临时节点 ：在客户端用create -e创建，该节点的生命周期依赖于创建它们的会话。 一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。 虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。 另外，**ZooKeeper的临时节点不允许拥有子节点。 ② 永久节点 ：在客户端用create 创建，该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。 7） 客户端可以给节点设置watch，我们称之为监视器 。 当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。 当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知。 分布式锁 zookeeper 是高可用协调流程图1.2 zookeepr角色介绍 领导者（leader） ，负责进行投票的发起和决议，更新系统状态（数据同步），发送心跳。 学习者（learner） ，包括跟随者（follower）和观察者（observer）。 跟随者（follower） ，用于接受客户端请求、向客户端返回结果，在选主过程中参与投票。 观察者（Observer） ，可以接受客户端请求，会把请求转发给leader， 但observer不参加投票过程，只同步leader的状态 ，observer的目的是为了扩展系统，提高读取速度。 1）leader失效后会在follower中重新选举新的leader 2）每个follower都和leader有连接，接受leader的数据更新操作 3）客户端可以连接到每个server，每个server的数据完全相同 4）每个节点的服务Server，记录事务日志和快照到持久存储1.3 工作原理 Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。 实现这个机制的协议叫做Zab协议。 Zab协议有两种模式 ，它们分别是恢复模式（选主）和广播模式（同步）。 恢复模式： 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，恢复模式不接受客户端请求，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。 状态同步保证了leader和Server具有相同的系统状态。 广播模式： 一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。 这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。 待到同步结束，它也参与消息广播。 ZooKeeper的广播状态一直到Leader崩溃了或者Leader失去了大部分的Followers支持。 1.4 Zookeeper节点数据操作流程(1）写操作 1）在Client向Follwer 或 Observer 发出一个写的请求； 2）Follwer 或 Observer 把请求发送给Leader； 3）Leader接收到以后向所有follower发起提案； 4）Follwer收到提案后执行写操作，然后把操作结果发送给Leader； 5）当多数follower返回提案结果后，leader会commit该提议，通知其他Follower 和 Observer 同步信息； 6）Follwer 或Observer把请求结果返回给Client。 (2）读操作 1）在Client向Follwer 或 Observer 发出一个读的请求； 2）Follwer 或 Observer 把请求结果返回给Client；1.5 主要特点 最终一致性 ：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的特性；可靠性 ：具有简单、健壮、良好的性能，如果消息被某一台服务器接受，那么它将被所有的服务器接受；实时性 ：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。 但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口；等待无关(wait-free) ：慢的或者失效的client，不得干预快速的client的请求，使得每个client都能有效的等待；原子性 ：更新只能成功或者失败，没有中间状态；顺序性 ：按照客户端发送请求的顺序更新数据。 1.6 zookeepr应用场景 1.6.1 数据发布与订阅 发布与订阅即所谓的配置管理，顾名思义就是将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。 应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。 1.6.2 命名空间服务 分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。 1.6.3 分布式通知/协调 不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。 1.6.4 分布式锁 Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。 锁的两种体现方式：(1）保持独占 一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。 (2）控制时序 有一个节点作为父节点，其底下是带有编号的子节点，所有要获取锁的用户，需要在父节点下创建带有编号的子节点，编号最小的会持有锁；当最我号的节点被删除后，锁被释放，再重新找最我号的节点来持有锁，这样保证了全局有序。 1.6.5 集群管理 每个加入集群的机器都创建一个节点，写入自己的状态。 监控父节点的用户会收到通知，进行相应的处理。 离开时删除节点，监控父节点的用户同样会收到通知。

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

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

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