分区机制

Kafka 的分区机制是其实现高吞吐和可扩展性的重要特性之一。

Kafka 中的数据具有三层结构，即主题（topic）-> 分区（partition）-> 消息（message）。一个 Kafka 主题可以包含多个分区，而每个分区又可以包含多条消息。

Topic和Partition是kafka中比较重要的概念。

• 主题:Topic是Kafka中承载消息的逻辑容器。可以理解为一个消息队列。生产者将消息发送到特定的Topic，消费者从Topic中读取消息。Topic可以被认为是逻辑上的消息流。在实际使用中多用来区分具体的业务。
• 分区:Partition。是Topic的物理分区。一个Topic可以被分成多个Partition，每个Partition是一个有序且持久化存储的日志文件。每个Partition都存储了一部分消息，并且有一个唯一的标识符(称为Partition ID)。

好处：

1. 提升吞吐量：通过将一个Topic分成多个Partition，可以实现消息息的并行处理。每个Partition可以由不同的消费者组进行独立消费,这样就可以提高整个系统的吞吐量。
2. 负载均衡：Partition的数量通常比消费者组的数量多，这样可以使每个消费者组中的消费者均匀地消费消息。当有新的消费者加入或离开消费者组时，可以通过重新分配Partition的方式进行负载均衡。
3. 扩展性：通过增加Partition的数量，可以实现Kafka集群的广展性。更多的Partition可以提供更高的并发处理能力和更大的存储容量。

重平衡机制

Kafka的重平衡机制是指在消费者组中新增或删除消费者时，Kafka集群会重新分配主题分区给各个消费者，以保证每个消费者消费的分区数量尽可能均衡。

重平衡机制的目的是实现消费者的负载均衡和高可用性，以确保每个消费者都能够按照预期的方式消费到消息。

重平衡的3个触发条件:

1. 消费者组成员数量发生变化。
2. 消费者组成员订阅主题数量发生变化。
3. 订阅主题的分区数发生变化。

平衡机制步骤:

1. 暂停消费：在重平衡开始之前，Kafka会暂停所有消费者的拉取操作，以确保不会出现重平衡期间的消息丢失或重复消费。
2. 计算分区分配方案：kafka集群会根据当前消费者组的消费者数量和主题分区数量，计算出每个消费者应该分配的分区列表，以实现分区的负载均衡。
3. 通知消费者：一旦分区分配方案确定，Kafka集群会将分配方案发送给每个消费者，告诉它们需要消费的分区列表，并请求它们重新加入消费者组。
4. 重新分配分区：在消费者重新加入消费者组后，Kafka集群会将分区分配方案应用到实际的分区分配中，重新分配主题分区给各个消费者。
5. 恢复消费：最后，Kafka会恢复所有消费者的拉取操作，允许它们消费分配给自己的分区。

Kafka的重平衡机制能够有效地实现消费者的负载均衡和高可用性，提高消息的处理能力和可靠性。但是，由于重平衡会带来一定的性能开销和不确定性，例如：消息乱序、重复消费等问题，因此在设计应用时需要考虑到重平衡的影响，并采取一些措施来降低重平衡的频率和影响。

在重平衡过程中，所有Consumer实例都会停止消费。等待重平衡完成。但是目前并没有什么好的办法来解决重平衡带来的STW，只能尽量避免它的发生。

Consumer实例五种状态

• Empty：组内没有任何成员，但是消费者可能存在已提交的位移数据，而且这些位移尚未过期。
• Dead：同样是组内没有任何成员，但是组的元数据信息已经被协调者端移除，协调者保存着当前向他注册过的所有组信息。
• Preparing Rebalance：费者组准备开启重平衡，此时所有成员都需要重新加入消肖费者组
• Completing Rebalance：消费者组下所有成员已经加入，各个成员中等待分配方案
• Stable：消费者组的稳定状态，该状态表明重平衡已经完成，组内成员能够正常消费数据

Leader选举机制

Partition Leader 选举

Kafka中的每个Partition都有一个Leader，负责处理该Parttition的读写请求。在正常情况下。Leader和ISR集合中的所有副本保持同步，Leader接收到的消息也会被ISF集合中的副本所接收。当leader副本宕机或者无法正常工作时，需要选举新的leader副本来接管分区的工作。

Leader选举的过程如下:

1. 每个参与选举的副本会尝试向ZooKeeper上写入一个临时节点，表示它们正在参与Leader选举
2. 所有写入成功的副本会在ZooKeeper上创建一个序列号节点，并将自己的节点序列号写入该节点
3. 节点序列号最小的副本会被选为新的Leader，并将自己的节点名称写入ZooKeeper上的/broker/…/leader节点中。

Controller选举

Kafka集群中只能有一个Controller节点，用于管理分区的副本分配、leader选举等任务。当一个Broker变成Controller后，会在Zookeeper的/controller节点中记录下来。然后其他的Broker会实时监听这个节点，主要就是避免当这个controller宕机的话，就需要进行重新选举。

Controller选举的过程如下:

1. 所有可用的Broker向ZooKeeper注册自己的ID。并监听Zookeeper中/controller节点的变化。
2. 当Controller节点出现故障时，ZooKeeper会删除/controller节点，这时所有的Broker都会监听到该事件，并开始争夺Controller的位置。为了避免出现多个Broker同时竞选Controller的情况，Kafka设计了一种基于ZooKeeper的Master-Slave机制，其中一个Broker成为Master，其它Broker成为为Slave。Master负责选举Controller，并将选举结果写入ZooKeeper中，而Slave则监听/controller节点的变化，一旦发现Master发生故障,则开始争夺Master的位置。
3. 当一个Broker发现Controller失效时，它会向ZooKeeper写入自自己的ID，并尝试竞选Controller的位置。如果他创建临时节点成功，则该Broker成为新的Controller，并将选举结果写入ZooKeeper中。
4. 其它的Broker会监听到ZooKeeper中/controller节点的变化，一旦发现选举结果发生变化，则更新自己的元数据信息，然后与新的Controller建立连接,进行后续的操作。

高水位HW机制

高水位(HW,HighWatermark)是Kafka中的一个重要的概念，主要是用于管理消费者的进度和保证数据的可靠性的。

高水位标识了一个特定的消息偏移量(offset)，即一个分区中已提交（这里的已提交指的是ISR中的所有副本都记录了这条消息）消息的最高偏移量(offset)，消费者只能拉取到这个offset之前的消息。消费者可以通过跟踪高水位来确定自己消费的位置。

在Kafka中，HW主要有两个作用:

1. 消费进度管理：消费者可以通过记录上一次消费的偏移量，然后将其与分区的高水位进行比较，来确定自己的消费进度。消费者可以在和高水位对比之后继续消费新的消息，确保不会错过任何已提交的消息。这样，消费者可以按照自己的节奏进行消费，不受其他消费者的响。
2. 数据的可靠性：高水位还用于确保数据的可靠性。在Kafka中，只有消息被写入主副本(Leader Replica)并被所有的同步副本(In-Sync Replicas,ISR)确认后，才被认为是是已提交的消息。高水位表示已经被提交的消息的边界。只有高水位之前的消息才能被认为是已经被确认的，其他的消息可能会因为副本故障或其他原因而丢失。当消费者消费消息，可以使用高水位作为参考点，只消费高水位之前的消息，以确保消费的是已经被确认的消息，从而保证数据的可靠性。
   

还有一个概念，叫做LEO，即LogEnd Offset,，他是日志最后消息的偏移量。它标识当前日志文件中下一条待写入消息的offset。

它有以下特点和作用：

• 用于表示副本写入下一条消息的位置。
• 每个副本（包括 leader 副本和 follower 副本）都有自己的 LEO。
• LEO 的值会随着消息的写入而增加，每当有新消息写入底层日志成功时，相应副本的 LEO 就会加 1。
• LEO 主要用于跟踪副本的同步进度。

需要注意的是，在 0.11.0.0 版本之前，HW 的更新可能存在一些问题，例如在特定情况下可能导致消息丢失。0.11.0.0 及之后的版本使用 leader epoch，与 HW 值结合，从而更好地保证了数据的一致性和顺序性。

• 每个分区都有一个初始的LeaderEpoch，通常为0。
• 当Leader副本发生故障或需要进行切换时，Kafka会触发副本切换过程。
• 副本切换过程中，Kafka会从ISR(In-Sync Replicas,同步副本)中选择一个新的Follower副本作为新的Leader副本。
• 新的Leader副本会增加自己的Leader Epoch，使其大于之前的Leader Epoch。这表示进入了一个新的任期。
• 新的Leader副本会验证旧Leader副本的状态以确保数据的一致性。它会检查旧Leader副本的Leader Epoch和高水位。
• 如果旧Leader副本的Leader Epoch小于等于新Leader副本的Leadder Epoch，并且旧Leader副本的高水位小于等于新Leader副本的高水位，则验证通过。
• 一旦验证通过，新的Leader副本会开始从ISR中的一部分副本中寻找最大的LEO副本进行复制数据，以确保新Leader上的数据与旧Leader-致。
• 一旦新的Leader副本复制了旧Leader副本的所有数据，并达到了与旧Leader副本相同的高水位，副本切换过程就完成了。

通过使用Leader Epoch、高水位、LEO的验证，Kafka可以避免新的Leader副本接受旧Leader副本之后的消息，从而避免数据回滚和丢失。Leader Epoch 为 Kafka 提供了一种更可靠和一致的副本管理机制，确保了在 Leader 副本切换等情况下数据的完整性和正确性。