Kafka 中的 Zookeeper：详细信息

2025年5月14日 | 阅读 16 分钟

ZooKeeper 是 Apache Kafka 架构中的一个基础组件，在协调和管理 Kafka Broker 方面发挥着至关重要的作用。它负责处理诸如领导者选举、配置管理和故障检测等关键任务。在本指南中，我们将详细解释 ZooKeeper 在 Kafka 中的作用，并通过示例程序来说明其功能。

ZooKeeper 是一个分布式协调服务，Kafka 使用它来管理其分布式组件。Kafka Broker（Kafka 集群中的服务器）依赖 ZooKeeper 进行元数据存储、领导者选举和配置管理。

Kafka 中 ZooKeeper 的架构

在深入探讨 ZooKeeper 在 Kafka 中的具体作用之前，了解其架构至关重要。

集群 (Ensemble)
ZooKeeper 集群是一组协同工作的 ZooKeeper 服务器，用于维护分布式系统的状态。通常使用奇数台服务器（3、5 或 7 台）来确保高可用性并避免脑裂场景。
领导者和跟随者 (Leader and Followers)
ZooKeeper 集群中的一台服务器充当领导者，负责处理所有写请求并将其数据复制到跟随者服务器。跟随者处理读请求并复制领导者的数据。
会话和监听器 (Sessions and Watches)
Kafka Broker 与 ZooKeeper 维护会话，允许它们注册自己并在特定的 znode（ZooKeeper 节点）上设置监听器。监听器会在 znode 状态发生变化时通知 Broker，从而使 Kafka 能够做出相应反应。
ZNodes
ZooKeeper 使用类似文件系统的分层命名空间，其中每个节点称为 znode。Znodes 存储数据和元数据。Kafka 使用 znodes 来存储关于 Broker、主题、分区等的信息。

Kafka 中 ZooKeeper 的特性

Broker 协调
领导者选举
控制器选举
元数据存储
配置管理
故障检测和恢复

ZooKeeper 是 Apache Kafka 分布式架构的有机组成部分，提供了许多对于 Kafka 集群平稳运行至关重要的特性。下面，我们将探讨 ZooKeeper 在 Kafka 中的关键特性，并提供示例程序来演示这些特性的实现和使用。

1. Broker 协调

ZooKeeper 通过跟踪集群中的所有活动 Broker 来协调 Kafka Broker。每个 Broker 在启动时都会向 ZooKeeper 注册自己，ZooKeeper 会维护一个这些 Broker 的动态列表。这种协调对于 Kafka 的可扩展性和可靠性至关重要。

示例程序：注册 Kafka Broker

import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.ZooDefs;
import org.apache.zookeeper.ZooKeeper;

public class BrokerRegistration {
    private static ZooKeeper zk;
    private static ZooKeeperConnection conn;

    public static void main(String[] args) throws Exception {
        String path = "/brokers/ids/1"; // Broker ID 1
        byte[] data = "localhost:9092".getBytes(); // Broker host and port

        // Establish ZooKeeper connection
        conn = new ZooKeeperConnection();
        zk = conn.connect("localhost");

        // Create ephemeral znode to register broker
        zk.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);

        System.out.println("Broker registered successfully.");

        // Close connection
        conn.close();
    }
}

输出

说明

Broker 通过在 `/brokers/ids/` 下创建一个临时 znode 来向 ZooKeeper 注册自己。
该 znode 包含 Broker 的主机和端口信息，如果 Broker 断开连接或失败，该 znode 会被自动删除。

2. 领导者选举

ZooKeeper 负责 Kafka 中的领导者选举。对于每个分区，Kafka 都需要一个 Broker 来充当领导者，负责管理该分区的所有读写操作。ZooKeeper 确保每个分区只有一个 Broker 被选举为领导者。

示例程序：领导者选举

import org.apache.zookeeper.*;
public class LeaderElection implements Watcher {
    private static ZooKeeper zk;
    private static ZooKeeperConnection conn;
    public void process(WatchedEvent event) {
        if (event.getType() == Event.EventType.NodeDeleted) {
            System.out.println("Leader lost. Initiating new leader election...");
            electLeader();
        }    }
    public static void electLeader() {
        try {
            zk.create("/leader", "broker1".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
            System.out.println("Broker1 is now the leader.");
        } catch (KeeperException | InterruptedException e) {
            System.out.println("Leader already exists, waiting for current leader to relinquish...");        }    }

    public static void main(String[] args) throws Exception {
        conn = new ZooKeeperConnection();
        zk = conn.connect("localhost");
        zk.register(new LeaderElection());
        electLeader();
        Thread.sleep(Long.MAX_VALUE);
    }
}

输出

说明

此程序模拟了一个领导者选举过程，Broker 尝试通过创建临时 znode 来成为领导者。
如果 znode 已存在，则表示另一个 Broker 已经是领导者。

3. 控制器选举

ZooKeeper 负责选举 Kafka 控制器，这是一个特殊的 Broker，负责管理分区领导者和副本分配。控制器对于集群的稳定性至关重要，尤其是在 Broker 发生故障或网络分区时。

示例程序：控制器选举

import org.apache.zookeeper.*;

public class ControllerElection implements Watcher {
    private static ZooKeeper zk;
    private static ZooKeeperConnection conn;

    public void process(WatchedEvent event) {
        if (event.getType() == Event.EventType.NodeDeleted) {
            System.out.println("Controller lost. Initiating new controller election...");
            electController();
        }
    }
    public static void electController() {
        try {
            zk.create("/controller", "broker1".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
            System.out.println("Broker1 is now the controller.");
        } catch (KeeperException | InterruptedException e) {
            System.out.println("Controller already exists, waiting for current controller to relinquish...");
        }
    }
    public static void main(String[] args) throws Exception {
        conn = new ZooKeeperConnection();
        zk = conn.connect("localhost");
        zk.register(new ControllerElection());
        electController();
        // Keep application running
        Thread.sleep(Long.MAX_VALUE);
    }
}

输出

说明

与领导者选举类似，Broker 尝试创建临时 znode 来成为控制器。
如果成功，Broker 将承担控制器角色；否则，它将等待当前控制器下线。

4. 元数据管理

ZooKeeper 存储关于 Kafka 主题、分区和配置的关键元数据。Broker 使用这些元数据来同步和管理集群的状态。

示例程序：存储和检索元数据

import org.apache.zookeeper.*;
public class MetadataManagement {
    private static ZooKeeper zk;
    private static ZooKeeperConnection conn;
    public static void main(String[] args) throws Exception {
        conn = new ZooKeeperConnection();
        zk = conn.connect("localhost");
        // Store metadata
        String path = "/brokers/topics/my-topic";
        byte[] data = "metadata information".getBytes();
        zk.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
        System.out.println("Metadata stored successfully.");
        // Retrieve metadata
        byte[] retrievedData = zk.getData(path, false, null);
        System.out.println("Retrieved metadata: " + new String(retrievedData));
        conn.close();
    }
}

输出

说明

与主题或分区相关的元数据被存储在 ZooKeeper 中的持久化 znode 中。
Broker 检索这些元数据以维护对集群状态的一致视图。

5. 配置管理

Kafka Broker 使用 ZooKeeper 来存储可以动态更新的配置设置。这允许 Kafka 在无需重启 Broker 的情况下管理和分发配置更改到整个集群。

示例程序：动态配置更新

import org.apache.zookeeper.*;

public class ConfigManagement {
    private static ZooKeeper zk;
    private static ZooKeeperConnection conn;

    public static void main(String[] args) throws Exception {
        conn = new ZooKeeperConnection();
        zk = conn.connect("localhost");
        String path = "/config/broker/1";
        byte[] data = "num.partitions=3".getBytes();
        zk.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);

        System.out.println("Configuration stored successfully.");

        // Update configuration
        byte[] newData = "num.partitions=5".getBytes();
        zk.setData(path, newData, zk.exists(path, true).getVersion());

        System.out.println("Configuration updated successfully.");

        // Retrieve configuration
        byte[] retrievedData = zk.getData(path, false, null);
        System.out.println("Retrieved configuration: " + new String(retrievedData));

        // Close connection
        conn.close();
    }
}

输出

说明

Kafka 配置存储在 ZooKeeper 中，并且可以动态更新。
Broker 可以在无需重启的情况下检索和应用这些配置。

6. 故障检测和恢复

ZooKeeper 持续监控 Kafka Broker 并检测故障。如果 Broker 发生故障，ZooKeeper 会通知其他 Broker，使它们能够启动恢复过程，例如选举新的领导者或重新分配分区。

示例程序：检测 Broker 故障

import org.apache.zookeeper.*;

public class FailureDetection implements Watcher {
    private static ZooKeeper zk;
    private static ZooKeeperConnection conn;

    public void process(WatchedEvent event) {
        if (event.getType() == Event.EventType.NodeDeleted) {
            System.out.println("Broker failure detected. Taking recovery actions...");
            // Implement recovery logic here
        }
    }

    public static void main(String[] args) throws Exception {
        conn = new ZooKeeperConnection();
        zk = conn.connect("localhost");

        zk.register(new FailureDetection());

        // Register broker
        String path = "/brokers/ids/1";
        byte[] data = "localhost:9092".getBytes();
        zk.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);

        System.out.println("Broker registered successfully.");

        // Simulate broker failure
        zk.delete(path, zk.exists(path, true).getVersion());

        // Keep application running
        Thread.sleep(Long.MAX_VALUE);
    }
}

输出

说明

ZooKeeper 监控 Broker znode，并通过观察临时 znode 的删除来检测故障。
当 Broker znode 被删除时，会触发领导者重选等恢复过程。

ZooKeeper 集群 (ZooKeeper Ensemble)

ZooKeeper 的设计旨在为 Apache Kafka 等分布式系统提供可靠且一致的协调。然而，单个 ZooKeeper 实例可能成为单点故障，这就是为什么在生产环境中通常使用 ZooKeeper 集群来实现高可用性和容错性。在本详细解释中，我们将介绍 ZooKeeper 集群的设置和配置、仲裁 (quorum) 在维护一致性中的作用，以及 ZooKeeper 如何管理数据持久化和快照。

运行多个 ZooKeeper 实例

ZooKeeper 集群是一组协同工作的 ZooKeeper 服务器（通常是奇数）以在所有节点之间维护一致的状态。使用集群的主要原因是：

容错性： 如果一个或多个 ZooKeeper 服务器发生故障，集群中的其余服务器可以继续运行。
高可用性： 只要多数服务器正常运行，集群就可以继续提供服务。
一致性： ZooKeeper 使用共识协议确保集群中的所有节点就系统状态达成一致。

使用 zoo.cfg 配置 ZooKeeper 集群

要配置 ZooKeeper 集群，集群中的每台服务器都必须有一个 zoo.cfg 文件，该文件定义了集群中的服务器及其角色。让我们逐步配置一个三节点的 ZooKeeper 集群。

步骤 1：设置服务器

假设您有三台服务器：zk1、zk2 和 zk3，IP 地址分别为 192.168.1.101、192.168.1.102 和 192.168.1.103。

步骤 2：配置 zoo.cfg 文件

每台服务器都有一个 zoo.cfg 文件，其中应包含以下配置：

# The directory where ZooKeeper will store its data
dataDir=/var/lib/zookeeper

# The port at which the clients will connect
clientPort=2181

# The maximum number of client connections
maxClientCnxns=60

# Time for which the server will wait for client connections
tickTime=2000

# Time taken to allow followers to sync with the leader
initLimit=10

# Time taken to limit the delay between the leader and followers
syncLimit=5

# Server definitions for ensemble members
server.1=192.168.1.101:2888:3888
server.2=192.168.1.102:2888:3888
server.3=192.168.1.103:2888:3888

集群特定参数解释

server.X=IP:2888:3888
- X 是服务器 ID，对于每台服务器都应该是唯一的。
- 2888 是 ZooKeeper 服务器之间用于通信的端口。
- 3888 是用于领导者选举的端口。

步骤 3：创建 myid 文件

集群中的每台 ZooKeeper 服务器都需要一个唯一的标识符，该标识符存储在 myid 文件中。此文件应放置在由 dataDir 指定的目录中（例如 `/var/lib/zookeeper`）。

在 zk1 (192.168.1.101) 上

在 zk2 (192.168.1.102) 上

在 zk3 (192.168.1.103) 上

步骤 4：启动 ZooKeeper 服务器

在各自的机器上启动每个 ZooKeeper 服务器：

通过检查状态来验证每台服务器是否已正确启动：

如果所有服务器都在运行，您的 ZooKeeper 集群现在应该已启动并正常运行。您可以使用 ZooKeeper 客户端 (zkCli.sh) 来验证集群的健康状况和连接性。

2. 仲裁 (Quorum)

ZooKeeper 通过一种称为仲裁 (quorum) 的机制来确保集群中节点之间的一致性。仲裁对于维护系统的可靠性和一致性至关重要，即使在某些服务器发生故障的情况下也是如此。

确保 ZooKeeper 节点之间的一致性

在 ZooKeeper 集群中，仲裁是指必须就系统状态的任何更改达成一致的最小服务器数量。对于 N 台服务器的集群，仲裁通常是 (N/2) + 1。

示例

在 3 节点集群中，仲裁是 2。
在 5 节点集群中，仲裁是 3。

这意味着只要多数（仲裁）服务器正常运行，集群就可以继续服务请求。如果可用服务器少于仲裁数量，集群将无法处理写请求，尽管它仍然可以处理读请求。

多数投票机制

ZooKeeper 使用多数投票机制来确保在提交任何系统状态更改之前，仲裁已就此达成一致。这个过程是 ZooKeeper 用于维护一致性的共识协议的一部分。

领导者选举：当 ZooKeeper 集群启动时，服务器会进行选举以选出领导者。领导者负责处理所有写请求。
跟随者节点：其余服务器是跟随者。它们会复制领导者提出的状态更改。
仲裁协议：对于任何状态更改（例如，配置更新、数据写入），领导者必须获得仲裁数量的跟随者同意。只有在收到多数票后，领导者才会应用更改并通知跟随者。

这种多数投票机制确保了即使某些服务器发生故障，集群仍然可以维护一致的状态。

示例场景

考虑一个 3 节点集群，其中一台服务器发生故障。其余两台服务器仍然可以形成仲裁并继续正常运行。如果第二台服务器发生故障，则会丢失仲裁，集群将无法处理任何写请求，直到至少恢复一台服务器。

为什么选择奇数？

ZooKeeper 集群通常配置为使用奇数台服务器。这是因为奇数台服务器可以在不增加不必要开销的情况下最大化容错能力。

在 3 节点集群中，系统可以容忍 1 次故障（仲裁 = 2）。
在 5 节点集群中，系统可以容忍 2 次故障（仲裁 = 3）。

偶数台服务器需要相同的仲裁大小，但不会增加可容忍的故障数量。

数据持久化和快照

ZooKeeper 在管理数据持久化和快照方面的作用对其从故障中恢复和在集群中维护一致性的能力至关重要。

ZooKeeper 在数据持久化中的作用

ZooKeeper 存储两种类型的数据：

事务日志 (Transaction Logs)
- 这些日志记录了 ZooKeeper 中数据树的每一次更改。每个写操作（例如，创建、删除、更新）都会在事务日志中生成一个新条目。
- 事务日志对于确保持久性至关重要。如果 ZooKeeper 服务器崩溃，它可以回放事务日志来恢复其状态。
快照
- ZooKeeper 会定期拍摄整个数据树的快照，并将其存储在磁盘上。快照代表了特定时间点的系统状态。
- 在启动时，ZooKeeper 服务器会加载最近的快照，然后应用日志中的任何后续事务来重建当前状态。

配置 zoo.cfg 中数据持久化的示例

# Directory where ZooKeeper stores transaction logs
dataLogDir=/var/lib/zookeeper/logs

# Directory where ZooKeeper stores snapshots
dataDir=/var/lib/zookeeper/data

dataLogDir: 指定存储事务日志的目录。
dataDir: 指定存储快照和 myid 文件的目录。

定期快照

ZooKeeper 的定期快照有助于减少恢复期间需要回放的事务日志数据量。快照的频率可以通过 ZooKeeper 的内部机制来控制，但通常无法通过 zoo.cfg 进行配置。

快照触发： ZooKeeper 在处理完一定数量的事务后会自动触发快照。这有助于限制事务日志的大小并加快恢复过程。
快照文件：这些文件通常存储在 dataDir 目录中，命名为 snapshot.X，其中 X 是时间戳或 zxid（ZooKeeper 事务 ID）。

恢复过程

当 ZooKeeper 服务器在崩溃后重启时：

加载快照：它首先从 dataDir 加载最近的快照。
回放事务日志：然后它会回放快照拍摄后发生的日志中的任何事务。这确保了服务器的状态与集群的其余部分保持同步。

集群之间的数据一致性

ZooKeeper 确保集群中的所有服务器以相同的顺序应用相同的事务集。这是通过领导者在管理事务日志和确保跟随者在提交事务之前复制每个事务来实现的。

如果某个服务器落后（例如，由于网络问题或重启），它将通过从领导者或其他跟随者检索最新的快照和事务日志来赶上。

管理事务日志和快照

随着时间的推移，事务日志和快照会累积，占用大量磁盘空间。ZooKeeper 提供了管理这些文件的工具：

清除旧快照和日志
- ZooKeeper 不会自动删除旧快照和日志。您可以使用 zkCleanup.sh 脚本定期清除旧文件：

`-n 3` 标志告诉 ZooKeeper 保留最后 3 个快照和关联的日志。

此脚本应作为 cron 作业运行，以确保旧文件不会占用过多的磁盘空间。

示例 Cron 作业

此 cron 作业每天午夜运行，保留最后三个快照。

Kafka 中的 ZooKeeper 故障和恢复

ZooKeeper 在管理 Kafka 等分布式系统方面发挥着至关重要的作用，尤其是在协调 Broker、维护元数据和确保一致性方面。了解 Kafka 如何处理 ZooKeeper 故障以及如何从这些故障中恢复对于维护健壮且可靠的消息系统至关重要。此外，监控 Kafka 和 ZooKeeper 对于确保持续的性能和健康状况至关重要。本节将深入探讨处理 ZooKeeper 故障、恢复过程以及监控 Kafka 和 ZooKeeper，并附有示例程序和配置。

1. 处理 ZooKeeper 故障

ZooKeeper 是 Kafka 运行的关键，但 Kafka 的设计即使在 ZooKeeper 发生中断时也能保持弹性。让我们探讨 Kafka 如何处理这些故障以及为保持系统稳定性而设的机制。

1.1. Kafka 在处理 ZooKeeper 中断时的弹性

Kafka 依赖 ZooKeeper 进行：

集群元数据管理： ZooKeeper 维护有关 Broker、主题、分区和领导者的信息。
控制器选举： ZooKeeper 选举 Kafka 控制器，该控制器管理分区领导者和副本。
Broker 协调： Broker 使用 ZooKeeper 来发现和相互通信。

鉴于这种依赖性，ZooKeeper 故障可能是灾难性的。然而，Kafka 的设计能够减轻短期 ZooKeeper 中断的影响：

ZooKeeper 中断期间的 Kafka Broker 操作

读操作：即使 ZooKeeper 暂时不可用，Kafka Broker 也可以继续处理读请求（即消费者从分区读取消息）。这是因为 Kafka Broker 本地缓存了分区领导者信息，使其无需不断查询 ZooKeeper 即可提供读服务。
写操作：只要处理写入的 Broker 是分区的领导者，Kafka Broker 也可以在 ZooKeeper 中断期间继续处理写请求（即生产者将消息发送到分区）。分区领导者负责将数据写入日志，并且该领导者信息已缓存在 Broker 上。
中断期间的限制
- 分区重新分配：如果 ZooKeeper 停止工作，Kafka 无法重新分配分区或选举新的领导者。这是因为负责这些任务的控制器需要 ZooKeeper 与 Broker 进行通信。
- 主题创建/删除：涉及更改集群元量的操作，例如创建或删除主题，也依赖于 ZooKeeper。这些操作在 ZooKeeper 中断期间将失败或延迟。

示例场景

短期中断：如果 ZooKeeper 仅中断了很短的时间，Kafka 将继续正常运行，处理读写操作。但是，如果在此期间 Broker 发生故障，Kafka 可能无法为受影响的分区选举新的领导者，直到 ZooKeeper 恢复联机。

Kafka 的故障转移机制

重试：Kafka Broker 将重试因 ZooKeeper 不可用而失败的操作，等待 ZooKeeper 恢复联机。
优雅降级：Kafka 会优雅降级，继续尽力处理请求，直到 ZooKeeper 恢复可用。

1.2. 处理 ZooKeeper 中断

这是一个如何模拟 ZooKeeper 中断并观察 Kafka 行为的示例：

步骤 1：启动 Kafka 和 ZooKeeper

# Start ZooKeeper
bin/zookeeper-server-start.sh config/zookeeper.properties
# Start Kafka broker
bin/kafka-server-start.sh config/server.properties

步骤 2：模拟 ZooKeeper 中断

您可以通过停止 ZooKeeper 服务器来模拟 ZooKeeper 中断：

在此期间，请观察 Kafka Broker 日志：

您应该会看到表明 Kafka Broker 无法连接到 ZooKeeper 的日志条目。尽管如此，Kafka 仍应继续处理现有请求。

步骤 3：恢复 ZooKeeper

短暂延迟后，重新启动 ZooKeeper：

Kafka 应该会自动重新连接到 ZooKeeper，并且任何排队的（例如，分区重新分配）操作都将被处理。

2. 恢复：故障后 Kafka 与 ZooKeeper 同步

当 ZooKeeper 在故障后恢复时，Kafka 必须重新同步以确保集群处于一致状态。本节将解释 Kafka 如何恢复并与 ZooKeeper 同步。

2.1. Kafka 恢复过程

ZooKeeper 中断后，Kafka Broker 会自动尝试重新连接到 ZooKeeper。连接后，会启动几项恢复任务：

领导者重选：如果 ZooKeeper 中断期间任何 Broker 离线，Kafka 将触发受影响分区的领导者重选过程。Kafka 控制器（负责管理分区领导者）确保为失去领导者的每个分区选举新的领导者。
元数据同步：Kafka Broker 会与 ZooKeeper 同步其元数据。这包括有关主题、分区和当前领导者的信息。如果在 ZooKeeper 中断期间发生了任何更改，这些将在重新同步期间进行协调。
控制器恢复：如果 Kafka 控制器本身在 ZooKeeper 中断期间发生故障，将触发新的控制器选举，以确保集群管理任务得以恢复。

示例场景

控制器故障转移：假设 Kafka 控制器在 ZooKeeper 中断期间发生故障。一旦 ZooKeeper 恢复联机，其余 Broker 将检测到控制器丢失并启动新的控制器选举。新选举出的控制器将接管分区领导者和副本同步的管理。

2.2. 示例代码：监控恢复

这是您在 ZooKeeper 中断后监控恢复过程的方法：

步骤 1：启动 Kafka 和 ZooKeeper

确保 Kafka 和 ZooKeeper 都在运行

bin/zookeeper-server-start.sh config/zookeeper.properties
bin/kafka-server-start.sh config/server.properties

步骤 2：模拟故障

停止 Kafka 控制器 Broker：

观察其余 Kafka Broker 的日志：

您应该看到表明控制器已关闭的日志条目。

步骤 3：恢复控制器

重新启动充当控制器的 Kafka Broker：

控制器恢复联机后，您应该会看到表明已选举出新控制器并且分区正在重新同步的日志。

3. 监控 Kafka 和 ZooKeeper

监控对于维护 Kafka 和 ZooKeeper 的健康和性能至关重要。通过跟踪特定指标，您可以在问题变得严重之前识别它们，并确保您的系统平稳运行。

3.1. Kafka 指标

Kafka 通过 Java 管理扩展 (JMX) 提供广泛的指标。这些指标可用于监控 Kafka 性能的各个方面，包括 Broker 活动、消费者滞后和生产者性能。

重要的 Kafka 指标

Broker 指标
- kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec：跟踪每秒传入消息的速率。
- kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec：跟踪每秒传出的字节速率。
- kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions：未完全同步的副本数量（即，副本未全部同步的分区数量）。
消费者指标
- kafka.consumer:type=ConsumerFetcherManager,name=MaxLag：衡量消费者正在获取的任何分区的最大消息滞后。
生产者指标
- kafka.producer:type=producer-metrics,name=record-send-rate：跟踪生产者发送记录的速率。
- kafka.producer:type=producer-metrics,name=record-error-rate：衡量生产者遇到的错误速率。

ZooKeeper 指标

ZooKeeper 还提供了对监控 ZooKeeper 集群健康状况至关重要的指标。这些指标可以通过 `mntr` 命令访问，该命令提供有关服务器健康状况、请求延迟和连接的信息。

重要的 ZooKeeper 指标

延迟
- zk_avg_latency：响应客户端请求的平均时间。
- zk_max_latency：响应请求的最大时间。
服务器状态
- zk_server_state：指示服务器的状态（领导者、跟随者或独立）。
连接
- zk_num_alive_connections：到 ZooKeeper 服务器的活动连接数。

下一主题Kafka 连接器

Kafka 中的 Zookeeper：详细信息

Kafka 中 ZooKeeper 的架构

Kafka 中 ZooKeeper 的特性

1. Broker 协调

2. 领导者选举

3. 控制器选举

4. 元数据管理

5. 配置管理

6. 故障检测和恢复

ZooKeeper 集群 (ZooKeeper Ensemble)

运行多个 ZooKeeper 实例

使用 zoo.cfg 配置 ZooKeeper 集群

2. 仲裁 (Quorum)

确保 ZooKeeper 节点之间的一致性

多数投票机制

示例场景

数据持久化和快照

ZooKeeper 在数据持久化中的作用

定期快照

恢复过程

集群之间的数据一致性

管理事务日志和快照

Kafka 中的 ZooKeeper 故障和恢复

1. 处理 ZooKeeper 故障

1.2. 处理 ZooKeeper 中断

2. 恢复：故障后 Kafka 与 ZooKeeper 同步

3. 监控 Kafka 和 ZooKeeper

ZooKeeper 指标

联系信息

关注我们

教程

面试题

在线编译器

Python

Java

.Net Framework

AI, ML and Data Science

Cloud Technology

B.Tech and MCA

Web Technology

PHP

Software Testing

Technical Interview

Java Interview

Python

Web Interview

Database Interview

B.Tech / MCA

Important Interview

Software Testing Interview

Company Interviews

Online Compilers

Multiple Choice Questions

Kafka 教程

Kafka 安装

Kafka CLI

Kafka 编程

实时示例

Kafka 监控

Kafka Connect

Kafka Streams

杂项

Kafka 中的 Zookeeper：详细信息

Kafka 中 ZooKeeper 的架构

Kafka 中 ZooKeeper 的特性

1. Broker 协调

2. 领导者选举

3. 控制器选举

4. 元数据管理

5. 配置管理

6. 故障检测和恢复

ZooKeeper 集群 (ZooKeeper Ensemble)

运行多个 ZooKeeper 实例

使用 zoo.cfg 配置 ZooKeeper 集群

2. 仲裁 (Quorum)

确保 ZooKeeper 节点之间的一致性

多数投票机制

示例场景

数据持久化和快照

ZooKeeper 在数据持久化中的作用

定期快照

恢复过程

集群之间的数据一致性

管理事务日志和快照

Kafka 中的 ZooKeeper 故障和恢复

1. 处理 ZooKeeper 故障

1.2. 处理 ZooKeeper 中断

2. 恢复：故障后 Kafka 与 ZooKeeper 同步

3. 监控 Kafka 和 ZooKeeper

ZooKeeper 指标

相关帖子

事件驱动架构：Kafka 到 Cosmos DB 集成

Kafka 到 Cosmos DB 故障的死信队列

使用 Kafka 设计容错微服务

使用 Kafka 进行事件驱动的网络安全

Kafka 状态存储

系统迁移中的 Kafka 组件

使用 Kafka 向 Cosmos DB 进行实时流式传输

Apache Kafka vs RabbitMQ

Kafka Hadoop 加载器

使用 Kafka 主题流和 Cosmos DB 进行数据丰富

订阅 Tpoint Tech

联系信息

关注我们

教程

面试题

在线编译器