kafka领导人是自己分区还是经纪人？我最初的理解是，它们是充当读/写代理的分区，然后将它们的值转换为ISR。
然而，最近我听到他们被提及，就好像他们发生在"经纪人"层面，因此我感到困惑。
我知道还有其他帖子旨在回答这个问题，但那里的答案没有帮助。
这里的一些答案不是绝对正确的，所以我想让它更清楚。
每个分区都有一个分区领导，负责处理该分区的所有读/写请求(更新：从Kafka 2.4.0开始，允许消费者从副本中读取)
如果复制因子大于1，则额外的分区复制充当分区跟随者
Kafka保证每个分区副本都驻留在不同的代理上(无论是领导者还是追随者)，因此最大复制因子是集群中的代理数量。
每个分区跟随器都在从分区引导器读取消息(充当一种使用者)，并且不为该分区的任何使用者提供服务(只有分区引导器提供读/写服务)
如果分区跟随器从分区引导器读取记录而不滞后，并且不丢失与ZooKeeper的连接，则视为同步(默认最大滞后时间为10秒，ZooKeepertimeout为6秒，两者都是可配置的)
如果分区跟随器落后于ZooKeeper或丢失了与ZooKeepper的连接，则认为它不同步
当分区引导程序因任何原因关闭(例如代理程序关闭)时，其中一个同步的分区跟随程序将成为新的引导程序
Kafka文档中的复制部分对此进行了详细解释
Confluent还写了一篇关于这个主题的不错的博客。
tl；dr
卡夫卡领导人是自己分区还是经纪人？
分区领导者是KafkaBroker。
分区领导
这一点在Kafka文档中有明确提及：
每个分区都有一个服务器作为"领导者"，零或更多的服务器充当"追随者"。领导处理所有的阅读和在跟随者被动的情况下写入分区请求复制领导者。如果领导者失败，其中一名追随者将自动成为新的领导者。每个服务器都充当它的一些分区和其他分区的一个追随者，所以负载很好在集群内保持平衡。
因此，分区负责人实际上是broker，负责此特定分区的所有读写请求。
分区领导人选举
为特定分区分配领导人的过程称为分区领导人选举。当创建主题/分区时，或者当分区领导者(即代理)由于任何原因不可用时，就会发生此过程。
此外，您可以使用首选副本负责人选举工具：强制进行首选副本选举
使用复制，每个分区可以有多个副本。列表分区的副本数称为"分配的副本"。这个此列表中的第一个副本是"首选副本"。什么时候创建了主题/分区，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
当Kafka主题的--replication因子大于1(这也意味着我们的集群的broker计数必须大于或等于replication factor)时，分区领导者的概念就起作用了。
在这种情况下，当生产者将任何消息推送到主题的分区时，请求首先到达分区的领导者(在Kafka集群上所有复制的分区中)。它存储消息，并首先在其他跟随分区上复制消息，然后向生产者发送对消息的确认。
仅在完成上述过程之后，特定的消息将可供消费者使用。
我推荐官方链接以获得更多的理解。
Kafka中的所有主题分区都有一个leader，如果复制因子大于1，则leader有个follower。分区引线可以使用以下命令进行检查：
bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic myTopic --describe
在该命令的输出中，分区领导者的代理ID显示为leader: xx