Apache kafka 如果Kafka制作者尝试向其发送消息的分区脱机，制作者是否可以尝试向其他分区发送消息？

我的Kafka集群有5个代理，主题的复制系数为3。某些分区有时会脱机，但最终会重新联机。我的问题是：

考虑到存在脱机分区这一事实，这表明有多少代理宕机？我认为考虑到上面的集群设置，我可以同时失去2个代理。但是，如果有2个代理关闭，对于某些分区，它们不再具有仲裁；在这种情况下，这些分区会脱机吗

如果存在脱机分区，并且卡夫卡制作者尝试向其发送消息但失败，制作者是否会尝试其他可能联机的分区？消息中没有密钥

---

我不确定我是否完全正确地理解了您的问题，但我的印象是您将分区和复制混为一谈。或者至少，你的问题不能孤立地看在制作人身上。一旦一个代理宕机，集群上就会发生一些事情

每个TopicPartition都有一个分区领导，您的客户端（例如生产者和消费者）仅与这一领导通信，而与复制的数量无关

在五分之二的代理不可用的情况下，Kafka将把分区前导以及副本移动到一个正常的代理。因此，在这种情况下，您不应该遇到麻烦，尽管选择新的领导者和在健康代理上创建新的复制可能需要一些时间和重试。由于将复制因子设置为3，所以可以快速选择引导者，因此即使两个代理宕机，一个代理仍应具有完整的数据（假设所有分区都同步）。但是，创建两个新副本可能需要一些时间，具体取决于数据量。对于该场景，您需要查看主题级配置

min.insync.replications

和KafkaProducer确认

acks

（见下文）

我认为以下是卡夫卡制作人处理此类情况的最重要配置：

bootstrap.servers：如果您预计代理经常出现连接问题，您应该确保列出所有五个问题。尽管只提及一个地址就足够了（因为一个代理随后将与集群中的所有其他代理通信），但在一个或两个代理不可用的情况下，将它们全部列出是安全的

确认：默认值为

1

，并定义生产者要求分区负责人在认为请求成功之前收到的确认数量。可能的值有

0

、

1

和

all

重试：此值默认为

2147483647

，将导致客户端重新发送发送失败且可能出现暂时错误的任何记录，直到到达

传递时间。超时.ms

delivery.timeout.ms：返回send（）调用后报告成功或失败的时间上限。这限制了记录在发送前延迟的总时间、等待代理确认的时间（如果预期）以及可重试发送失败的允许时间。如果遇到不可恢复的错误，重试次数已用尽，或者记录添加到达到较早交付到期期限的批次中，则生产者可能会报告未能在此配置之前发送记录。此配置的值应大于或等于request.timeout.ms和linger.ms之和

您将在上找到有关文档的更多详细信息