Kafka的Zookeeper元数据梳理学习笔记-04

Kafka的Zookeeper元数据梳理学习笔记-04

引用

CSDN

1.

https://m.blog.csdn.net/qq_29434541/article/details/144984577

Kafka作为一款高性能、可扩展、可靠的分布式消息系统，其复杂架构设计中，Zookeeper扮演了至关重要的角色。本文将系统梳理Kafka在Zookeeper中存储的元数据及其相关机制，帮助读者深入理解Kafka集群的工作原理。

一、引言

Kafka作为一个高性能、可扩展、可靠的分布式消息系统，其设计旨在满足高吞吐量、低延迟和高可用性的需求。为了实现这些目标，Kafka采用了复杂的架构设计，其中Zookeeper在Kafka集群的管理和协调中扮演了至关重要的角色。本笔记将系统梳理Kafka在Zookeeper中存储的元数据及其相关机制，帮助理解Kafka集群的工作原理。

二、从Zookeeper数据理解Kafka集群工作机制

Kafka依赖Zookeeper来存储和管理集群的状态信息。这种设计将Kafka服务的状态信息与实际的数据存储分离，使得Kafka集群具有良好的扩展性和高可用性。通过Zookeeper，Kafka集群中的各个Broker能够协调一致地管理分区、选举控制器和领导者，从而保证数据的一致性和系统的稳定运行。

三、Kafka的Zookeeper元数据梳理

1. Zookeeper整体数据

Kafka将集群的状态信息保存在Zookeeper中，这些信息包括：

• Broker信息：存储在
  /brokers/ids
  下，记录集群中所有Broker的ID及其相关信息。

• Topic和Partition信息：存储在
  /brokers/topics
  下，记录每个Topic及其分区的状态，包括Leader、副本（Replicas）和同步副本（ISR）。

• 控制器信息：存储在
  /controller
  节点，用于选举集群的Controller Broker。

• 其他管理信息：如删除Topic的操作存储在
  /admin/delete_topic
  下。

这些数据通过Zookeeper的强一致性和Watcher机制，确保集群中所有Broker能够及时感知状态变化，减少频繁读取Zookeeper的开销。

示例结构图：

/brokers
    /ids
        /{brokerId}
    /topics
        /{topicName}
            /partitions
                /{partitionId}
                    /state
/controller
/admin
    /delete_topic

2. Controller Broker选举机制

在Kafka集群启动时，需要选举出一个Broker作为Controller，负责管理集群内的分区和副本状态。选举过程如下：

1. 尝试创建
   /controller
   临时节点：每个Broker启动后，尝试在Zookeeper上创建
   /controller
   临时节点，并将自己的
   brokerId
   写入该节点。

2. 确保唯一性：Zookeeper保证只有一个Broker能成功创建该临时节点，成功创建的Broker即成为Controller。

3. 监控Controller状态：Zookeeper的Watcher机制确保如果Controller Broker宕机，
   /controller
   节点会被删除，其他Broker会感知到这一变化并重新参与Controller的选举。

Controller的职责包括：

• 监听
  /brokers/ids
  和
  /brokers/topics
  的变化，感知Broker和Topic的增减。

• 处理删除Topic的请求。

• 将元数据推送给集群中的其他Broker。

3. Leader Partition选举机制

在Kafka中，每个Topic被划分为多个Partition，每个Partition有多个副本，其中一个副本被选举为Leader，负责处理所有客户端的读写请求，其他副本为Follower，负责同步Leader的数据。

选举机制如下：

1. 副本集（AR）和同步副本集（ISR）：

• AR（Assigned Replicas）：指定的所有副本，包括Leader和Follower。

• ISR（In-Sync Replicas）：与Leader同步且处于健康状态的副本。

2. 选举过程：

• 按照AR中的顺序，优先选择排在前面的副本作为Leader。

• 确保选出的Leader在ISR中，以保证其数据是最新的。

示例命令查看Partition状态：

bin/kafka-topics.sh --bootstrap-server worker1:9092 --describe --topic disTopic

实验示例：

1. 创建一个副本因子为3的Topic。

2. 查看初始Leader分配。

3. 停止一个Broker，观察Leader的重新选举。

4. 重启Broker，手动触发Leader的自动平衡。

4. Leader Partition自动平衡机制

为了防止Leader Partition过于集中在某些Broker上，Kafka引入了自动平衡机制，确保Leader的分布尽可能均衡，从而优化集群的整体性能。

自动平衡的工作原理：

• 理想状态：每个Partition的首选Leader应当是AR中的第一个副本。

• 检测与触发：Controller定期检查Leader分布，如果某个Broker的Leader数量超过预设阈值（
  leader.imbalance.per.broker.percentage
  ），则触发Leader的重新选举，将部分Leader迁移到其他Broker。

关键配置参数：

• auto.leader.rebalance.enable
  ：是否启用自动平衡，默认
  true
  。

• leader.imbalance.check.interval.seconds
  ：自动平衡的检查间隔，默认300秒。

• leader.imbalance.per.broker.percentage
  ：允许的Leader不平衡比例，默认10%。

注意事项：

• 自动平衡过程涉及大量的数据迁移和同步，可能导致短暂的性能下降和数据丢失风险。

• 在线上环境中，建议在业务低峰期手动进行Leader的平衡，以减少对业务的影响。

5. Partition故障恢复机制

在实际运行中，Broker可能会因为网络问题或硬件故障而宕机。Kafka通过以下机制确保Partition的高可用性和数据的一致性：

5.1 Follower故障恢复

当一个Follower发生故障时：

1. 从ISR中移除：故障的Follower会被临时从ISR中移除，剩余的ISR继续正常工作。

2. 恢复后重新加入ISR：

• 恢复的Follower会根据其本地的HW（High Watermark）进行数据恢复。

• 删除高于HW的日志，重新从HW开始同步数据。

• 当其LEO（Log End Offset）赶上HW后，重新加入ISR。

5.2 Leader故障恢复

当Leader Broker宕机时：

1. 选举新Leader：从ISR中选举一个新的Leader。

2. 数据一致性：

• 新Leader的LEO可能低于原Leader，导致部分数据未同步。

• 新Leader将根据自身的LEO更新HW，并通知所有Follower进行数据同步。

3. 数据丢失风险：未同步到新Leader的部分数据可能会丢失。

图示说明：

Leader故障前：
Leader LEO = 100
ISR = {Follower1 LEO=100, Follower2 LEO=95}
Leader故障后：
新Leader = Follower1 LEO=100
HW = 95

结论：Kafka在保证高性能和高可用性的同时，可能在极端情况下牺牲部分数据的安全性。

Kafka设计时要面对的就是各种不稳定的网络以及服务环境。如果Broker的服务不稳定，随时崩溃，Kafka集群要怎么保证数据安全呢？

当一组Partition中选举出了一个Leader节点后，这个Leader节点就会优先写入并保存Producer传递过来的消息，然后再同步给其他Follower。当Leader Partition所在的Broker服务发生宕机时，Kafka就会触发Leader Partition的重新选举。但是，在选举过程中，原来Partition上的数据是如何处理的呢？

Kafka为了保证消息能够在多个Parititon中保持数据同步，内部记录了两个关键的数据：

• LEO(Log End Offset): 每个Partition的最后一个Offset

这个参数比较好理解，每个Partition都会记录自己保存的消息偏移量。leader partition收到并记录了生产者发送的一条消息，就将LEO加1。而接下来，follower partition需要从leader partition同步消息，每同步到一个消息，自己的LEO就加1。通过LEO值，就知道各个follower partition与leader partition之间的消息差距。

• HW(High Watermark): 一组Partiton中最小的LEO。

follower partition每次往leader partition同步消息时，都会同步自己的LEO给leader partition。这样leader partition就可以计算出这个HW值，并最终会同步给各个follower partition。leader partition认为这个HW值以前的消息，都是在所有follower partition之间完成了同步的，是安全的。这些安全的消息就可以被消费者拉取过去了。而HW值之后的消息，就是不安全的，是可能丢失的。这些消息如果被消费者拉取过去消费了，就有可能造成数据不一致。

也就是说，在所有服务都正常的情况下，当一个消息写入到Leader Partition后，并不会立即让消费者感知。而是会等待其他Follower Partition同步。这个过程中就会推进HW。当HW超过当前消息时，才会让消费者感知。比如在上图中，4号往后的消息，虽然写入了Leader Partition，但是消费者是消费不到的。

这跟生产者的acks应答参数是不一样的

当服务出现故障时，如果是Follower发生故障，这不会影响消息写入，只不过是少了一个备份而已。处理相对简单一点。Kafka会做如下处理：

1. 将故障的Follower节点临时提出ISR集合。而其他Leader和Follower继续正常接收消息。

2. 出现故障的Follower节点恢复后，不会立即加入ISR集合。该Follower节点会读取本地记录的上一次的HW，将自己的日志中高于HW的部分信息全部删除掉，然后从HW开始，向Leader进行消息同步。

3. 等到该Follower的LEO大于等于整个Partiton的HW后，就重新加入到ISR集合中。这也就是说这个Follower的消息进度追上了Leader。

如果是Leader节点出现故障，Kafka为了保证消息的一致性，处理就会相对复杂一点。

1. Leader发生故障，会从ISR中进行选举，将一个原本是Follower的Partition提升为新的Leader。这时，消息有可能没有完成同步，所以新的Leader的LEO会低于之前Leader的LEO。

2. Kafka中的消息都只能以Leader中的备份为准。其他Follower会将各自的Log文件中高于HW的部分全部清理掉，然后从新的Leader中同步数据。

3. 旧的Leader恢复后，将作为Follower节点，进行数据恢复。

在这个过程当中，Kafka注重的是保护多个副本之间的数据一致性。但是这样，消息的安全性就得不到保障。例如在上述示例中，原本Partition0中的4，5，6，7号消息就被丢失掉了。

6. HW一致性保障-Epoch更新机制

为了确保在Leader切换后，所有Follower能够正确同步数据，Kafka引入了Epoch机制，用于保证HW的一致性。

Epoch机制工作原理：

1. Epoch定义：一个单调递增的版本号，每当Leader发生变更时，Epoch增加。

2. Epoch记录：

• 每个Leader在接任时，会生成一个新的Epoch，并记录该Epoch的版本号和对应的第一个消息Offset。

• 这些信息保存在
  leader-epoch-checkpoint
  文件中，并同步到所有Follower。

3. 同步过程：

• Follower在与Leader同步数据时，会参考最新的Epoch信息，确保数据同步的起点一致。

• 防止因Leader切换导致的数据不一致问题。

**
leader-epoch-checkpoint
文件示例：**

0
1
29 2485991681

• 第一行：版本号

• 第二行：记录数

• 第三行及之后：
  epoch offset
  ，表示每个Epoch对应的起始Offset

作用：

• 确保数据一致性：通过Epoch机制，确保即使发生Leader切换，Follower也能正确同步数据，避免数据丢失或重复。

• 数据恢复：新Leader在恢复时，根据Epoch信息确定从哪个Offset开始同步数据。

7. 章节总结

本章节系统梳理了Kafka在Zookeeper中存储的元数据及其相关机制，包括Broker信息、Controller选举、Leader Partition选举与自动平衡、Partition故障恢复以及HW一致性保障等。通过这些机制，Kafka能够在复杂多变的运行环境中，保持数据的一致性和系统的高可用性。

核心要点：

• Zookeeper的作用：作为集群的协调者，存储关键的元数据，确保集群中各个Broker的一致性和协调性。

• Controller的职责：集中管理集群的状态，处理分区和副本的分配与管理。

• Leader选举与自动平衡：保证每个Partition有且仅有一个Leader，并通过自动平衡机制优化集群的负载分配。

• 故障恢复机制：通过ISR和Epoch机制，确保在Broker故障时，系统能够迅速恢复并保持数据的一致性。

• 数据一致性保障：通过HW和Epoch机制，确保数据在多个副本之间的一致性和可靠性。

理解这些机制不仅有助于深入掌握Kafka的工作原理，还为日常运维和故障排查提供了理论基础。在实际应用中，结合具体的配置和监控手段，能够更好地发挥Kafka集群的性能和稳定性。