【问题标题】:What is a partition leader in Apache Kafka?Apache Kafka 中的分区领导者是什么?
【发布时间】:2020-07-05 05:31:15
【问题描述】:

kafka 领导者是自己分区还是经纪人? 我最初的理解是,它们是充当读/写代理的分区,然后将它们的价值传递给 ISR。

但是最近我听到他们提到它们,好像它们发生在“经纪人”级别,因此我感到困惑。

我知道还有其他帖子旨在回答这个问题,但那里的答案没有帮助。

【问题讨论】:

    标签: apache-kafka broker kafka-topic leader kafka-partition


    【解决方案1】:

    这里的一些答案并不绝对正确,所以我想让它更清楚。

    每个分区都有一个分区领导者,负责处理该分区的所有读/写请求。
    如果复制因子大于 1,则额外的分区复制充当分区追随者。
    Kafka 保证每个分区副本驻留在不同的代理上(无论是领导者还是追随者),所以最大复制因子是经纪人数量。

    每个分区追随者都从分区领导者那里读取消息(充当一种消费者),并且不为该分区的任何消费者提供服务(只有分区领导者提供读/写服务)。
    如果分区跟随者一直从分区领导者读取数据而不会落后并且不会失去与 ZooKeeper 的连接(最大延迟默认为 10 秒,ZooKeeper 超时时间为 6,它们都是可配置的),则认为它是同步的。
    如果分区追随者落后,则认为它不同步。
    当分区领导者因任何原因关闭(实际上它所在的代理关闭)时,其中一个是同步的分区追随者成为新的领导者。

    replication section in Kafka Documentation 对此进行了详细说明。
    Confluent 还写了一个很好的blog 关于这个话题。

    【讨论】:

    • 这是一个非常好的和全面的答案。但我认为答案的最后一部分是不正确的。我猜你假设 acks=all 已设置。我知道,如果acks=all 并且根据min.insync.replicas 没有足够的ISR,生产者无法生成数据并获得NotEnoughReplicas 异常。但这并不意味着“分区不可用”。订阅此主题的消费者仍然可以发送获取请求,并且分区仍然可用。其他拥有acks=1acks=0 的生产者仍然可以生产消息。你可以考虑改变这部分。问候。
    • 谢谢!据我所知,acks 配置仅与生产者在其发送得到确认时有关,但与此无关,如果分区没有足够的同步跟随者分区,则分区可能不可用。因此,即使 acks=0,如果由于太多不同步的分区而导致分区不可用,生产者也将无法为该主题生成任何新消息。无论如何,我会进一步挖掘并尝试用一个可信赖的来源来支持这个解释。如果我们发现我错了,我会更新答案:)
    • 我查看了文档,您完全正确,他们说:If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed, even if the number of in-sync replicas is lower than the minimum (e.g. it can be as low as just the leader).。我删除了关于最小同步副本的最后一部分。我不认为添加有关此的更多信息,并且 acks 参数与此问题相关。如果您认为我应该添加解释,请告诉我!
    • 我觉得现在可以了:)
    • 这个答案即使在 2020 年 3 月 24 日也已过时。2019 年 12 月 16 日发布的 Kafka 2.4.0 支持从副本消费。见KIP-392
    【解决方案2】:

    tl;dr

    kafka 领导者是自己分区还是经纪人?

    分区领导者是一个Kafka Broker


    分区领导

    Kafka Docs中明确提到了这一点:

    每个分区都有一个服务器作为“领导者”,零或 更多充当“追随者”的服务器。领导者处理所有读取和 在追随者被动的情况下写入分区请求 复制领导者。如果领导者失败,其中一个追随者将 自动成为新的领导者。每个服务器充当领导者 它的一些分区和其他分区的追随者,所以负载很好 在集群内保持平衡。

    因此,分区领导者实际上是服务于这个目的的broker,负责这个特定分区的所有读写请求。


    分区领导选举

    为特定分区分配领导者发生在称为分区领导者选举的过程中。当创建主题/分区或分区领导者(即代理)因任何原因不可用时,会发生此过程。

    另外,您可以使用Preferred Replica Leader Election Tool 强制首选副本选举:

    使用复制,每个分区可以有多个副本。名单 分区的副本称为“分配的副本”。这 此列表中的第一个副本是“首选副本”。什么时候 创建主题/分区时,Kafka 确保“首选 跨主题分区的副本”是均匀分布的 在集群中的代理之间。在理想情况下,领导者 给定的分区应该是“首选副本”。这保证 集群中代理之间的领导负载是均匀的 均衡。然而,随着时间的推移,领导力的负担可能会变得不平衡 由于代理关闭(由受控关闭、崩溃、 机器故障等)。该工具有助于恢复领导力 集群中代理之间的平衡。

    为此,您必须运行以下命令:

    bin/kafka-preferred-replica-election.sh --zookeeper localhost:12913/kafka --path-to-json-file topicPartitionList.json
    

    topicPartitionList.json 的内容应如下所示:

    {
     "partitions":
      [
        {"topic": "topic1", "partition": 0},
        {"topic": "topic1", "partition": 1},
        {"topic": "topic1", "partition": 2},
        {"topic": "topic2", "partition": 0},
        {"topic": "topic2", "partition": 1}
      ]
    }
    

    如何找到哪个代理充当分区领导者

    为了找到哪个代理充当分区领导者,哪个充当同步副本(ISR),您必须运行以下命令:

    kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic myTopic
    

    并且输出应该与下面的相同:

    Topic:myTopic       PartitionCount:4        ReplicationFactor:1     Configs:
        Topic: myTopic      Partition: 0    Leader: 2       Replicas: 2     Isr: 2
        Topic: myTopic      Partition: 1    Leader: 3       Replicas: 3     Isr: 3
        Topic: myTopic      Partition: 2    Leader: 4       Replicas: 4     Isr: 4
        Topic: myTopic      Partition: 3    Leader: 0       Replicas: 0     Isr: 0
    

    【讨论】:

      【解决方案3】:

      当 Kafka 主题的 --replication-factor 大于 1 时,分区领导概念有效(这也意味着我们的集群必须具有大于或等于复制因子的代理数)。

      在这种情况下,当生产者将任何消息推送到主题的分区时,请求首先到达分区的领导者(在 Kafka 集群上存在的所有复制分区中)。它存储消息并首先将消息复制到其他追随者分区上,然后将消息确认发送给生产者。

      仅在完成上述过程后,特定消息将可供消费者使用。

      推荐官方link了解更多。

      【讨论】:

        【解决方案4】:

        Kafka 中的所有主题分区都有一个领导者,如果复制因子大于 1,则领导者有追随者。可以使用以下命令检查分区领导者:

        bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic myTopic --describe
        

        在此命令的输出中,分区领导者的代理 ID 显示为 leader: xx

        【讨论】:

          猜你喜欢
          • 2021-11-08
          • 1970-01-01
          • 1970-01-01
          • 2021-10-12
          • 2020-03-30
          • 1970-01-01
          • 2018-05-25
          • 2023-04-05
          • 2020-10-18
          相关资源
          最近更新 更多