Topic和Partition是Kafka中国比较重要的概念
从上面简单的解释不难看出,这两个看上去其实都是消息的载体。那么为什么还要分为两层呢,有了Topic为什么还需要Partition呢?
在软件领域中,任何问题都可以加一个中间层来解决,而Topic和Partition就是类似的思想,在Topic的基础上,再细粒度的划分出了一层,主要有以下几个好处:
综上所述,Topic是消息的逻辑分类,而Partition是物理上的消息分区。通过Topic分成多个Partition,可以实现提高吞吐量、负载均衡、以及由更好的扩展性。
Kafka的重平衡机制是指再消费者组中新增或删除消费者时,Kafka会重新分配Topic Partition给各个消费者,以保证每个消费者消费的分区数量尽可能均衡。
重平衡机制的目的时实现消费者的负载均衡和高可用性,以确保每个消费者都能够按照预期的方式消费到消息。
当Kafka集群要出发重平衡机制时,大致步骤如下:
Kafka的重平衡机制能够有效地实现消费者的负载均衡和高可用性,提高消息的处理能力和可靠性。但是,由于平衡会带来一定的性能开销和不确定性,因此在设计应用时需要考虑到重平衡的影响,并采取一定的措施来降低重平衡的频率和影响。
在重平衡过程中,所有Consumer实例都会停止消费,等待重平衡完成。但是目前并没有什么好的办法来解决重平衡带来的STW,只能尽量避免它的发生。
Kafka的Consumer实例的五种状态,分别是:
状态 | 描述 |
---|---|
Empty | 组内没有任何成员,但是消费者可能存在已经提交的位移数据,而且这些位移尚未过期 |
Dead | 同样是组内没有任何成员,但是组的元数据信息已经被协调者端移除,协调者保存着当前向他注册过的所有组信息 |
PreparingRebalance | 消费者组准备开启重平衡,此时所有成员都需要重新加入消费者组 |
CompletingRebalance | 消费者组所有成员已经加入,各个成员中等待分配方案 |
Stable | 消费者组的稳定状态,该状态表明重平衡已经完成,组内成员能够正常消费数据 |
状态的流转过程:
在Kafka中常见的几种选举过程如下:
Kafka中的每个Partition都有一个Leader,负责处理该Partition的读写请求。在正常情况下,Leader和ISR集合中的所有副本保持同步,Leader接收到的消息也会被ISR集合中的副本所接收。当Leader副本宕机或者无法正常工作时,需要选举新的Leader副本来接管分区的工作。
Leader选举的过程如下:
/broker/.../leader
节点中Kafka集群中只能有一个Controller节点,用于管理分区的副本分配、leader选举等任务。当一个Broker变成Controller后,会在Zookeeper的/controller节点中记录下来。然后其它的Broker会实时监听这个节点,主要就是避免这个Controller宕机的话,就需要重新选举。
Controller选举的过程如下:
在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节点序列号是唯一且递增的
好了,本章节到此告一段落。希望对你有所帮助,祝学习顺利。
我正在参与2024腾讯技术创作特训营第五期有奖征文,快来和我瓜分大奖!
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。