ZooKeeper 适合哪些应用场景？
ZooKeeper 适用于以下应用场景：
- 分布式服务注册与订阅：在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就需要在这些对等的服务器中选择一个来执行相关的业务逻辑，比较典型的服务注册与订阅，如 Dubbo。
- 分布式配置中心：发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到 ZooKeeper 节点上，供订阅者获取数据，实现配置信息的集中式管理和动态更新。
- 命名服务：在分布式系统中，通过命名服务客户端应用能够根据指定名字来获取资源、服务地址和提供者等信息。
- 分布式锁：这个主要得益于 Zookeeper 为我们保证了数据的强一致性。
- 数据发布和/订阅：主要的一个场景，比如配置中心。
- 负载均衡：能够基于域名服务，进行应用的负载，从而达到请求负载到各个应用中。
- 分布式协调/通知：对于一个在多台机器部署运行的应用上，通常都需要一个协调者来控制整个系统的运行流程。
- 集群管理：在集群环境中，机器和应用都是分散着进行部署，每次进行服务的上下线升级的过程中，都要手动进行集群的管理，这样造成人做的事比较重复性，并且也比较麻烦容易出错。
- Master选举。
- 分布式队列。
简述什么是Zookeeper ？
Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。Zookeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
简述Zookeeper 目录结构和作用 ？
Zookeeper的目录结构是基于层次型的目录树，它对树中的节点进行有效管理，从而可以设计出多种多样的分布式的数据管理模型。Zookeeper的作用主要是用来维护和监控存储的数据的状态变化，通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。它并不是用来专门存储数据，而是用于维护和监控数据的状态变化。
简述Zookeeper的工作原理 ？
Zookeeper的工作原理主要基于原子广播机制，实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃的时候，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步之后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。在广播模式下，当一个server加入zookeper服务中，它会在恢复模式下启动，发现leader并和leader进行状态的同步，待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的follower。
简述zoo.cfg 配置项目和对应的作用 ?
Zoo.cfg配置文件是Zookeeper的核心配置文件，其中可以配置的参数有：
- clientPort：用于配置当前服务器对客户端暴露的端口，一般配置为2181，无默认值。
- dataDir：用于配置Zookeeper服务器存储快照文件(Zookeeper 节点数据)的目录，无默认值。
- dataLogDir：用于配置服务器存储事务日志文件的目录，有默认值dataDir，但是建议将两个目录分别配置，防止磁盘的并发读写，影响服务器性能。可将其配置在一个单独的磁盘上。
- tickTime：心跳时间，用于配置服务器最小时间的单位，默认值3000ms，心跳检测时间通常是该单位的倍数。如客户端与服务端之间的会话超时时间在2tickTime~20tickTime之间。
- initLimit：用于配置leader服务器等待Follower服务器启动，并完成数据同步的时间，默认为10，表示10*tickTime。
- syncLimit：用于配置leader服务器和Follower服务器之间进行心跳检测的最大延时时间，默认为5，表示5*tickTime。
- minSessionTimeout和maxSessionTimeout：用于服务端对客户端会话超时时间的限制，也就是客户端自定义的超时时间必须在minSessionTimeoutmaxSessionTimeout内，其默认为分别为2和20，时间表示为2tickTime20tickTime。
- maxClientCnxns：从socket层面限制单个客户端和单台服务器之间的最大并发连接数，即以IP地址粒度来进行连接数的限制，如果为0，表示不作限制，默认为60。
- clientPortAddress：针对多网卡的机器，该参数允许为每个IP地址指定不同的监听端口。
- server.id=host:port:port：用于配置组成Zookeeper集群的机器列表，其中id为serverId，与myid文件中的值对应。第一个端口用于指定Leader服务器和Follower服务器进行运行时通信和数据同步所使用的端口，第二个端口用于进行Leader选举过程中的投票通信。
- autopurge.snapRetainCount：用于配置Zookeeper在自动清理的时候需要保留的快照数据文件数量和对应的事务日志文件，默认为3，自定义值小于3也会取值3。
这些参数可以用来配置Zookeeper服务器的各个方面的行为，包括端口号、数据存储目录、心跳检测机制、集群模式等。在具体使用时，需要根据实际情况进行配置。
请列举Zookeeper的常用命令 ？
Zookeeper的常用命令包括：
- 启动Zookeeper服务：bin/zkServer.sh start
- 查看 Zookeeper状态：bin/zkServer.sh status
- 停止 Zookeeper服务：bin/zkServer.sh stop
- 重启 Zookeeper服务：bin/zkServer.sh restart
- 连接服务器：zkCli.sh -server 192.168.1.2:2181
- 查看根目录：ls /
- 创建节点：create /zk myDate
- 查看节点内容： get /zk
- 设置节点内容： set /zk myBook
- 删除节点： delete /zk
这些命令可以在Zookeeper的CLI环境下使用，用于管理Zookeeper服务器的状态、连接、节点创建、内容查看、修改和删除等操作。
列举Zookeeper服务启动日志的组成结构 ？
Zookeeper服务启动日志的组成结构包括三类日志：事务日志、快照日志和系统日志。
- 事务日志：在Zookeeper系统正常运行过程中，针对所有的更新操作，在返回客户端更新成功响应前，Zookeeper会保证已经将本次更新操作的事务日志写到磁盘上，只有这样，整个更新操作才会生效。事务日志为二进制文件，不能通过vim等工具直接访问，可以通过Zookeeper自带的功能文件读取事务日志文件。
- 快照日志：Zookeeper服务器会产生三类日志其中就有快照日志，它是指在Zookeeper运行过程中，将系统状态的快照以文件形式记录下来，可以用于系统恢复或者备份。
- 系统日志：Zookeeper的系统运行日志可以通过三个位置来进行设置，一是log4j.properties文件中通过zookeeper.log.dir=.来设置，这里的’.'指的是zkServer.sh所在的目录；二是在zkEnv.sh文件中通过ZOO_LOG_DIR=" Z O O K E E P E R P R E F I X / l o g s " 来设置；三是在 z k S e r v e r . s h 文件中通过 Z O O L O G F I L E = z o o k e e p e r − ZOOKEEPER_PREFIX/logs"来设置；三是在zkServer.sh文件中通过ZOO_LOG_FILE=zookeeper- ZOOKEEPERPREFIX/logs"来设置；三是在zkServer.sh文件中通过ZOOLOGFILE=zookeeper−USER-server- H O S T N A M E . l o g Z O O D A E M O N O U T = " HOSTNAME.log _ZOO_DAEMON_OUT=" HOSTNAME.logZOODAEMONOUT="ZOO_LOG_DIR/zookeeper- U S E R − s e r v e r − USER-server- USER−server−HOSTNAME.out"来指定。
这些日志记录了Zookeeper服务器的运行状态、更新操作、系统状态等信息，可以用于系统监控、调试和恢复等操作。
简述Zookeeper基本数据模型和存储结构 ？
Zookeeper的基本数据模型和存储结构可以概括如下：
- 数据模型：Zookeeper的数据模型类似于一个文件系统，具有一个层次的命名空间，使用斜杠“/”进行分隔。但它与标准文件系统不同，标准文件系统由文件夹和文件组成，而Zookeeper由节点（Znode）组成，每个节点都可以拥有子节点。Znode是Zookeeper中的基本单位，每个节点都有一个路径，并且可以存储数据。
- 存储结构：Zookeeper的存储结构采用了类似于目录树的形式，从根节点（/）开始，可以创建子节点，并在子节点下继续创建下一级节点。这种树形结构使得Zookeeper可以方便地存储和管理大量的数据。
- 数据存储方式：在Zookeeper中，每个节点（Znode）都有默认能够存储1MB的数据。每个Znode都可以通过其路径唯一标识。
- 节点类型：Zookeeper有两种类型的节点，分别是临时节点和永久节点。临时节点依赖于创建它们的会话，一旦会话结束，临时节点将会被自动删除。临时节点不允许拥有子节点。
以上信息仅供参考，如需了解更多信息，建议查阅Zookeeper官方文档或咨询专业技术人员。
Zookeeper客户端与服务端之间的的连接称之为什么？
Zookeeper客户端与服务端之间的连接称为会话（session）。在Zookeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。
简述Zookeeper的watcher机制 ？
Zookeeper的watcher机制是一种实现分布式数据发布/订阅功能的方式，它允许客户端向服务端注册一个watcher监听，当服务器的一些特定事件触发这个watcher时，就会向指定客户端发送一个事件通知。这种机制可以帮助实现分布式的通知功能。在Zookeeper中，watcher机制主要包括客户端线程、客户端WatchManager和ZooKeeper服务器三部分。客户端向服务端注册watcher，当服务器的一些特定事件触发了这个watcher，就会向指定客户端发送一个事件通知。触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。总的来说，Watcher机制可以概括为以下三个过程：客户端向服务端注册Watcher、服务端事件发生触发Watcher、客户端回调Watcher得到触发事件情况。
Zookeeper集群不得少于几台服务器，集群规则是什么？
Zookeeper集群不得少于三台服务器，因为Zookeeper通过存活节点数数量是否大于总节点数一半来判断服务是否可以。例如三个节点，挂掉了2个表示整个集群挂掉，而用偶数4个，挂掉了2个，剩下的2个节点并没有超过半数，因此也会挂掉。集群最好是在不同的物理机上，本案例因生产环境因素，搭建在一台物理机上，因此也叫伪集群，但差别不是很大，只是ip地址不同。
Zookeeper有哪几种几种部署模式？
Zookeeper有三种部署模式，分别是单机模式、伪集群模式和集群模式。
- 单机模式：一般用来检验Zookeeper基础功能，熟悉Zookeeper各种基础操作及特性。
- 伪集群模式：在单台机器上部署集群，方便在本地验证集群模式下的各种功能。
- 集群模式：一般在生产环境使用，具备一致性、分区容错性。
请阐述Zookeeper是如何选取主leader的？
Zookeeper在集群模式下，是通过一种称为Zab协议的机制来选取主leader的。Zab协议有两种模式，分别是恢复模式和广播模式。当服务启动或者在领导者崩溃的时候，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步之后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。在广播模式下，当一个server加入zookeper服务中，它会在恢复模式下启动，发现leader并和leader进行状态的同步，待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的follower。
在Zab协议中，每个服务器都会发出一个投票。由于是初始情况，服务器1和服务器2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，然后各自将这个投票发给集群中其他机器。之后，每个服务器会接受来自各个服务器的投票。在这个过程中，服务器会判断收到的投票是否合法，并根据一定的规则进行投票的确认和转发。最终，会选出一个主leader，其他服务器则会成为follower。
需要注意的是，Zookeeper在选举主leader时并不是基于节点ID的大小进行排序的，而是通过一种基于时序的机制来选取主leader。具体来说，每个服务器在发出投票时都会携带一个时间戳，这个时间戳是服务器在启动时获取的。当其他服务器收到投票后，会根据时间戳的大小来判断是否转发这个投票。时间戳最大的服务器会被选为主leader。如果多个服务器的投票时间戳相同，则按照节点的ID进行排序，ID最小的服务器会被选为主leader。
Zookeeper是如何保证事务的顺序一致性的？
Zookeeper通过多种机制保证了事务的顺序一致性：
- 顺序执行：Zookeeper的所有写操作都会被服务器顺序执行，无论这些操作是否来自同一个客户端。这意味着客户端发起的每次写操作（如创建节点、设置节点数据或删除节点等）都会在严格的先后顺序下按顺序执行。
- 唯一性约束：Zookeeper通过路径名确保所有写请求都是唯一的。对于相同的节点路径和数据，只允许一个客户端成功创建或更新该节点，其他客户端会收到NodeExistsException或版本冲突（version mismatch）等异常信息。
- 数据版本控制：Zookeeper中的每条记录（包括znode、数据等）都有一个版本号，它是由一个递增的计数器生成的。如果客户端试图使用过期版本号更新或删除记录，则会导致版本号冲突而失败。
- 会话控制：当客户端建立与Zookeeper服务器的连接时，将分配一个唯一的会话ID。在会话有效期内，客户端可以发送读写请求，在会话超时后，Zookeeper将关闭与其关联的会话并清除已经申请的临时节点等数据。
- 仅序列化的访问：对于每个znode的所有操作都是通过一个全局有序的更新序列（transaction log）进行的，客户端只会看到该全局序列的一个后缀。因此，对数据和状态的读取操作必须以相同的方式和序列化顺序执行。
- ZAB协议：ZAB协议是Zookeeper自主开发的一种原子广播协议。它将Zookeeper服务集群中的每个服务器划分为两类:Leader（领导者）和Follower（跟随者）。Leader负责处理客户端请求并维护系统状态，而Followers则负责复制Leader的状态。当客户端发送一个事务请求到Zookeeper集群时，Leader会将该请求附加到自己的事务日志中，并广播给所有的Followers。这些Followers会按照Leader发送的顺序逐个执行事务请求。
- 提案编号：每个事务请求在被广播前，会被分配一个唯一的递增编号，称为提案编号。这个编号在整个集群中都是唯一的，用于标识事务的顺序。
- Quorum和多数派决策：Zookeeper采用了Quorum的思想来保证顺序一致性。Quorum是指在一个分布式系统中，至少需要多少个节点达成一致才能进行下一步操作。通常情况下，Zookeeper集群的Quorum数量为奇数，以确保有足够的节点来解决冲突。多数派决策是指在一个Quorum中，大多数节点必须就某个提案达成一致，才认为这个提案是提交的。
- 提交过程：一旦多数节点接受了某个提案，Leader就会将该提案标记为“已提交”。一旦提交，提案所对应的操作就会被应用到状态机上，从而实现一致性的状态更新。
综上所述，Zookeeper通过多种机制共同保证了事务的顺序一致性。
由于内容太多，更多内容以链接形势给大家，点击进去就是答案了
27. Zookeeper负载均衡和Nginx负载均衡有什么区别？
30. ZooKeeper 集群中个服务器之间是怎样通信的？
31. 请列举ZooKeeper中使用watch的注意事项有哪些？
32. 客户端修改了某个节点的数据，其他客户端能够马上获取到这个最新数据吗？
34. 解释ZooKeeper下service有几种工作状态 ？
40. Zookeeper对节点的watch监听通知是永久的吗？
2483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
