ZooKeeper 故障排除神器：可视化工具助您快速查明问题 (zookeeper的主要功能)

简介

ZooKeeper是一个分布式协调服务，用于管理分布式系统中的数据一致性和服务发现。作为关键基础设施，ZooKeeper故障排查至关重要。可视化工具可以帮助我们快速查明问题，提高排障效率。

本文将介绍两款常用的ZooKeeper可视化工具：ZkVis和ZooInspector，并展示如何使用它们进行故障排查。

ZooKeeper的主要功能

在使用可视化工具之前，了解ZooKeeper的主要功能将有助于我们更好的定位问题：

• 数据存储：ZooKeeper提供了层次结构的数据存储，类似于文件系统，可以存储配置数据、服务注册信息等。
• 协调服务：ZooKeeper提供了一系列协调服务，如分布式锁、队列、计数器，便于分布式系统的协调管理。
• 服务发现：ZooKeeper可以帮助服务注册和发现，使分布式系统的各个组件能够相互通信。
• 配置管理：ZooKeeper可以集中管理系统配置，便于配置的变更和管理。

故障排除神器：可视化工具

ZkVis

ZkVis是一个基于Web的ZooKeeper可视化工具，可以提供ZooKeeper集群的实时视图。它的主要功能包括：

• 查看ZooKeeper集群结构，包括节点、数据和Watcher。
• 追踪ZooKeeper会话和事务活动。
• 监视ZooKeeper指标，如集群负载、服务器状态等。

ZooInspector

ZooInspector是一个Java客户端工具，可以连接到ZooKeeper集群并提供直观的GUI界面。它的主要功能包括：

• 浏览ZooKeeper数据树，查看节点数据和子节点。
• 创建、修改、删除ZooKeeper节点和数据。
• 监视ZooKeeper事件，如节点创建、删除、数据变更等。

使用可视化工具进行故障排查

下面是一些使用可视化工具进行ZooKeeper故障排查的示例：

• 集群状态监控：使用ZkVis监控集群负载、服务器状态等指标，及时发现异常情况。
• 节点数据查看：使用ZooInspector浏览数据树，查看节点数据，判断数据是否正确或是否存在异常修改。
• 会话跟踪：使用ZkVis追踪ZooKeeper会话，分析会话数量、持续时间，判断是否存在会话泄露等问题。
• 事件监视：使用ZooInspector监视ZooKeeper事件，分析节点创建、删除、数据变更等事件，定位问题产生的源头。

结语

可视化工具是ZooKeeper故障排查的有力助手。通过使用ZkVis和ZooInspector，我们可以快速获得ZooKeeper集群的实时视图，查看数据、追踪会话、监视事件，从而快速定位问题，提高排障效率。在实际运维中，管理员应熟练掌握这些工具，以确保ZooKeeper集群的稳定运行。

Zookeeper-Zookeeper可以干什么

在Zookeeper的官 网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。 那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。 配置管理在我们的应用中除了代码外，还有一些就是各种配置。 比如数据库连接等。 一般我们都是使用配置文件的方式，在代码中引入这些配置文件。 但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。 这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。 比如我们可以把配置放在数据库里，然后所有需要配置的服务都去这个数据库读取配置。 但是，因为很多服务的正常运行都非常依赖这个配置，所以需要这个集中提供配置服务的服务具备很高的可靠性。 一般我们可以用一个集群来提供这个配置服务，但是用集群提升可靠性，那如何保证配置在集群中的一致性呢？ 这个时候就需要使用一种实现了一致性协议的服务了。 Zookeeper就是这种服务，它使用Zab这种一致性协议来提供一致性。 现在有很多开源项目使用Zookeeper来维护配置，比如在HBase中，客户端就是连接一个Zookeeper，获得必要的HBase集群的配置信息，然后才可以进一步操作。 还有在开源的消息队列Kafka中，也使用Zookeeper来维护broker的信息。 在Alibaba开源的SOA框架Dubbo中也广泛的使用Zookeeper管理一些配置来实现服务治理。 名字服务名字服务这个就很好理解了。 比如为了通过网络访问一个系统，我们得知道对方的IP地址，但是IP地址对人非常不友好，这个时候我们就需要使用域名来访问。 但是计算机是不能是别域名的。 怎么办呢？如果我们每台机器里都备有一份域名到IP地址的映射，这个倒是能解决一部分问题，但是如果域名对应的IP发生变化了又该怎么办呢？于是我们有了DNS这个东西。 我们只需要访问一个大家熟知的(known)的点，它就会告诉你这个域名对应的IP是什么。 在我们的应用中也会存在很多这类问题，特别是在我们的服务特别多的时候，如果我们在本地保存服务的地址的时候将非常不方便，但是如果我们只需要访问一个大家都熟知的访问点，这里提供统一的入口，那么维护起来将方便得多了。 分布式锁其实在第一篇文章中已经介绍了Zookeeper是一个分布式协调服务。 这样我们就可以利用Zookeeper来协调多个分布式进程之间的活动。 比如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。 但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。 而如果我们只让一个服务进行操作，那又存在单点。 通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。 这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。 比如HBase的Master就是采用这种机制。 但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的时候要比同一个进程里的锁更谨慎的使用。 集群管理在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。 有新的节点加入进来，也有老的节点退出集群。 这个时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。 比如我们是一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。 这个时候我们就需要动态感知到集群目前的状态。 还有，比如一个分布式的SOA架构中，服务是一个集群提供的，当消费者访问某个服务时，就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现，比如Alibaba开源的SOA框架Dubbo就采用了Zookeeper作为服务发现的底层机制)。 还有开源的Kafka队列就采用了Zookeeper作为Cosnumer的上下线管理。 后记在这篇文章中，列出了一些Zookeeper可以提供的服务，并给出了一些开源系统里面的实例。 后面我们从Zookeeper的安装配置开始，并用示例进一步介绍Zookeeper如何使用。 (转载）

【Zookeeper系列】ZK命令基本使用

在了解 ZK 底层原理之前，咱们先简单了解常用的 ZK 命令，熟悉常用 ZK 命令有利于排查相关问题或了解基于 ZK 自研系统等场景。 比如在开发的时候，发现有些Dubbo服务无法被调用，这有可能是服务没有注册到ZK或者断开连接；也有可能公司有自研的系统使用 ZK 作为配置中心，熟悉 ZK 命令就能知道是如何做到服务发现注册和配置动态更新。 话不多说，咱们先来了解常见的 ZK 命令吧！ 实际上，ZK并没有help命令，你可以随意敲一两个字符也会这样显示，只不过基于使用Linux的习惯，姑且认为输入help能打印出ZK支持的命令吧。 ls 命令可以查看指定目录下的节点，使用可选的参数，能够更加详细的看到节点的相关信息 stat / 等价于 ls -s / 和 ls 命令相似的，加上-w参数添加监听 在ZK 3.5版本之后，新增了容器和TTL节点，分别是使用-c 和 -t 创建。 所以读者们要注意你当前使用的版本，如果版本低于3.5的，是没有容器和TTL节点。 特别说明一下容器节点和TTL节点的使用： 另外关于TTL节点 的使用，需要特别注意的是，如果使用默认的配置文件启动zk，想创建有存活时间的节点，比如执行 create -t 10 /test 是会报 KeeperErrorCode = Unimplemented for XXX 这样的错误。 解决办法是需要在ZK启动前，先在配置文件加上 extendedTypesEnabled=true 然后重启ZK（集群部署的话，所有ZK都需要修改配置文件再重启） 配置后重启，执行 create -t 10 /test 这样的命令就不会报错啦 例子：get -s /demo 例子：先查询节点版本号，模拟并发下修改同一节点 get -s /demo 可知当前 dataVersion = 1 客户端1：set -v 1 /demo demo-data1 客户端2：set -v 1 /demo demo-data2 客户端1比客户端2先执行，客户端2再执行的话，这时显示报错 -v version：和 set 命令相似，-v 参数用于判断当前操作的版本 例子：先创建一个delNode节点，然后删除 在前面使用create命令的时候，有一个acl参数是设置节点权限的，那么我们应该怎么设置？ 举个例子： create /testAcl demo world:anyone:crwda 这行命令的意思是，创建 testAcl 这个节点，节点值为demo，其权限策略是所有人都可以执行 crwda 操作。 那么接下来，咱们先看下 ACL 是什么东东？ ACL 全称是 Access Control List ，也就是访问控制列表，ACL可以设置节点的操作权限。 那么控制权限的粒度是怎样呢？ 对于节点 ACL 权限控制，是通过使用： scheme:id:perm来标识（也就是例子中的格式 -> world:anyone:crwda），其含义是： Scheme 有哪些授权策略？ ID 授权对象有哪些？ Permission 权限有哪些？ 根据上面的参数可知，我们可以通过给所有人、特定的账号密码、特定的 ip 设置节点权限，这样能够更加方面地管理节点的访问。 值得注意的是，节点可以设置多种授权策略，但对于上下节点而言，权限的设置只对当前节点有效。 换言之，权限不存在继承关系，即使节点被设置权限，但不会影响上下节点原来的权限！ 上面执行了 create /testAcl demo world:anyone:crwda 命令给节点设置权限，那怎么看节点的权限咧？ 很简单，执行 getAcl 节点路径 就可以查看对应节点的权限，比如 getAcl /testAcl，执行结果如下 除了在执行create命令创建节点的时候设置权限，还可以通过 setAcl 指定节点设置权限，比如我想指定/testAcl这个节点只可以通过特定 IP操作，并且限制执行权限为crdw，那么可以执行setAcl /testAcl ip:127.0.0.1:crwd ，再次执行 getAcl /testAcl 结果如下： ZK 的命令还有部分没有展示，这并不阻碍咱们学习ZK的原理，先掌握常见的命令，如果日后有其他场景的话，再根据特定的命令学习就可以啦。 无意中发现有 Zookeeper的客户端，感兴趣的读者可以玩一下～ 友情提醒，可能在节点数量很多的时候，打开很慢，甚至卡死，所以这个可视化工具可以在自己本地玩玩，不建议应用在生产上哈。 这也侧面的说明，学会 ZK 命令的重要性（认真脸） 解压缩后，进入ZooInspector的build目录，执行java -jar 就可以启动工具。 连接上 ZK 后，就可以看到节点的信息和节点的ACL，具体玩法，可以再自己摸索哈～ 好了，以上是 ZK 常见命令的基本使用和可视化工具的基本使用。 参考资料： 《从Paxos到Zookeeper分布式一致性原理与实践》 如果觉得文章不错的话，麻烦点个赞哈，你的鼓励就是我的动力！对于文章有哪里不清楚或者有误的地方，欢迎在评论区留言~

Zookeeper在哪些系统中使用，又是怎么用的

ZooKeeper作为发现服务的问题ZooKeeper(注：ZooKeeper是著名Hadoop的一个子项目，旨在解决大规模分布式应用场景下，服务协调同步(CoordinateService)的问题;它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目，它很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用;但是用它来做Service发现服务解决方案则是个错误。 在分布式系统领域有个著名的 CAP定理(C-数据一致性;A-服务可用性;P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个);ZooKeeper是个CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。 但是别忘了，ZooKeeper是分布式协调服务，它的职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗?)。 而且，作为ZooKeeper的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。 作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好;再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。 所以说，用ZooKeeper来做Service发现服务是肯定错误的，如果你这么用就惨了!而且更何况，如果被用作Service发现服务，ZooKeeper本身并没有正确的处理网络分割的问题;而在云端，网络分割问题跟其他类型的故障一样的确会发生;所以最好提前对这个问题做好100%的准备。 就像 Jepsen在ZooKeeper网站上发布的博客中所说：在ZooKeeper中，如果在同一个网络分区(partition)的节点数(nodes)数达不到ZooKeeper选取Leader节点的“法定人数”时，它们就会从ZooKeeper中断开，当然同时也就不能提供Service发现服务了。 如果给ZooKeeper加上客户端缓存(注：给ZooKeeper节点配上本地缓存)或者其他类似技术的话可以缓解ZooKeeper因为网络故障造成节点同步信息错误的问题。 Pinterest与 Airbnb公司就使用了这个方法来防止ZooKeeper故障发生。 这种方式可以从表面上解决这个问题，具体地说，当部分或者所有节点跟ZooKeeper断开的情况下，每个节点还可以从本地缓存中获取到数据;但是，即便如此，ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。 如果ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的;所以导致到达这些节点的服务请求被丢失了。 (注：这也是为什么ZooKeeper不满足CAP中A的原因)更深层次的原因是，ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法的目的是为了让ZooKeeper变得更加可靠(available);但是，ZooKeeper设计的本意是保持节点的数据一致，也就是CP。 所以，这样一来，你可能既得不到一个数据一致的(CP)也得不到一个高可用的(AP)的Service发现服务了;因为，这相当于你在一个已有的CP系统上强制栓了一个AP的系统，这在本质上就行不通的!一个Service发现服务应该从一开始就被设计成高可用的才行!如果抛开CAP原理不管，正确的设置与维护ZooKeeper服务就非常的困难;错误会 经常发生，导致很多工程被建立只是为了减轻维护ZooKeeper的难度。 这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。 Knewton平台很多故障就是由于ZooKeeper使用不当而导致的。 那些看似简单的操作，如：正确的重建观察者(reestablishingwatcher)、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。 同时，我们确实也遇到过ZooKeeper的一些经典bug： ZooKeeper-1159 与 ZooKeeper-1576;我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。 这些问题之所以会出现，在于ZooKeeper需要管理与保障所管辖服务群的Session与网络连接资源(注：这些资源的管理在分布式系统环境下是极其困难的);但是它不负责管理服务的发现，所以使用ZooKeeper当Service发现服务得不偿失。 做出正确的选择：Eureka的成功我们把Service发现服务从ZooKeeper切换到了Eureka平台，它是一个开源的服务发现解决方案，由Netflix公司开发。 (注：Eureka由两个组件组成：Eureka服务器和Eureka客户端。 Eureka服务器用作服务注册服务器。 Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。 )Eureka一开始就被设计成高可用与可伸缩的Service发现服务，这两个特点也是Netflix公司开发所有平台的两个特色。 (他们都在讨论Eureka)。 自从切换工作开始到现在，我们实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。 我们也被告知过，在云平台做服务迁移注定要遇到失败;但是我们从这个例子中得到的经验是，一个优秀的Service发现服务在其中发挥了至关重要的作用!首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切换到新的Eureka节点;当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中;而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。 所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。 Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。 当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务(注：ZooKeeper不会)：接收新的服务注册同时将它们提供给下游的服务发现请求。 这样一来，就可以实现在同一个子网中(same side ofpartition)，新发布的服务仍然可以被发现与访问。 但是，Eureka做到的不止这些。 正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器;如果在Eureka中注册的服务，它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。 这是个很好的功能，但是当网络分割故障发生时，这也是非常危险的;因为，那些因为网络问题(注：心跳慢被剔除了)而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割成了独立的子网而不能互访而已。 幸运的是，Netflix考虑到了这个缺陷。 如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。 此时，这个Eureka节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。 当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。 所以Eureka的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。 最后，Eureka还有客户端缓存功能(注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口)。 所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过Eureka客户端缓存来获取现有的服务注册信息。 甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题时;得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。 Eureka的构架保证了它能够成为Service发现服务。 它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，这样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。 而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。 但是，如果使用ZooKeeper你必须自己来实现这些功能。 Eureka的所有库都是开源的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。 维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。 Eureka提供了一个web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。 Eureka甚至提供了Restful-API接口，方便第三方程序集成Eureka的功能。

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

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

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