Zookeeper 面试题（六）

1. 简述Zookeeper中的脑裂问题？

在分布式系统中，脑裂（Split-brain）问题是指由于网络分区或其他故障导致系统分裂成两个或多个独立的、相互之间无法通信的部分，每个部分都认为自己是整个系统的唯一活跃部分。在ZooKeeper这类分布式协调服务中，脑裂问题可能导致严重的后果，比如数据不一致性和服务不可用。

以下是ZooKeeper中可能出现脑裂问题的情况和特点：

网络分区：由于网络问题，ZooKeeper集群被分割成两个或多个无法相互通信的组。如果每个组内都包含有ZooKeeper节点，它们可能各自独立运行。
领导者选举：在正常情况下，ZooKeeper集群通过选举出一个领导者（Leader）来管理事务和协调状态。但如果发生脑裂，每个分裂出来的独立组都可能选举出自己的Leader。
数据不一致：由于每个分裂出来的组都可能独立处理事务，这可能导致不同组之间的数据不一致。
服务冲突：如果每个分裂出来的组都认为自己是活跃的，它们可能会同时对外提供服务，造成服务冲突。
恢复困难：一旦发生脑裂，当网络恢复后，合并分裂出来的组可能会非常困难，因为需要解决数据一致性问题。

为了避免脑裂问题，ZooKeeper采用了以下一些策略：

过半机制：确保集群中超过半数的节点能够相互通信，以此来选举出一个统一的Leader。
奇数节点：推荐部署奇数个节点的ZooKeeper集群，以便在容忍最大数量节点故障的同时，节省资源。
网络设计：通过设计高可用网络和使用网络隔离技术，减少网络问题导致的分区。
仲裁机制：在一些配置中，可以设置仲裁节点或使用第三方服务来帮助解决脑裂问题。
磁盘锁：在某些实现中，可以使用磁盘锁来防止在脑裂发生时两个分裂的集群同时运行。

ZooKeeper通过这些机制来最大程度地减少脑裂问题的发生，并确保分布式系统的一致性和可靠性。

2. Zookeeper对节点的watch监听通知是永久的吗？

不是的，ZooKeeper对节点的watch监听通知不是永久的。在ZooKeeper中，watcher是一次性的。这意味着当客户端在一个ZNode上注册了一个watcher并因为某个事件被触发后，这个watcher就会被自动移除。如果客户端希望继续监听该节点的变化，它需要重新注册一个新的watcher。

这种设计有几个原因：

避免资源泄露：通过自动移除已触发的watcher，ZooKeeper避免了资源的持续占用，这对于资源管理和避免内存泄露是非常重要的。
减轻服务器负担：如果watcher是永久的，ZooKeeper服务器需要维护大量的持久连接和状态信息，这会增加服务器的负担。
客户端显式控制：客户端显式地注册和注销watcher可以让客户端有更精确的控制权，决定何时监听以及何时停止监听。
保证一致性：在分布式系统中，永久的watcher可能会导致状态同步的问题，因为客户端可能在网络分区或其他故障后错过了一些更新。通过重新注册watcher，客户端可以确保它与当前系统状态同步。
简化实现：一次性的watcher简化了客户端和服务器端的实现，因为不需要处理watcher的生命周期管理。

因此，如果客户端需要持续监听ZNode的变化，它必须在每次收到通知后重新设置watcher。这种做法在ZooKeeper中是推荐的，以确保系统的效率和可靠性。

3. 简述Zookeeper和Dubbo的关系？

ZooKeeper和Dubbo之间的关系是协作关系，其中ZooKeeper作为服务注册中心和协调组件，支持Dubbo框架实现服务的发现、配置和治理。以下是它们之间的关系概述：

服务注册中心：
- 在Dubbo中，服务提供者在启动时会向ZooKeeper注册自己的服务地址。
- 服务消费者在启动时会向ZooKeeper订阅服务提供者的地址信息，以便知道如何访问服务。
动态发现：
- ZooKeeper提供了一个动态的服务注册表，Dubbo利用这个注册表来动态发现服务提供者。
- 服务消费者可以通过ZooKeeper获得服务提供者的最新地址列表，实现负载均衡和服务调用。
配置管理：
- ZooKeeper可以用来存储和管理Dubbo的配置信息，如集群模式、超时设置、重试策略等。
- 配置信息可以在不重启服务的情况下动态更新。
集群管理：
- ZooKeeper可以帮助Dubbo集群进行领导者选举、成员管理等操作。
- 在Dubbo集群中，ZooKeeper可以用来协调多个服务实例，确保集群的一致性和高可用性。
故障转移：
- 当服务提供者实例宕机时，ZooKeeper可以通知服务消费者有服务提供者下线，触发故障转移机制。
- 服务消费者可以根据ZooKeeper中的信息重新选择可用的服务提供者。
服务治理：
- ZooKeeper作为Dubbo服务治理的一部分，帮助实现服务的分组、版本控制和路由策略。
分布式协调：
- ZooKeeper提供了分布式锁、队列等协调原语，Dubbo可以使用这些原语来实现更复杂的分布式应用场景。
可扩展性：
- 通过ZooKeeper，Dubbo可以很容易地扩展服务，添加新的服务提供者或消费者，而无需复杂的配置更改。
容错性：
- ZooKeeper的容错机制能够确保即使部分节点宕机，Dubbo集群仍然可以正常工作。
监控和管理：
- ZooKeeper可以集成监控系统，帮助管理和监控Dubbo集群的状态和性能。

总的来说，ZooKeeper为Dubbo提供了一个强大的基础设施，帮助Dubbo实现服务的注册、发现、配置和治理，确保了Dubbo集群的高可用性和可扩展性。

4. 简述对ZooKeeper对事务性的支持？

ZooKeeper是一个为分布式应用提供协调服务的系统，它提供了类似于文件系统的树形结构的命名空间，其中每个节点称为ZNode。ZooKeeper对事务性的支持主要体现在以下几个方面：

原子性操作：ZooKeeper保证每个更新操作（如创建、删除、更新ZNode）都是原子性的。这意味着操作要么完全应用，要么完全不应用，不存在中间状态。
顺序一致性：ZooKeeper保证了事务的顺序一致性。每个事务都会被分配一个全局唯一的序列号（ZXID），系统按照ZXID的顺序来处理事务。
写入持久性：ZooKeeper通过事务日志（Write-Ahead Logging, WAL）确保写操作的持久性。事务日志在变更操作执行前就会被写入到磁盘，这样即使系统发生故障，也能够恢复到一致的状态。
多版本并发控制：每个ZNode可以有多个版本，ZooKeeper通过数据版本来处理并发更新，确保并发操作的一致性。
客户端会话：ZooKeeper为每个客户端会话分配一个唯一的会话ID，并保证会话ID的顺序一致性。客户端的请求都是在会话的上下文中进行的，ZooKeeper会根据会话ID来处理客户端的请求。
Watcher机制：客户端可以在ZNode上注册Watcher来监听节点的变化。当ZNode发生变化时，所有注册了Watcher的客户端都会收到通知，这可以看作是一种轻量级的事务通知机制。
事务日志和快照：ZooKeeper周期性地生成数据的快照，并与事务日志一起存储在磁盘上，以确保数据的持久化和一致性恢复。
最终一致性：虽然ZooKeeper保证了单个事务的原子性和顺序性，但在复杂的分布式环境中，客户端可能会在不同的时间点看到不同的数据副本。ZooKeeper保证在没有新的更新的情况下，客户端最终会读取到最新的数据。
事务提案和提交：在ZooKeeper的Zab协议中，Leader节点负责将客户端的更新操作作为提案发送给所有的Follower。只有当超过半数的Follower确认了提案，Leader才会提交事务并更新集群状态。

通过这些机制，ZooKeeper能够为分布式应用提供可靠和一致的协调服务，尽管它不是一个传统的事务性数据库系统。

5. 请说明ZooKeeper使用到的各个端口的作用？

ZooKeeper作为一个分布式协调服务，会使用到几个不同的端口来支持其功能。以下是一些常见的ZooKeeper端口及其作用：

客户端端口（Client Port）：
- 这是客户端与ZooKeeper服务器进行通信的端口。客户端通过这个端口发送请求，如创建会话、获取数据、注册Watcher等，以及接收响应。
- 默认情况下，ZooKeeper的客户端端口是2181。
领导者选举端口（Leader Election Port）：
- 在集群模式下，ZooKeeper服务器节点之间需要进行通信以选举领导者。这个端口用于集群内部的领导者选举通信。
- 默认情况下，ZooKeeper的领导者选举端口是3888。
组播端口（Quorum Port）：
- 这个端口用于ZooKeeper服务器节点之间的组播通信，特别是在领导者选举和集群状态同步的过程中。
- 默认情况下，ZooKeeper的组播端口是2888。
跟随者端口（Follower Port）：
- 在集群模式下，跟随者节点（Follower）使用这个端口来接收来自领导者的请求和同步数据。
- 跟随者端口通常与客户端端口相同，但在某些配置中可能会有所不同。
观察者端口（Observer Port）：
- 如果ZooKeeper集群配置了观察者（Observer）角色，这个端口用于观察者接收来自领导者的数据副本，以便提供读取操作的扩展能力。
- 观察者端口通常与客户端端口相同，但在某些配置中可能会有所不同。
JMX端口（JMX Port）：
- ZooKeeper提供了Java管理扩展（JMX）端口，用于管理和监控ZooKeeper实例。管理员可以通过JMX客户端连接到这个端口来获取性能指标和运行时信息。
- JMX端口不是ZooKeeper默认配置的一部分，需要在启动ZooKeeper时指定。
RooKie端口：
- 在ZooKeeper 3.5.0及更高版本中，RooKie是一种新的通信协议，旨在提高性能。RooKie端口用于支持这种新的通信方式。

请注意，端口号可以在ZooKeeper的配置文件中进行自定义设置，以适应不同的部署需求。在生产环境中，出于安全考虑，建议将ZooKeeper的端口配置在防火墙后面，并仅允许受信任的客户端和服务访问这些端口。

6. 创建的临时节点什么时候会被删除，是连接一断就删除吗？

在ZooKeeper中，临时节点（Ephemeral Nodes）的生命周期与创建它的客户端会话（Session）紧密相关。以下是临时节点被删除的几种情况：

会话超时：如果客户端的会话因为网络问题或其他原因而超时，那么与该会话关联的所有临时节点都会被自动删除。
客户端断开连接：当客户端与ZooKeeper服务器的连接断开时，如果会话已经超时，那么临时节点会被删除。如果会话没有超时，客户端可能会重新连接到服务器，此时临时节点仍然存在。
客户端显式删除：客户端可以在任何时候显式地删除它创建的临时节点，即使客户端的会话仍然有效。
客户端崩溃：如果客户端崩溃或突然停止运行，那么它的会话将不会被续期，一旦会话超时，临时节点就会被删除。
会话关闭：客户端可以主动关闭其与ZooKeeper的会话，这将导致会话结束，随后临时节点被删除。
服务器故障：如果ZooKeeper服务器发生故障，客户端可能会失去连接。在服务器恢复后，如果客户端能够重新连接并续期其会话，那么临时节点将继续存在；如果会话超时，则临时节点会被删除。

总的来说，临时节点的删除主要取决于客户端会话的状态。只要会话保持活跃（无论是通过客户端的正常操作还是服务器的会话续期），临时节点就会继续存在。一旦会话结束，无论是因为超时还是客户端的显式关闭，相关的临时节点都会被ZooKeeper自动删除。这种机制使得临时节点非常适合用于实现诸如领导者选举、锁定机制和协调分布式系统中的临时状态等场景。

7. Zookeeper 能否为临时节点创建子节点？

在ZooKeeper中，可以为临时节点（EPHEMERAL节点）创建子节点。然而，这有一些重要的考虑事项：

临时节点的生命周期：临时节点的生命周期与创建它的会话相关联。如果会话过期或客户端与ZooKeeper断开连接，那么该临时节点以及其所有子节点都会被自动删除。
子节点的类型：你可以为临时节点创建不同类型的子节点，包括持久节点、持久顺序节点、临时节点和临时顺序节点。
有序节点：如果为临时节点创建了一个持久顺序子节点（PERSISTENT_SEQUENTIAL），当临时父节点被删除时，该有序子节点将变为普通的持久节点，失去其顺序属性，并且继续存在。
客户端断开连接：如果客户端断开连接，其创建的所有临时节点及其子节点都会被删除，无论子节点的类型如何。
集群稳定性：由于临时节点及其子节点会在客户端会话结束时被删除，因此在设计使用临时节点时需要考虑到这可能对集群稳定性和数据一致性的影响。
使用场景：临时节点通常用于实现诸如领导者选举、锁定机制等，其中节点的存在仅在客户端活跃期间需要。
API限制：在使用ZooKeeper客户端API创建子节点时，需要确保正确处理了会话的生命周期，以避免意外删除节点。