我们是随机的 NetworkExceptions 以及 TimeoutExceptions 在我们的生产环境中：
Brokers: 3
Zookeepers: 3
Servers: 3
Kafka: 0.10.0.1
Zookeeeper: 3.4.3我们偶尔会在我的生产商日志中遇到此异常：
过期10条记录topic:：自批创建加上延迟时间后已过5608毫秒。
此类错误消息中的毫秒数不断变化。有时是~5秒，有时是~13秒！
我们很少得到：
NetworkException: Server disconnected before response received.集群由3个代理和3个Zookeeper组成。生产者服务器和kafka集群在同一个网络中。
我在打同步电话。有一个web服务，多个用户请求调用它来发送数据。kafka web服务有一个producer对象来执行所有发送。生产者的请求超时最初是1000ms，现在改为15000ms（15秒）。即使在增加超时时间之后 TimeoutExceptions 仍显示在错误日志中。
原因是什么？
4条答案
按热度按时间swvgeqrz1#
增加request.timeout.ms和生产者的重试次数
zz2j4svz2#
找到根本原因有点棘手，我将放弃我的经验，希望有人会发现它有用。一般来说，它可以是一个网络问题或太多的网络洪水结合在一起
ack=ALL. 这里有一个图表解释TimeoutException从编写本文时的kafka kip-91（直到1.1.0仍然适用）：不包括网络配置问题或错误，这些属性可以根据您的场景进行调整，以减轻或解决问题：
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，以优化批处理和压缩的使用。这将减少网络中的洪水，并优化压缩，如果你正在使用它。
对于这类问题没有一个确切的答案，因为它们也取决于实现，在我的例子中，对上述值进行了实验。
wwodge7n3#
我们也遇到过类似的问题。很多
NetworkExceptions在日志中TimeoutException.原因
一旦我们从生产中收集到tcp日志，就发现到kafka代理（我们有3个代理节点）的一些tcp连接在空闲5分钟后（没有）在没有通知客户端的情况下被丢弃
FINtcp层上的标志）。当客户端在那之后尝试重新使用此连接时，则RST标志已返回。我们可以很容易地将tcp日志中的连接重置与NetworkExceptions在应用程序日志中。至于
TimeoutException，我们无法进行与找到原因时相同的匹配，此类型的错误不再发生。不过，我们在另一个测试中证实，删除tcp连接也可能导致TimeoutException. 我猜这是因为javakafka客户机在幕后使用javanio套接字通道。所有消息都将被缓冲，然后在连接就绪后进行调度。如果在超时（30秒）内连接未就绪，则消息将过期，导致TimeoutException.解决方案
对我们来说，解决办法是将客户端的connections.max.idle.ms减少到4分钟。一旦我们应用了它，
NetworkExceptions从我们的日志里消失了。我们仍在调查是什么导致连接中断。
编辑
问题的原因是aws nat网关在350秒后中断了传出连接。
https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html#nat-网关故障排除超时
ep6jt1vc4#
解决方案1
修改
属性中的
解决方案2
将broker.id更改为1001这样的值，通过设置环境变量更改brocker id
KAFKA_BROKER_ID.您必须设置环境变量
KAFKA_RESERVED_BROKER_MAX_ID像1001这样的东西被允许设置代理id为1001。我希望能有所帮助