那个网站教做馒头,河源新闻最新消息,炉石吐司做的网站,娄底市建设网站分区机制
Kafka 的分区机制是其实现高吞吐和可扩展性的重要特性之一。
Kafka 中的数据具有三层结构#xff0c;即主题#xff08;topic#xff09;- 分区#xff08;partition#xff09;- 消息#xff08;message#xff09;。一个 Kafka 主题可以包含多个分…分区机制
Kafka 的分区机制是其实现高吞吐和可扩展性的重要特性之一。
Kafka 中的数据具有三层结构即主题topic- 分区partition- 消息message。一个 Kafka 主题可以包含多个分区而每个分区又可以包含多条消息。
Topic和Partition是kafka中比较重要的概念。
主题:Topic是Kafka中承载消息的逻辑容器。可以理解为一个消息队列。生产者将消息发送到特定的Topic消费者从Topic中读取消息。Topic可以被认为是逻辑上的消息流。在实际使用中多用来区分具体的业务。分区:Partition。是Topic的物理分区。一个Topic可以被分成多个Partition每个Partition是一个有序且持久化存储的日志文件。每个Partition都存储了一部分消息并且有一个唯一的标识符(称为Partition ID)。
好处
提升吞吐量通过将一个Topic分成多个Partition可以实现消息息的并行处理。每个Partition可以由不同的消费者组进行独立消费,这样就可以提高整个系统的吞吐量。负载均衡Partition的数量通常比消费者组的数量多这样可以使每个消费者组中的消费者均匀地消费消息。当有新的消费者加入或离开消费者组时可以通过重新分配Partition的方式进行负载均衡。扩展性通过增加Partition的数量可以实现Kafka集群的广展性。更多的Partition可以提供更高的并发处理能力和更大的存储容量。
重平衡机制
Kafka的重平衡机制是指在消费者组中新增或删除消费者时Kafka集群会重新分配主题分区给各个消费者以保证每个消费者消费的分区数量尽可能均衡。
重平衡机制的目的是实现消费者的负载均衡和高可用性以确保每个消费者都能够按照预期的方式消费到消息。 重平衡的3个触发条件:
消费者组成员数量发生变化。消费者组成员订阅主题数量发生变化。订阅主题的分区数发生变化。
平衡机制步骤:
暂停消费在重平衡开始之前Kafka会暂停所有消费者的拉取操作以确保不会出现重平衡期间的消息丢失或重复消费。计算分区分配方案kafka集群会根据当前消费者组的消费者数量和主题分区数量计算出每个消费者应该分配的分区列表以实现分区的负载均衡。通知消费者一旦分区分配方案确定Kafka集群会将分配方案发送给每个消费者告诉它们需要消费的分区列表并请求它们重新加入消费者组。重新分配分区在消费者重新加入消费者组后Kafka集群会将分区分配方案应用到实际的分区分配中重新分配主题分区给各个消费者。恢复消费最后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选举的过程如下:
每个参与选举的副本会尝试向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建立连接,进行后续的操作。
高水位HW机制
高水位(HW,HighWatermark)是Kafka中的一个重要的概念主要是用于管理消费者的进度和保证数据的可靠性的。
高水位标识了一个特定的消息偏移量(offset)即一个分区中已提交这里的已提交指的是ISR中的所有副本都记录了这条消息消息的最高偏移量(offset)消费者只能拉取到这个offset之前的消息。消费者可以通过跟踪高水位来确定自己消费的位置。
在Kafka中HW主要有两个作用:
消费进度管理消费者可以通过记录上一次消费的偏移量然后将其与分区的高水位进行比较来确定自己的消费进度。消费者可以在和高水位对比之后继续消费新的消息确保不会错过任何已提交的消息。这样消费者可以按照自己的节奏进行消费不受其他消费者的响。数据的可靠性高水位还用于确保数据的可靠性。在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 副本切换等情况下数据的完整性和正确性。
