likes
comments
collection
share

【年后跳槽必看篇-非广告】Kafka核心知识点 第三章

作者站长头像
站长
· 阅读数 15

Kafka为什么有Topic还用Partition

Topic和Partition是Kafka中国比较重要的概念

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

从上面简单的解释不难看出,这两个看上去其实都是消息的载体。那么为什么还要分为两层呢,有了Topic为什么还需要Partition呢?

在软件领域中,任何问题都可以加一个中间层来解决,而Topic和Partition就是类似的思想,在Topic的基础上,再细粒度的划分出了一层,主要有以下几个好处:

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

综上所述,Topic是消息的逻辑分类,而Partition是物理上的消息分区。通过Topic分成多个Partition,可以实现提高吞吐量、负载均衡、以及由更好的扩展性。

什么是Kafka的重平衡机制?

Kafka的重平衡机制是指再消费者组中新增或删除消费者时,Kafka会重新分配Topic Partition给各个消费者,以保证每个消费者消费的分区数量尽可能均衡。

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

【年后跳槽必看篇-非广告】Kafka核心知识点 第三章

触发重平衡的3个条件:

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

当Kafka集群要出发重平衡机制时,大致步骤如下:

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

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

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

消费者的五种状态

Kafka的Consumer实例的五种状态,分别是:

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

状态的流转过程:

【年后跳槽必看篇-非广告】Kafka核心知识点 第三章

Kafka几种选举过程

在Kafka中常见的几种选举过程如下:

Partition Leader选举

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

Leader选举的过程如下:

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

Controller 选举

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

Controller选举的过程如下:

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

Kafka中,为什么节点序列号最小的副本会被选为新的Leader

在Kafka中,节点序列号最小的副本被选为新的Leader是因为Kafka使用了Zookeeper作为协调服务。在Kafka集群中,Zookeeper负责维护集群的元数据(例如Topic和Partition信息)以及Brokers(Kafka服务器)的状态

当一个Broker(副本)成为Leader候选人时,它会向Zookeeper注册自己并申请成为该分区的Leader。在这个过程中,每个候选人都会创建一个临时带有递增序列号的Zookeeper节点,被称为选举竞争者(election contender)

当都选人注册完成后,它们会查询Zookeeper并比较自己的序列号与其他候选人的序列号。Kafka采用基于递增序列号的最小值来选择新的Leader。因此,具有最小序列号的候选人将成为新的Leader,并负责处理该分区的所有读写请求

通过这种方式,Kafka实现了简单而有效的Leader选举机制,确保了高可用性和数据一致性。选择序列号最小的副本作为Leader可以避免分区不一致的情况,并且能够迅速的恢复正常操作,因为Zookeeper节点序列号是唯一且递增的

如有问题,欢迎加微信交流:w714771310,备注- 技术交流  。或关注微信公众号【码上遇见你】。

好了,本章节到此告一段落。希望对你有所帮助,祝学习顺利。