Kafka Producer NetworkException and Timeout Exceptions

java apache-kafka

2022-09-03 04:47:11

我们在生产环境中获得了随机的网络异常和超时异常：

Brokers: 3
Zookeepers: 3
Servers: 3
Kafka: 0.10.0.1
Zookeeeper: 3.4.3

我们偶尔会在我的生产者日志中遇到此异常：

TOPIC：XXXXXX 的 10 条记录即将过期：自批处理创建以来已超过 5608 毫秒加上延迟时间。

此类错误消息中的毫秒数不断变化。有时它〜5秒，其他时候它高达〜13秒！

我们很少得到：

NetworkException: Server disconnected before response received.

集群由3个经纪人和3个动物园管理员组成。生产者服务器和 Kafka 集群位于同一网络中。

我正在进行同步调用。有一个 Web 服务，多个用户请求调用该服务以发送其数据。Kafka Web服务有一个生产者对象，用于执行所有发送。生产者的请求超时最初为 1000 毫秒，已更改为 15000 毫秒（15 秒）。即使在增加超时期限后，超时异常仍然显示在错误日志中。

原因何在？

答案 1

找到根本原因有点棘手，我会放弃我的经验，希望有人会发现它有用。通常，它可能是网络问题或与 .这里有一个图表，解释了在撰写本文时从Kafka KIP-91（仍然适用到1.1.0）：ack=ALLTimeoutException

排除网络配置问题或错误，您可以根据自己的方案调整以下属性，以缓解或解决问题：

buffer.memory 控制生产者可用于缓冲的总内存。如果记录的发送速度快于传输到Kafka的速度，那么这个缓冲区将被超过，那么额外的发送调用阻止最多 max.block.ms 之后，生产者抛出一个。TimeoutException
max.block.ms 已经具有很高的价值，我不建议进一步增加它。buffer.memory的默认值为32MB，根据您的消息大小，您可能希望增加它;如有必要，请增加 jvm 堆空间。
重试次数定义在放弃之前在发生错误时重新发送记录的次数。如果使用零重试，则可以尝试通过增加此值来缓解问题，请注意，除非将 max.in.flight.requests.per.connection 设置为 1，否则不再保证记录顺序。
一旦达到批大小或超过延迟时间（以先到者为准），就会发送记录。如果 batch.size（默认为 16kb）小于最大请求大小，则可能应使用更高的值。此外，将 linger.ms 更改为更高的值，如 10、50 或 100，以优化批处理和压缩的使用。这将减少网络中的泛洪，并在使用它时优化压缩。

关于这类问题没有确切的答案，因为它们也取决于实现，在我的情况下，尝试上面的值是有帮助的。

答案 2

我们也面临类似的问题。许多在日志中，并且不时。NetworkExceptionsTimeoutException

原因

一旦我们从生产中收集TCP日志，事实证明，与Kafka代理的一些TCP连接（我们有3个代理节点）在空闲5分钟后没有通知客户端（TCP层上没有标志）被删除。当客户端尝试在该时间之后重用此连接时，则返回标志。我们可以轻松地将这些TCP日志中的连接重置与应用程序日志中的连接重置相匹配。FINRSTNetworkExceptions

至于，我们无法进行与找到原因时相同的匹配，这种类型的错误不再发生。但是，我们在单独的测试中确认，断开TCP连接也可能导致.我想这是因为Java Kafka Client在引擎盖下使用Java NIO套接字通道。所有消息都被缓冲，然后在连接准备就绪后进行调度。如果连接在超时（30 秒）内未就绪，则消息将过期，从而导致。TimeoutExceptionTimeoutExceptionTimeoutException

溶液

对我们来说，解决方法是将客户 connections.max.idle.ms 减少到4分钟。一旦我们应用了它，就从我们的日志中消失了。NetworkExceptions

我们仍在调查是什么在断开连接。

编辑

问题的原因是 AWS NAT 网关在 350 秒后断开传出连接。

https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html#nat-gateway-troubleshooting-timeout