我试着列出Kafka进行领导者选举的所有不同场景。到目前为止，根据我的研究，领导者选举是在一个节点崩溃时进行的。出现在崩溃的节点中的分区需要新的领导者，因此发生了领导者选举。还有其他发生领导者选举的场景吗？
我试图重现NOT_LEADER_FOR_PARTITION异常，我相信发生在Kafka推到一个代理时，该代理不是分区的领导者，我相信这是由于生产者中过时的元数据，这可能是由领导者选举引起的，因此我努力重现它。
我尝试发布并停止一个包含代理的虚拟机，但还无法复制它。
我试着列出Kafka进行领导者选举的所有不同场景。到目前为止，根据我的研究，领导者选举是在一个节点崩溃时进行的。出现在崩溃的节点中的分区需要新的领导者，因此发生了领导者选举。还有其他发生领导者选举的场景吗？
我试图重现NOT_LEADER_FOR_PARTITION异常，我相信发生在Kafka推到一个代理时，该代理不是分区的领导者，我相信这是由于生产者中过时的元数据，这可能是由领导者选举引起的，因此我努力重现它。
我尝试发布并停止一个包含代理的虚拟机，但还无法复制它。
1条答案
按热度按时间am46iovg1#
是的，你的发现是正确的。基本上，当Kafka集群中的一个节点（应该是一个领导者）发生故障时，就会发生领导者选举。但这不是唯一发生领导者选举的时候。下面是发生领导者选举的其他情况：
1.添加新分区时
1.当分区的 Bootstrap 不可用时
1.将分区迁移到其他节点
现在来看NOT_LEADER_FOR_PARTITION异常，为了复制该异常，您可以关闭领导分区并发送数据。但是，您必须确保元数据中包含作为领导的节点的信息。为了更深入地了解这一点，客户端在发送数据之前获取元数据（可能不是一直都一样，可能会发生元数据缓存），所以要确保客户端的元数据中有旧的领导者/非领导者节点的信息，而不是新领导者的信息。
简而言之，你可以使用上面提到的任何一种场景来产生NotLeaderForPartition异常，但唯一的条件是你的客户端需要向非领导节点发送数据。