Kafka正试图以“恢复模式”向经纪人发送消息

Question

我有以下设置

3个Kafka（v2.1.1）代理5个Zookeeper实例

Kafka代理具有以下配置：

      auto.create.topics.enable: 'false'
      default.replication.factor: 1
      delete.topic.enable: 'false'
      log.cleaner.threads: 1
      log.message.format.version: '2.1'
      log.retention.hours: 168
      num.partitions: 1
      offsets.topic.replication.factor: 1
      transaction.state.log.min.isr: '2'
      transaction.state.log.replication.factor: '3'
      zookeeper.connection.timeout.ms: 10000
      zookeeper.session.timeout.ms: 10000
      min.insync.replicas: '2'
      request.timeout.ms: 30000

生产者配置（使用Spring Kafka）大致如下：

...
acks: all
retries: Integer.MAX_VALUE
deployment.timeout.ms: 360000ms
enable.idempotence: true
...

这个配置我读如下：有三个Kafka代理，但一旦其中一个死了，它是罚款，如果只有至少两个复制和持久的数据发送ack回（=在同步副本）。如果失败，Kafka制作人会持续重试6分钟，但随后放弃。

这就是让我头疼的场景：

• 所有Kafka和Zookeeper实例都已启动并处于活动状态

问题是

• 为什么Kafka集群要等到死去的Broker回来？
• 当生产者意识到代理没有响应时，为什么它不尝试连接另一个代理？
• 线程完全卡住了6分钟，等待死去的Broker恢复，我怎么能告诉制作人宁愿尝试另一个Broker？
• 我是错过了什么，还是有什么好的做法来避免这种情况？

Answer 1

你有很多问题，我将尝试提供我们的经验，希望能对其中一些问题有所帮助。

在我的产品IBM IDR Replication中，我们必须为那些主题正在重新平衡或在集群中失去代理的客户提供健壮性信息。我们的一些测试的结果是，仅仅设置请求超时是不够的，因为在某些情况下，请求将决定不等待整个时间，而是几乎立即执行另一次重试。这会消耗配置的重试次数，即，在某些情况下会绕过超时时间。

因此，我们指示用户使用如下公式...

https://www.ibm.com/support/knowledgecenter/en/SSTRGZ_11.4.0/com.ibm.cdcdoc.cdckafka.doc/tasks/robust.html

“若要调整环境的值，请根据以下公式调整Kafka producer属性retry.backoff.ms和retries：retry.backoff.ms*retries。”

因此，也许可以尝试利用重试和重试。退避。请注意，如果有多个正在进行中，则使用不带幂等性的重试可能会导致批写入无序。。。因此，根据您的业务逻辑进行相应的选择。

根据我们的经验，Kafka制作人写信给经纪人，经纪人是该主题的领导者，因此你必须等待新领导人当选。此时，如果重试过程仍在进行中，则生产者将透明地确定新的领导者并相应地写入数据。