Kafka篇——Kafka集群Controller、Rebalance和HW的详细介绍，保姆级教程！

Controller

一、概念
在Kafka中，Controller是Kafka集群中的一个角色，负责管理集群的元数据、分区分配、副本管理等功能。
Controller的主要职责包括：
1. 元数据管理：Controller负责维护Kafka集群的元数据，包括broker的存活状态、分区的分配情况、副本的分配情况等。它通过与Zookeeper进行交互，监控集群中broker的状态变化，并更新集群的元数据。
通俗的讲，就是当Controller检测到某个分区的ISR集合发生变化时，由Controller负责通知所有Broker更新其元数据信息
2. 分区分配：当有新的topic创建或者有新的broker加入集群时，Controller根据一定的策略来进行分区分配。它会根据集群的负载情况、副本的分布情况等因素，将分区均匀地分配给各个broker。
3. 副本管理：Controller负责管理副本的状态和分配情况。它会监控副本的健康状态，当副本出现故障或离线时，Controller会接管该副本的分区，并重新分配该副本的副本。比如Leader副本挂了，Controller会去查看ISR中存的分区，排在第一位的肯定是上一个Leader副本，后面的是理论上网络状态更优的分区，那么Controller，会将这个分区升级成Leader
4. 集群状态管理：Controller会监控整个集群的状态，并且在集群出现故障或者变化时做出相应的调整。例如，当集群中的broker宕机时，Controller会触发副本重新分配，确保分区的高可用性。

二、Controller选举流程
Kafaka集群在启动的时候，会在Zookeeper中创建一个临时序号节点，序号最小的也就是最先启动的Broker节点，被认定为是Controller，继续管理集群中的相关数据、分区的分配等功能

Rebalance

一、Rebalance机制
Kafka的Rebalance机制是一种自动化的重平衡过程，用于在Consumer Group中的消费者数量或消费的分区数发生变化时重新分配消费者和分区之间的关系。Rebalance机制确保了Consumer Group中的所有消费者能够均匀地分配订阅的主题分区，并保持负载均衡。
当Consumer Group中的消费者数量发生变化，或者消费的分区数发生变化时，Kafka会自动触发Rebalance过程。例如，当某个消费者实例挂掉时，Kafka会自动将该消费者所拥有的分区重新分配给其他消费者实例。同样地，当新加入的消费者实例加入Consumer Group时，Kafka也会重新分配分区给新加入的实例。
Rebalance过程中，消费者无法从Kafka读取消息，因此会对Kafka的TPS（每秒传输的消息量）产生影响。如果Kafka集群中有大量的节点，例如数百个节点，那么重平衡可能会耗时极多，因此应尽量避免在系统高峰期的重平衡发生。
为了优化Rebalance过程，可以通过设置合理的配置参数来控制Rebalance的行为。例如，可以设置max.poll.interval.ms参数来控制消费者在发生Rebalance时等待分区重新分配的最长时间，以避免长时间无法读取消息。
总之，Kafka的Rebalance机制提供了一种自动化的方式来处理Consumer Group中的消费者和分区变化，确保了负载均衡和系统的可用性。

二、Rebalance机制重新分配细节
触发Rebalance机前提：
消费者没有指明分区消费，当消费组里的消费者和分区的关系发生变化，那么就会触发Rebalance机制，这个机制会重新调整消费者消费哪个分区。

在触发Rebalance机制前，消费者在哪个分区消费，有下面3种策略：
1、range范围分配：
在Kafka中，消费者消费分区的策略有多种，其中一种默认的分配策略是Range范围分配。这种策略可以确保每个消费者消费的分区数量是均衡的。
以下是Kafka中Range范围分配的示例公式：
n = 分区数量 / 消费者数量
m = 分区数量 % 消费者数量
前m个消费者消费n+1个分区，剩余消费者消费n个分区。
需要注意的是，Range范围分配策略是针对每个主题（topic）的。要配置消费者的分区分配策略为Range范围分配，需要将消费者的partition.assignment.strategy配置为org.apache.kafka.clients.consumer.RangeAssignor。

2、轮询：轮着消费

3、sticky：在触发Rebalance后，在消费者消费的原分区不变的基础上进行调整，不会改变之前的分配。如果这个策略没有开，那么就要全部进行重新分配，非常消耗性能，建议开启

HW

一、HW介绍
在Kafka中，HW（High Watermark）“高水位”是一个关键概念，用于表示消息复制的进度。具体来说，HW表示已经成功复制到所有副本的消息的位置。
HW之前的所有消息都被认为是已提交的消息，这意味着消费者可以安全地消费这些消息。消费者最多只能消费到HW所在的位置，另外每个副本都有HW，
Leader和Follower各自更新自己的HW状态，对于Leader重新写入消息，消费者不能立即消费，Leader会等待该消息被所有ISR中的副本同步并更新HW，
此时消息才能被消费者消费。这样就保证了如果Leader所在的Broker失效挂掉了，不会在新的Leader副本中重复消费

二、HW图示

根据上图所示，为了防止消息丢失，保证消费者的安全消费。只有当Leader副本将消息同步到其他所有的副本后，HW才会下移动，才能消费到第5条消息，
否则只能消费到第4条消息

LEO

Kafka中的LEO（Log End Offset）表示当前日志文件中下一条待写入消息的offset。每个partition的log最后一条Message的位置都会有一个LEO。它用于标识消息追加到文件的最后位置。
此外，LEO还是Log End Offset的缩写，用于标识当前副本中最后一条消息的offset。当生产者向Leader副本追加消息时，Leader副本的LEO标记会增加；当Follower副本成功从Leader副本拉取消息并更新到本地时，Follower副本的LEO也会增加。

至此，关于Kafka的常见关键技术点介绍完毕，知识点较多，希望大家能够反复学习，常学常新奥！