跨VM部署Kafka发送消息异常：vm-2发送时报TimeoutException

我来帮你分析下这个TimeoutException问题，这种情况通常是生产者没法在规定时间内和vm-2的Kafka Broker建立连接或者完成消息确认，咱们一步步排查：

• 首先确认你的应用所在机器能不能ping通vm-2的IP，别想当然觉得vm-1能通就vm-2也没问题——毕竟是两台独立VM，网络策略可能完全不一样。
• 测试Kafka端口是否可达：用telnet vm-2-ip 9092或者nc -zv vm-2-ip 9092试试，如果连接失败，十有八九是vm-2的防火墙/安全组把9092端口给挡住了，得手动打开这个端口的入站规则。
• 重点检查Kafka Broker的listeners配置：如果vm-2的Kafka配置里listeners写的是PLAINTEXT://localhost:9092，那它只接受本地请求，外部应用根本连不上！赶紧改成PLAINTEXT://0.0.0.0:9092（允许所有网卡访问）或者vm-2的具体IP，比如PLAINTEXT://192.168.1.100:9092，改完记得重启Kafka服务。

• 先确认bootstrap-servers是不是填对了vm-2的IP和端口，别手滑写成vm-1的地址了，这种低级错误很容易犯。
• 调整超时相关配置：默认的request.timeout.ms是30秒，如果vm-2的网络延迟高或者Broker处理慢，可能不够用，可以改成60秒试试。另外delivery.timeout.ms要对应调大，它是消息从发送到判定失败的总超时时间，得大于等于request.timeout.ms + retry.backoff.ms * retries的总和。
• 临时调整消息确认机制：如果你的生产者配置了acks=all，需要所有ISR副本都确认消息才算成功。要是vm-2的Kafka副本配置有问题（比如只有1个副本却设了acks=all，或者副本同步太慢），也会触发超时。可以先把acks改成1试试，如果能发送成功，再去排查Broker的副本配置问题。

• 登录vm-2，去Kafka的日志目录（一般是logs/server.log）看看有没有报错，比如启动失败、副本同步异常、磁盘满了之类的问题——这些都会导致Broker没法正常处理请求。
• 用Kafka自带工具验证Broker是否正常运行：执行kafka-topics.sh --list --bootstrap-server localhost:9092，如果能正常列出主题，说明Broker服务是正常的。
• 别漏了advertised.listeners配置：这个是Broker告诉生产者自己的对外地址，如果配置的是localhost或者错误的IP，生产者会拿到错误的地址去连接，自然就超时了。一定要把它设成外部机器能访问到的vm-2的IP和端口，比如PLAINTEXT://192.168.1.100:9092。

• 如果你的应用是在容器里跑的，还要检查容器的网络模式，比如是不是用了host模式？或者容器有没有权限访问vm-2所在的网络？
• 看看vm-2的系统资源：CPU、内存、磁盘IO是不是跑满了？如果Broker机器资源耗尽，处理请求的速度会慢到离谱，超时也就不奇怪了。

内容的提问来源于stack exchange，提问作者Ajey kumar HB