Kafka生产者网络异常和超时异常

Question

我们的生产环境中出现了随机的NetworkExceptions和TimeoutExceptions：

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

我们偶尔会在我的生产者日志中得到这个异常：

主题：XXXXXX：5608 ms的过期记录自批量创建加上逗留时间以来已经过去。

此类错误消息中的毫秒数不断变化。有时是5秒，有时是13秒！

我们很少能得到：

NetworkException: Server disconnected before response received. 

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

我在打同步电话。有一个web服务，多个用户请求调用它来发送数据。Kafka web服务有一个Producer对象，负责所有发送操作。制作人的请求超时最初为1000毫秒，后来改为15000毫秒（15秒）。即使在增加超时时间后，TimeoutExceptions仍会显示在错误日志中。

原因是什么？

Answer 1

解决方案1

修改

listeners=PLAINTEXT://hostname:9092

属性。属性文件到

listeners=PLAINTEXT://0.0.0.0:9092

解决方案2

换经纪人。将id设置为1001这样的值，通过设置环境变量KAFKA_BROKER_id来更改brocker id。

您必须将环境变量KAFKA_RESERVED_BROKER_MAX_ID设置为像1001这样的值，才能将BROKER ID设置为1001。

我希望能有所帮助

Answer 2

我们也面临过类似的问题。日志中的许多NetworkExceptions不时地TimeoutExc0019。

原因

一旦我们从生产中收集了TCP日志，结果发现一些到Kafka代理（我们有3个代理节点）的TCP连接在空闲5分钟后没有通知客户端就被删除了（TCP层上没有FIN标志）。当客户端在此之后尝试重新使用此连接时，将返回RST标志。我们可以很容易地将TCP日志中的这些连接重置与应用程序日志中的NetworkExceptions相匹配。

至于TimeoutException，我们无法进行与找到原因时相同的匹配，这种类型的错误不再发生。然而，我们在另一项测试中确认，断开TCP连接也可能导致TimeoutException。我猜这是因为Java Kafka客户端在幕后使用Java NIO套接字通道。所有消息都将被缓冲，然后在连接就绪后被发送。如果连接在超时（30秒）内未就绪，则消息将过期，导致TimeoutException。

解决方案

对我们来说，解决办法是减少连接。麦克斯，空闲。ms在我们的客户身上停留了4分钟。一旦我们应用了它，NetworkExceptions就从我们的日志中消失了。

我们仍在调查是什么导致连接中断。

编辑

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

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

Answer 3

要找到根本原因有点棘手，我将放弃我的经验，希望有人会发现它有用。一般来说，这可能是网络问题，或者与ack=ALL相结合的网络洪水过多。下面是一个图表，解释了在撰写本文时KafkaKIP-91中的TimeoutException（在1.1.0之前仍然适用）：

除了网络配置问题或错误之外，您可以根据场景调整以下属性，以缓解或解决问题：

>

buffer.memory控制生产者用于缓冲的总可用存储器。如果记录被发送的速度快于它们可以被传输到Kafka然后，这个缓冲区将得到超过然后额外的发送调用阻止max.block.ms之后，生产者抛出一个TimeoutExc0019。

麦克斯街区。ms的值已经很高，我不建议进一步增加它。缓冲器内存的默认值为32MB，根据您的邮件大小，您可能希望增加它；如有必要，增加jvm堆空间。

重试定义在放弃之前，在出现错误的情况下重新发送记录的尝试次数。如果您使用零重试，您可以尝试通过增加此值来缓解问题，除非您将max.in.flight.requests.per.connection设置为1，否则请注意记录顺序不再是保证。

一旦达到批量大小或经过延迟时间（以先到者为准），就会发送记录。如果批量生产。大小（默认为16kb）小于最大请求大小，可能您应该使用更高的值。此外，变化依然存在。ms设置为更高的值，例如10、50或100，以优化批次和压缩的使用。这将减少网络中的洪水，并在使用时优化压缩。

对于这类问题没有一个确切的答案，因为它们也取决于实现，在我的例子中，对上述价值观进行了实验。