当前位置： 首页 > article >正文

【小红书一面】Kafka 是如何选择 Leader的？

article 2024/10/24 15:12:39

👉博主介绍： 博主从事应用安全和大数据领域，有8年研发经验，5年面试官经验，Java技术专家，WEB架构师，阿里云专家博主，华为云云享专家，51CTO 专家博主

⛪️ 个人社区：个人社区
💞 个人主页：个人主页
🙉 专栏地址： ✅ Java 中级
🙉八股文专题：剑指大厂，手撕 Java 八股文
在这里插入图片描述

文章目录

      • 1. Kafka集群整体架构？
      • 2. Controller的作用？
        • 2.1. 集群元数据管理
        • 2.2. 故障检测与恢复
        • 2.3. 负载均衡
        • 2.4. 配置管理
        • 2.5. 协调 Zookeeper 操作
        • 2.6. 日志清理和保留策略
        • 2.7. 安全性管理
      • 3. 选主的原理分析
        • 3.1.选主流程
        • 3.2.详细步骤
        • 3.3.选举过程中的注意事项
      • 4. Controller选举机制详解
        • 4.1. Zookeeper 的作用
        • 4.2. 选举流程
        • 4.3. 选举过程中的关键步骤
      • 5. 分区Leader选举详解
        • 5.1.分区Leader选举的背景
        • 5.2.分区Leader选举的流程
        • 5.3.详细步骤
        • 5.4.选举策略
      • 6. 用 java 模拟写一个 Controller 选举的代码案例
        • 6.1.代码示例
        • 6.2.代码解释
        • 6.3.注意事项

1. Kafka集群整体架构？

Apache Kafka 是一个分布式流处理平台，广泛用于构建实时数据管道和流应用。Kafka 的设计目标是提供高吞吐量、可扩展性和容错性。下面是 Kafka 集群的整体架构及其主要组件的详细介绍：

主要组件

  1. Broker：

    • Kafka 集群由多个 Broker 组成，每个 Broker 是一个独立的 Kafka 服务器。
    • Broker 负责存储和管理 Topic 中的消息。
    • 每个 Broker 都有一个唯一的 ID，并且可以处理来自 Producer 和 Consumer 的请求。

  2. Topic：

    • Topic 是消息的类别或主题，类似于数据库中的表。
    • 每个 Topic 可以被分成多个 Partition，每个 Partition 是一个有序的、不可变的消息序列。
    • 每个 Partition 可以分布在不同的 Broker 上，从而实现负载均衡和水平扩展。

  3. Partition：

    • Partition 是 Topic 的物理分割，每个 Partition 是一个有序的、不可变的消息队列。
    • 每个 Partition 在一个 Broker 上有副本（Replica），以实现容错和高可用性。
    • 消息在 Partition 内是按顺序存储的，但不同 Partition 之间的消息是无序的。

  4. Producer：

    • Producer 是负责发布消息到 Kafka Topic 的客户端应用程序。
    • Producer 可以将消息发送到指定的 Partition 或者让 Kafka 自动分配 Partition。
    • Producer 可以配置各种参数来控制消息的发送行为，如批处理大小、压缩等。

  5. Consumer：

    • Consumer 是负责从 Kafka Topic 订阅并消费消息的客户端应用程序。
    • 多个 Consumer 可以组成一个 Consumer Group，组内的每个 Consumer 会订阅 Topic 的不同 Partition。
    • Consumer Group 保证每个 Partition 只被组内的一个 Consumer 消费，从而实现负载均衡。

  6. Zookeeper：

    • Zookeeper 是一个分布式协调服务，Kafka 使用它来管理和协调集群中的 Broker。
    • Zookeeper 保存了集群的元数据信息，如 Broker 列表、Topic 的 Partition 分配、Leader 选举等。
    • 在较新的 Kafka 版本中（0.11.0.0 及以上），Kafka 已经支持不依赖 Zookeeper 运行的模式（KIP-500）。

  7. Offset：

    • Offset 是 Partition 中每条消息的唯一标识符，表示消息在 Partition 中的位置。
    • Consumer 通过记录和提交 Offset 来跟踪其消费进度。
    • Offset 可以存储在 Zookeeper 或 Kafka 内部的主题（如 __consumer_offsets）中。

架构图

以下是一个简化的 Kafka 集群架构图：

+-------------------+       +-------------------+       +-------------------+
|    Producer 1     |       |    Producer 2     |       |    Producer 3     |
+-------------------+       +-------------------+       +-------------------+
         |                         |                         |
         v                         v                         v
+-------------------+       +-------------------+       +-------------------+
|      Broker 1     |<----->|      Broker 2     |<----->|      Broker 3     |
| (Leader for P1)   |       | (Leader for P2)   |       | (Leader for P3)   |
+-------------------+       +-------------------+       +-------------------+
         |                         |                         |
         v                         v                         v
+-------------------+       +-------------------+       +-------------------+
|    Topic: T1      |       |    Topic: T2      |       |    Topic: T3      |
|  Partition 1 (P1) |       |  Partition 1 (P2) |       |  Partition 1 (P3) |
+-------------------+       +-------------------+       +-------------------+
         |                         |                         |
         v                         v                         v
+-------------------+       +-------------------+       +-------------------+
|    Consumer 1     |       |    Consumer 2     |       |    Consumer 3     |
|  (Group G1, P1)   |       |  (Group G1, P2)   |       |  (Group G1, P3)   |
+-------------------+       +-------------------+       +-------------------+

关键特性

  • 高吞吐量：Kafka 通过批量处理、压缩和零拷贝技术实现了高吞吐量的消息传递。
  • 持久化存储：Kafka 将消息持久化到磁盘，并且支持配置消息保留策略（如基于时间或空间）。
  • 水平扩展：通过增加 Broker 和 Partition 数量，Kafka 可以轻松地进行水平扩展。
  • 容错性：通过多副本机制，Kafka 提供了高可用性和容错性。即使部分 Broker 故障，系统仍能继续运行。
  • 消费者组：Consumer Group 机制允许多个 Consumer 协同工作，共同消费 Topic 中的消息，实现负载均衡。

Kafka 的整体架构设计旨在提供一个高性能、可扩展和容错的分布式消息系统。通过 Broker、Topic、Partition、Producer、Consumer 和 Zookeeper 等组件的协同工作，Kafka 能够高效地处理大规模的数据流，并支持多种应用场景，如日志聚合、事件驱动架构、实时分析等。

2. Controller的作用？

在 Apache Kafka 中，Controller 是一个非常重要的组件，它负责管理和协调整个 Kafka 集群的状态。Controller 的主要作用包括但不限于以下几点：

2.1. 集群元数据管理
  • Topic 和 Partition 管理：Controller 负责管理 Topic 和 Partition 的创建、删除和重新分配。
  • Broker 注册与注销：当 Broker 启动或关闭时，Controller 会更新集群的元数据信息，确保所有 Broker 的状态是最新的。
  • Leader 选举：Controller 负责在 Broker 故障时进行 Leader 选举，确保每个 Partition 有一个有效的 Leader。
2.2. 故障检测与恢复
  • Broker 故障检测：Controller 通过心跳机制检测 Broker 的存活状态。如果某个 Broker 在一段时间内没有发送心跳，Controller 会认为该 Broker 已经宕机，并触发相应的恢复操作。
  • Leader 重新选举：当检测到某个 Broker 宕机时，Controller 会为该 Broker 上的所有 Leader Partition 重新选举新的 Leader。
  • ISR（In-Sync Replicas）管理：Controller 负责维护每个 Partition 的 ISR 列表，确保只有同步的副本才能成为新的 Leader。
2.3. 负载均衡
  • Partition 重新分配：Controller 可以根据集群的负载情况，重新分配 Partition 以实现负载均衡。这通常是在 Broker 加入或离开集群时进行的。
  • Broker 间的数据迁移：为了平衡集群中的负载，Controller 可能会将某些 Partition 从一个 Broker 迁移到另一个 Broker。
2.4. 配置管理
  • 动态配置更新：Controller 负责处理集群配置的动态更新，例如 Topic 的配置变更、Broker 的配置变更等。
  • 配置传播：Controller 会将最新的配置信息传播给所有的 Broker，确保整个集群的一致性。
2.5. 协调 Zookeeper 操作
  • Zookeeper 交互：虽然较新的 Kafka 版本（如 3.0.0 及以上）已经支持不依赖 Zookeeper 的模式（KIP-500），但在旧版本中，Controller 仍然需要与 Zookeeper 交互来存储和读取集群的元数据信息。
  • Watch 机制：Controller 会在 Zookeeper 中设置 Watch 来监听集群状态的变化，从而能够及时响应这些变化。
2.6. 日志清理和保留策略
  • 日志保留策略：Controller 会根据配置的日志保留策略（如基于时间或空间）来管理日志文件的清理工作。
  • 日志压缩：对于启用了日志压缩的 Topic，Controller 会协调 Broker 执行日志压缩操作。
2.7. 安全性管理
  • 权限控制：Controller 会处理与安全相关的操作，如 ACL（Access Control List）的管理，确保只有授权的用户可以访问特定的资源。

Controller 是 Kafka 集群的核心组件之一，它负责管理集群的元数据、协调 Broker 之间的通信、处理故障恢复、维护数据一致性以及执行各种管理和配置任务。通过这些功能，Controller 确保了 Kafka 集群的高可用性、一致性和可扩展性。在实际运行中，Controller 通常由集群中的一个 Broker 担任，这个 Broker 会在启动时通过选举机制确定。如果当前的 Controller 宕机，其他 Broker 会重新选举一个新的 Controller 来接管其职责。

3. 选主的原理分析

在 Apache Kafka 中，Controller 的选主过程是确保集群高可用性和一致性的关键机制。Kafka 通过 Zookeeper 来管理和协调 Controller 的选举。以下是 Kafka Controller 选主的详细原理分析：

3.1.选主流程

  1. 初始化阶段：

    • 每个 Broker 在启动时会尝试成为 Controller。
    • Broker 会在 Zookeeper 中创建一个临时节点 /controller，并写入自己的 Broker ID。
    • 创建这个临时节点的操作是原子的，只有一个 Broker 能成功创建这个节点，从而成为 Controller。

  2. Zookeeper 通知机制：

    • 成功创建 /controller 节点的 Broker 会成为新的 Controller。
    • 其他 Broker 会监听 /controller 节点的变化。如果当前 Controller 宕机或主动放弃控制权，该节点会被删除。
    • 当 /controller 节点被删除时，其他 Broker 会收到通知，并重新开始新一轮的选举。

  3. 重新选举：

    • 收到通知的 Broker 会再次尝试创建 /controller 节点。
    • 只有一个 Broker 会成功创建这个节点，从而成为新的 Controller。
    • 新的 Controller 会读取 Zookeeper 中的集群状态信息，并接管之前 Controller 的职责。
3.2.详细步骤

  1. Broker 启动：

    • 每个 Broker 在启动时会连接到 Zookeeper。
    • Broker 会检查 Zookeeper 中是否存在 /controller 节点。

  2. 尝试成为 Controller：

    • 如果 /controller 节点不存在，Broker 会尝试创建这个节点。
    • 创建节点时，Broker 会写入自己的 Broker ID 和一些初始状态信息。
    • 创建节点的操作是原子的，只有第一个尝试的 Broker 会成功。

  3. 成为 Controller：

    • 成功创建 /controller 节点的 Broker 会成为新的 Controller。
    • Controller 会读取 Zookeeper 中的集群元数据（如 Topic、Partition、ISR 等）。
    • Controller 会监听 Broker 的注册和注销事件，以及 Partition 的 Leader 选举事件。

  4. 监听节点变化：

    • 其他 Broker 会监听 /controller 节点的变化。
    • 如果当前 Controller 宕机或主动放弃控制权，/controller 节点会被删除。
    • 监听节点的 Broker 会收到通知，并重新开始新一轮的选举。

  5. 重新选举：

    • 收到通知的 Broker 会再次尝试创建 /controller 节点。
    • 只有一个 Broker 会成功创建这个节点，从而成为新的 Controller。
    • 新的 Controller 会读取 Zookeeper 中的集群状态信息，并接管之前的职责。

  6. 接管职责：

    • 新的 Controller 会更新 Zookeeper 中的集群元数据。
    • Controller 会处理 Broker 的注册和注销事件，以及 Partition 的 Leader 选举事件。
    • Controller 会确保集群的一致性和高可用性。
3.3.选举过程中的注意事项
  • 唯一性：由于 /controller 节点是临时节点，且创建操作是原子的，因此只有一个 Broker 能成功创建这个节点。
  • 一致性：通过 Zookeeper 的 Watch 机制，所有 Broker 都能及时感知到 Controller 的变化，并进行相应的处理。
  • 容错性：即使当前的 Controller 宕机，其他 Broker 也能快速检测到并重新选举新的 Controller，保证集群的连续运行。

Kafka 的 Controller 选主过程依赖于 Zookeeper 的临时节点和 Watch 机制。通过这些机制，Kafka 能够在 Broker 故障时迅速选出新的 Controller，确保集群的高可用性和一致性。这个过程是自动化的，不需要人工干预，从而简化了集群管理的复杂性。

4. Controller选举机制详解

在 Apache Kafka 中，Controller 选举机制是确保集群高可用性和一致性的关键部分。Controller 负责管理集群的元数据、协调 Broker 之间的通信、处理故障恢复等重要任务。下面是 Kafka Controller 选举机制的详细解释：

4.1. Zookeeper 的作用

Kafka 使用 Zookeeper 来进行 Controller 选举和存储集群的元数据。Zookeeper 提供了以下功能来支持 Controller 选举：

  • 临时节点：Broker 会在 Zookeeper 中创建一个临时节点 /controller。
  • Watch 机制：其他 Broker 会监听这个临时节点的变化，以便在当前 Controller 失效时能够及时感知并重新选举新的 Controller。
4.2. 选举流程

启动阶段

  1. Broker 启动：

    • 每个 Broker 在启动时会连接到 Zookeeper。
    • Broker 会检查 Zookeeper 中是否存在 /controller 节点。

  2. 尝试成为 Controller：

    • 如果 /controller 节点不存在，Broker 会尝试创建这个临时节点。
    • 创建节点时，Broker 会写入自己的 Broker ID 和一些初始状态信息。
    • 创建节点的操作是原子的，只有第一个尝试的 Broker 会成功。

  3. 成为 Controller：

    • 成功创建 /controller 节点的 Broker 会成为新的 Controller。
    • Controller 会读取 Zookeeper 中的集群元数据（如 Topic、Partition、ISR 等）。
    • Controller 会监听 Broker 的注册和注销事件，以及 Partition 的 Leader 选举事件。

监听节点变化

  1. 其他 Broker 监听：
    • 其他 Broker 会监听 /controller 节点的变化。
    • 如果当前 Controller 宕机或主动放弃控制权，/controller 节点会被删除。
    • 监听节点的 Broker 会收到通知，并重新开始新一轮的选举。

重新选举

  1. 收到通知：

    • 收到通知的 Broker 会再次尝试创建 /controller 节点。
    • 只有一个 Broker 会成功创建这个节点，从而成为新的 Controller。

  2. 接管职责：

    • 新的 Controller 会读取 Zookeeper 中的集群状态信息，并接管之前的职责。
    • Controller 会更新 Zookeeper 中的集群元数据。
    • Controller 会处理 Broker 的注册和注销事件，以及 Partition 的 Leader 选举事件。
    • Controller 会确保集群的一致性和高可用性。
4.3. 选举过程中的关键步骤

创建临时节点

  • 原子操作：创建 /controller 节点是一个原子操作，只有第一个尝试的 Broker 会成功。
  • 临时节点：这个节点是临时节点，如果创建该节点的 Broker 宕机，节点会自动被删除。

监听节点变化

  • Watch 机制：Broker 通过 Zookeeper 的 Watch 机制监听 /controller 节点的变化。
  • 通知机制：当 /controller 节点被删除时，所有监听的 Broker 会收到通知，触发重新选举。

重新选举

  • 竞争创建：多个 Broker 会同时尝试创建 /controller 节点，只有一个 Broker 会成功。
  • 接管职责：新的 Controller 会接管之前 Controller 的职责，包括管理集群元数据和协调 Broker 之间的通信。

容错性与一致性

  • 容错性：即使当前的 Controller 宕机，其他 Broker 也能快速检测到并重新选举新的 Controller，保证集群的连续运行。
  • 一致性：通过 Zookeeper 的 Watch 机制，所有 Broker 都能及时感知到 Controller 的变化，并进行相应的处理，确保集群的一致性。

Kafka 的 Controller 选举机制依赖于 Zookeeper 的临时节点和 Watch 机制。通过这些机制，Kafka 能够在 Broker 故障时迅速选出新的 Controller，确保集群的高可用性和一致性。具体步骤如下：

  1. 启动阶段：每个 Broker 尝试创建 /controller 临时节点，只有第一个尝试的 Broker 会成功。
  2. 监听节点变化：其他 Broker 通过 Watch 机制监听 /controller 节点的变化。
  3. 重新选举：如果当前 Controller 宕机，其他 Broker 会收到通知并重新选举新的 Controller。

这种机制确保了 Kafka 集群在面对 Broker 故障时能够快速恢复，并保持集群的稳定运行。

5. 分区Leader选举详解

在 Apache Kafka 中，分区（Partition）的 Leader 选举是确保数据一致性和高可用性的关键机制。Leader 负责处理该分区的所有读写请求，并将数据复制到其他副本（Replicas）。当 Leader 宕机或不可用时，需要从剩余的副本中选举一个新的 Leader 来继续提供服务。下面是 Kafka 分区 Leader 选举的详细过程：

5.1.分区Leader选举的背景
  • ISR（In-Sync Replicas）：Kafka 维护了一个 ISR 列表，其中包含与 Leader 保持同步的所有副本。只有 ISR 中的副本才有资格被选为新的 Leader。
  • Controller：Kafka 集群中的 Controller 负责管理和协调 Leader 选举过程。
5.2.分区Leader选举的流程

  1. 检测 Leader 故障：

    • 当某个 Broker 宕机或变得不可用时，Controller 会通过心跳机制或其他方式检测到这个故障。
    • Controller 会标记该 Broker 上所有 Leader Partition 为无 Leader 状态。

  2. 选择候选副本：

    • Controller 会查看受影响 Partition 的 ISR 列表，从中选择一个合适的副本作为新的 Leader。
    • 通常情况下，会选择 ISR 列表中的第一个副本作为新的 Leader，但具体策略可以配置。

  3. 更新元数据：

    • Controller 会在 Zookeeper 中更新受影响 Partition 的元数据，设置新的 Leader。
    • Controller 还会更新 Broker 的元数据，确保所有 Broker 都知道新的 Leader。

  4. 通知 Broker：

    • Controller 会向所有 Broker 发送 LeaderAndIsrRequest 请求，通知它们新的 Leader 信息。
    • Broker 会更新自己的本地状态，确保后续的读写请求能够正确路由到新的 Leader。

  5. 恢复服务：

    • 新的 Leader 开始处理读写请求，并继续将数据复制到其他副本。
    • 如果有新的 Broker 加入集群，或者原来的 Leader 恢复，Controller 会根据当前情况重新调整 ISR 和 Leader。
5.3.详细步骤

  1. 检测 Leader 故障：

    • 心跳机制：每个 Broker 会定期向 Controller 发送心跳消息。如果 Controller 在一段时间内没有收到某个 Broker 的心跳，它会认为该 Broker 已经宕机。
    • Zookeeper 监听：Controller 也会监听 Zookeeper 中的 Broker 注册信息。如果某个 Broker 的注册信息被删除，Controller 会认为该 Broker 不可用。

  2. 选择候选副本：

    • ISR 列表：Controller 会查看受影响 Partition 的 ISR 列表，从中选择一个合适的副本作为新的 Leader。
    • 优先级：通常情况下，会选择 ISR 列表中的第一个副本作为新的 Leader。这是因为 ISR 列表中的第一个副本通常是最新且最完整的副本。

  3. 更新元数据：

    • Zookeeper 更新：Controller 会在 Zookeeper 中更新受影响 Partition 的元数据，设置新的 Leader。
    • Broker 元数据更新：Controller 会向所有 Broker 发送 LeaderAndIsrRequest 请求，更新 Broker 的本地元数据。

  4. 通知 Broker：

    • LeaderAndIsrRequest：Controller 会向所有 Broker 发送 LeaderAndIsrRequest 请求，通知它们新的 Leader 信息。
    • 本地状态更新：Broker 会更新自己的本地状态，确保后续的读写请求能够正确路由到新的 Leader。

  5. 恢复服务：

    • 处理读写请求：新的 Leader 开始处理读写请求，并继续将数据复制到其他副本。
    • ISR 调整：如果有新的 Broker 加入集群，或者原来的 Leader 恢复，Controller 会根据当前情况重新调整 ISR 和 Leader。
5.4.选举策略

Kafka 提供了几种不同的 Leader 选举策略，可以通过配置来选择：

  • 默认策略：选择 ISR 列表中的第一个副本作为新的 Leader。
  • 最小索引策略：选择 ISR 列表中索引最小的副本作为新的 Leader。
  • 随机策略：从 ISR 列表中随机选择一个副本作为新的 Leader。
  • 自定义策略：用户可以实现自定义的 Leader 选举策略，以满足特定的需求。

Kafka 的分区 Leader 选举机制通过 Controller 的协调和 Zookeeper 的元数据管理，确保了在 Leader 故障时能够快速选出新的 Leader 并恢复服务。选举过程包括检测故障、选择候选副本、更新元数据、通知 Broker 和恢复服务等步骤。这种机制保证了 Kafka 集群的高可用性和一致性。

6. 用 java 模拟写一个 Controller 选举的代码案例

下面是一个简化的 Java 代码示例，模拟 Kafka Controller 选举的过程。这个示例使用了 Zookeeper 来进行 Controller 选举，并展示了如何创建临时节点、监听节点变化以及重新选举新的 Controller。

首先，确保你已经添加了 Zookeeper 的依赖到你的项目中。如果你使用 Maven，可以在 pom.xml 中添加以下依赖：

<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.7.0</version>
</dependency>
6.1.代码示例
import org.apache.zookeeper.*;
import org.apache.zookeeper.data.Stat;

import java.io.IOException;
import java.util.concurrent.CountDownLatch;

public class KafkaControllerElection {

    private static final String ZK_ADDRESS = "localhost:2181"; // Zookeeper 地址
    private static final String CONTROLLER_PATH = "/controller"; // Controller 节点路径
    private static final int SESSION_TIMEOUT = 5000; // 会话超时时间 (毫秒)

    public static void main(String[] args) throws IOException, InterruptedException, KeeperException {
        // 创建 Zookeeper 客户端
        ZooKeeper zk = new ZooKeeper(ZK_ADDRESS, SESSION_TIMEOUT, event -> {
            if (event.getState() == Watcher.Event.KeeperState.SyncConnected) {
                System.out.println("Zookeeper 连接成功");
                try {
                    electController(zk);
                } catch (InterruptedException | KeeperException e) {
                    e.printStackTrace();
                }
            } else if (event.getType() == Watcher.Event.EventType.NodeDeleted) {
                System.out.println("检测到 Controller 节点被删除，重新选举...");
                try {
                    electController(zk);
                } catch (InterruptedException | KeeperException e) {
                    e.printStackTrace();
                }
            }
        });

        // 等待连接完成
        CountDownLatch connectedSignal = new CountDownLatch(1);
        zk.exists("/", false, (event, rc, path, ctx) -> {
            if (rc == KeeperException.Code.Ok) {
                connectedSignal.countDown();
            }
        });
        connectedSignal.await();

        // 保持主线程运行
        Thread.sleep(Long.MAX_VALUE);
    }

    private static void electController(ZooKeeper zk) throws KeeperException, InterruptedException {
        // 尝试创建 Controller 节点
        String controllerNode = zk.create(CONTROLLER_PATH, "Controller".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);

        if (controllerNode != null) {
            System.out.println("成为新的 Controller: " + controllerNode);
            // 成为 Controller 后的处理逻辑
            // 例如：读取集群元数据、监听 Broker 注册和注销事件等
        } else {
            // 如果创建失败，说明已经有其他 Broker 成为了 Controller
            System.out.println("已有 Controller 存在，等待重新选举...");
            // 监听 Controller 节点的变化
            zk.exists(CONTROLLER_PATH, true, (event, rc, path, ctx) -> {});
        }
    }
}
6.2.代码解释

  1. ZooKeeper 客户端初始化：

    • 使用 ZooKeeper 构造函数创建一个客户端实例，并传入一个 Watcher 用于监听连接状态和节点变化。
    • 使用 CountDownLatch 确保客户端与 Zookeeper 服务器连接成功后再继续执行后续操作。

  2. 选举 Controller：

    • 在 electController 方法中，尝试创建一个临时节点 /controller。
    • 如果创建成功，说明当前 Broker 成为了新的 Controller，并可以开始执行 Controller 的职责。
    • 如果创建失败（即节点已存在），则设置一个 Watcher 来监听该节点的变化，以便在当前 Controller 失效时重新进行选举。

  3. 监听节点变化：

    • 当检测到 /controller 节点被删除时，触发重新选举过程。

  4. 保持主线程运行：

    • 使用 Thread.sleep(Long.MAX_VALUE) 保持主线程运行，以防止程序退出。
6.3.注意事项
  • 实际应用：这个示例是一个简化的版本，实际生产环境中需要处理更多的细节，如异常处理、日志记录、配置管理等。
  • 高可用性：在实际的 Kafka 集群中，Controller 选举和管理是非常复杂的，涉及到多种情况和优化策略。
  • Zookeeper 版本：确保使用的 Zookeeper 版本与 Kafka 兼容。

精彩专栏推荐订阅：在下方专栏👇🏻
✅ 2023年华为OD机试真题（A卷&B卷）+ 面试指导
✅ 精选100套 Java 项目案例
✅ 面试需要避开的坑（活动）
✅ 你找不到的核心代码
✅ 带你手撕 Spring
✅ Java 初阶

在这里插入图片描述


http://www.kler.cn/news/363146.html

相关文章：

  • 【传知代码】智能推荐与隐私保护的融合（论文复现）
  • 游戏界面设计的最佳实践
  • SIP 业务举例之 三方通话：邀请第三方加入的信令流程
  • 面试总结一
  • 后端C++
  • 【MySQL】详解MySQL数据类型
  • Unity目录居然这么写就不会被引入到项目内
  • python第五次作业
  • 手机怎么玩GTA5？GameViewer远程助你手机畅玩GTA5侠盗飞车
  • 【RoadRunner】自动驾驶模拟3D场景构建 | 软件简介与视角控制
  • etl-查询错误log日志和oracle删除数据表空间
  • ansible一键部署k8s集群
  • 20241024-帖子发布
  • Ollama
  • git 工作环境恢复到上次提交
  • node.js 的顶级对象
  • spring中的枚举类型转换
  • 人工智能需要学哪些课程?
  • ＜大厂实战经验＞ Flutter鸿蒙next 中使用 initState 和 mounted 处理异步请求的详细解析
  • java文件分片与合并：RandomAccessFile+FileInputStream+FileOutputStream
  • 【性能优化】安卓性能优化之CPU优化
  • 【设计模式系列】观察者模式
  • 3D虚拟服装试穿技术：迈向元宇宙与AR电商的新时代
  • 鼠标移入盒子，盒子跟随鼠标移动
  • word，exl，txt转pdf
  • HttpOnly Cookie