主节点（Leader）宕机时会发生什么？

当 Kafka 集群中的某个 Leader 节点宕机时，Kafka 会自动触发故障恢复机制，以确保集群的高可用性：

1.故障检测

• Kafka 通过 ZooKeeper 的 Watcher 机制检测到 Leader 节点宕机。
• Kafka 控制器（Controller）会收到通知，并开始处理故障。

2.选举新的 Leader

• Kafka 控制器会在 ISR（In-Sync Replicas）集合中选择一个新的 Leader。
• 新 Leader 的选择遵循以下规则：
  • 优先选择 AR（Assigned Replicas）列表中靠前且在 ISR 中的副本。
  • 确保新 Leader 的 LEO（Log End Offset）尽可能接近原 Leader 的 LEO。

3.数据一致性处理

• 新 Leader 会根据 ISR 中所有副本的 LEO 计算新的 HW（High Watermark），HW 是 ISR 中最小的 LEO。
• 新 Leader 会清理高于 HW 的数据，确保数据一致性。
• 新 Leader 通知所有 Follower 从 HW 开始同步数据。

4.对消费者和生产者的影响

• 消费者：消费者会收到通知，自动切换到新的 Leader，继续读取消息。
• 生产者：生产者会重新连接到新的 Leader，继续发送消息。
• 数据丢失风险：在极端情况下，可能会丢失未同步到所有副本的部分数据。

主节点（Leader）恢复时会发生什么？

当宕机的 Leader 节点恢复后，Kafka 会进行以下操作：

1.数据同步

• 恢复的 Leader 节点会检查其本地存储的 HW 值。
• 如果其 LEO 超过 HW，表示其可能持有未同步的数据，Kafka 会指示该节点删除高于 HW 的消息。
• 该节点会从新的 Leader 处拉取 HW 之后的数据，重新同步。

2.重新加入 ISR

• 当该节点的 LEO 达到或超过 HW 后，Kafka 会将其重新加入 ISR。
• 此时，该节点可以作为数据同步的参与者，继续提供服务。

3.对集群的影响

• 恢复的 Leader 节点不会重新成为 Leader，而是作为 Follower 继续同步数据。
• 集群的读写操作继续由新的 Leader 节点处理。

总结

• Leader 宕机时：Kafka 会自动选举新的 Leader，并清理数据以确保一致性，消费者和生产者会自动切换到新的 Leader。
• Leader 恢复时：恢复的节点会重新同步数据并加入 ISR，但不会重新成为 Leader。
• 数据丢失风险：在 Leader 切换过程中，可能会丢失未同步到所有副本的部分数据。