本文介绍: 后台同步任务是 Kafka 内部自动管理的,不需要人为干预。Kafka 设计了一些后台任务来确保副本之间的同步和数据的一致性,以提高整个系统的可用性和可靠性。滞后主要指的是追随者在处理消息时相对于领导者的位置较远,即它的日志文件中的消息相对较旧。这是通过追随者的日志文件中的偏移量(offset)来衡量的。消息追加到分区的日志文件,这确保了分区的写入顺序。🫱🏽 kafka后台同步策略。在线(心跳表现 | ISR中)宕机(心跳表现 | ISR中)滞后(心跳表现 | ISR中)🫱🏽 kafka分区策略。

在这里插入图片描述

  • 主题(topic):消息的第一次分类
    • 根据人为的划分条件将消息分成不同的主题
      • 主题的划分是人为的根据不同的任务情景去划分
        • 比如,我们有两个主题,一个是”订单”,另一个是”库存”。每个主题代表一个消息流。
      • 主题的名称作为主题的为一标识符,我们需要保证其唯一性
      • Topic是一个逻辑上的概念,并不能直接在图中把Topic的相关单元画出
  • 分区(partition):消息的第二次分类
    • 区域化同主题中的消息:分区管理同主题的消息
      • 不同主题下分区标识可以相同
      • 每个分区都有一个唯一的标识
  • 分区偏移(partition offset):消息的第三次分类
    • 同一分区内的不同消息都有唯一的偏移
      • 消息的偏移值是唯一且按照顺序递增的。kafka分配消息时确定
    • 不同分区内的消息的偏移可以相同

🫱🏽 kafka分区策略

  1. 默认分区策略(DefaultPartitioner): 如果消息没有指定 key,或者指定的 key 为 null,那么默认分区策略会采用轮询(round-robin)的方式将消息均匀地分配到所有可用分区。请添加图片描述
  2. 基于 key 的分区策略(PartitionByKey): 如果消息指定了 key,那么基于 key 的分区策略会根据 key 的哈希值将消息分配到对应的分区。这确保具有相同 key 的消息总是被分配到同一个分区,以保证消息的顺序性。
  3. 自定义分区策略: 用户可以根据自己的需求实现自定义的分区策略。这可以通过实现 Kafka 提供的 Partitioner 接口来完成。
  • 分区备份(replicas of partition):分区的备份,用于防止数据丢失。
    • 备份时机
      • 消息写入
      • 消费者拉取
      • 后台任务

🫱🏽 kafka后台同步策略

后台同步任务是 Kafka 内部自动管理的,不需要人为干预。Kafka 设计了一些后台任务来确保副本之间的同步和数据的一致性,以提高整个系统的可用性和可靠性。

这些后台同步任务包括:

  1. Leader 的心跳检测: Kafka 集群中的每个分区都有一个领导者(Leader),领导者会定期发送心跳消息给追随者(Followers)。这有助于检测领导者的健康状态。
  2. 追随者的数据拉取: 追随者会定期从领导者拉取缺失的数据,以保持与领导者的同步。这有助于处理因追随者滞后或宕机而导致的数据不一致。
  3. Leader 的日志清理: 领导者会定期清理旧的日志段,删除过时的消息。这确保了存储在磁盘上的数据不会无限增长,也有助于提高性能。

  • 经纪人(Brokers):负责维护发布数据的系统,每个代理可以管理一个或多个主题的分区。
    • 同一主题下可能有1-n 经纪人
    • 同一分区任意时刻只能由一个经纪人管理
    • 经纪人的分配区域管理
      • 一个主题和N个代理中有N个分区,每个代理将有一个分区。
      • 一个主题中有N个分区并且多于N个代理(n + m),则第一个N代理将具有一个分区,并且下一个M代理将不具有用于该特定主题的任何分区。
      • 一个主题中有N个分区并且小于N个代理(n-m),每个代理将在它们之间具有一个或多个分区共享。 由于代理之间的负载分布不相等,不推荐使用此方案

  • 领导者(Leader):负责处理该分区的读写请求
    • 职责:
      • 消息追加到分区的日志文件,这确保了分区的写入顺序

        • 不同分区的消息顺序不做保证
        • 同一分区下的消息顺序是根据消息的写入的先后顺序有序存储
      • 消息的复制和同步:

        • 消息异步地复制到追随者(Followers)

          步骤 详细过程 举例(假设分区有3个追随者,需要2个确认)
          初始状态: 一个分区有一个领导者和多个追随者。领导者和追随者的副本都在 ISR 中,表示它们与领导者同步。
          生产者写入消息: 生产者产生一条新消息并发送给领导者。领导者接收到消息后,将消息追加到分区的日志文件。 生产者发送消息A,领导者将A追加到日志。
          消息异步复制到追随者: 领导者开始异步地将写入的消息复制到追随者。追随者接收到领导者的复制请求,将消息追加到它们的日志文件中。 追随者1、追随者2接收A并将A追加到各自日志。
          等待 ISR 中的确认: 尽管消息复制是异步进行的,领导者必须等待 ISR 中的一定数量的追随者确认已成功复制。 等待追随者1、追随者2确认。两者是异步的。
          如果 ISR 中的足够数量的追随者确认成功复制,领导者将响应给生产者,表示消息已成功写入。 追随者1、追随者2确认,领导者响应。
          消息的持久性和有序性: 由于消息已成功写入 ISR 中的足够数量的追随者,可以确保消息的持久性。 消息A被持久化,即使领导者宕机,ISR 中的副本可以被选为新的领导者,从而保证消息的持久性。
          由于等待 ISR 中的追随者确认,保证了消息的有序性。领导者会按照消息写入的顺序等待确认,以确保整个分区的消息顺序性。 领导者需要等待一定数量的追随者确认后才能继续处理下一条消息。这确保了消息在分区内的有序存储。
      • 追随者的管理

        • 心跳机制:检测追随者状态(在线、宕机、滞后)
          • 在线(心跳表现 | ISR中)

            • 追随者定期发送心跳消息,表示自己在线
            • 如果追随者的心跳正常,领导者将其包含在 ISR 中,表示它是同步的。
          • 宕机(心跳表现 | ISR中)

            • 领导者在一定时间内没有受到心跳信息,无法确认追随者的在线状态
            • 领导者可能将宕机的追随者移出 ISR,等待其他追随者的确认。
          • 滞后(心跳表现 | ISR中)

            • 追随者仍定期发送心跳消息,但在处理消息上存在滞后。
            • 领导者可能将滞后太多的追随者移出 ISR,以确保 ISR 中的副本是相对同步的。

            滞后主要指的是追随者在处理消息时相对于领导者的位置较远,即它的日志文件中的消息相对较旧。这是通过追随者的日志文件中的偏移量(offset)来衡量的。

      • 读操作的响应

        • 领导者负责处理来自消费者的读取请求。
          • 消费者可以从领导者或者任意一个追随者拉取消息。领导者负责返回正确的消息,确保读取操作的正确性。
      • 故障转移

        • 如果领导者宕机或者发生故障,Kafka 集群会自动进行领导者选举。新的领导者将被选举出来,确保分区的可用性。这是通过使用 ZooKeeper 进行协调的。
      • 日志清理

        • 领导者定期进行日志清理,删除过时的日志段,以释放磁盘空间。这有助于保持存储的合理大小
  • 追随者(Follower):备份节点是领导者的追随者,它们会按照领导者的指令更新数据。如果领导者失败,追随者可以接管并保持系统正常运行。
  • 消费者:
    • 同一消费组中,消费者不能同时消费同一分区的消息

    • 消费者分配消费分区策略

      • 初始化(静态)
        请添加图片描述

      • 动态变化

        • 同一消费组内,增加消费者
          请添加图片描述请添加图片描述

        • 增加消费组

        在这里插入图片描述

原文地址:https://blog.csdn.net/qq_25218219/article/details/135552974

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

如若转载,请注明出处:http://www.7code.cn/show_57058.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注