一、问题现象
搭建3节点Kafka集群（master、slave1、slave2），启动后日志疯狂刷屏报错，核心报错信息如下：
plain text[2026-04-11 15:13:09,594] INFO [Controller id=0, targetBrokerId=2] Node 2 disconnected. (org.apache.kafka.clients.NetworkClient)[2026-04-11 15:13:09,594] INFO [Controller id=0, targetBrokerId=2] Cancelled in-flight LEADER_AND_ISR request with correlation id 105 due to node 2 being disconnected…报错反复出现，表现为Controller无法与slave1（Node1）、slave2（Node2）建立通信，但Kafka进程已正常启动，且Hadoop集群、SSH、Ping均能正常使用，排除基础网络故障。核心矛盾：Kafka进程存活，但集群节点间通信失败，无法正常组成3节点集群。

二、排查过程（按优先级排序，逐步排除）

1. 初步判断：怀疑网络不通
   最直观的报错是“Node disconnected”，首先排查集群节点间网络连通性，执行以下命令验证：# master节点ping slave1、slave2
   ping slave1
   ping slave2
   # 验证SSH连通性
   ssh slave1
   ssh slave2

结果：3节点间Ping无丢包（延迟<1ms），SSH可正常登录，Hadoop集群也能正常运行，排除网络不通问题。
2. 排查Kafka核心配置
查看3节点的kafka/config/server.properties配置文件，重点检查3个核心参数（集群通信关键）：
•broker.id：master=0、slave1=1、slave2=2，唯一且正确，无重复。
•listeners：master配置为PLAINTEXT://master:9092，slave1为PLAINTEXT://slave1:9092，slave2为PLAINTEXT://slave2:9092，格式正确。
•zookeeper.connect：3节点均配置为master:2181,slave1:2181,slave2:2181，ZK集群正常，无配置错误。
结论：核心配置无明显错误，排除配置写错问题。
3. 排查防火墙拦截（高频坑）
Kafka集群通信依赖9092端口，若防火墙未关闭，会拦截节点间的9092端口连接，执行命令查看并关闭防火墙（CentOS 7/8通用）：
bash

查看防火墙状态（3节点均执行）

sudo systemctl status firewalld

关闭并禁用防火墙（3节点均执行）

sudo systemctl stop firewalld
sudo systemctl disable firewalld
结果：3节点防火墙均为inactive（dead）状态，已关闭，排除防火墙拦截问题。
4. 排查主机名匹配问题
Kafka内部通信依赖主机名解析，若系统实际hostname与配置中的主机名不匹配，会导致通信失败，执行命令验证：
hostname
ssh slave1 hostname
ssh slave2 hostname

结果：master输出master、slave1输出slave1、slave2输出slave2，与配置中的主机名完全一致，排除主机名不匹配问题。
5. 排查Kafka进程与端口监听
验证Kafka进程是否正常启动，以及9092端口是否正常监听：

查看Kafka进程（3节点均执行）

jps
# 验证9092端口监听（master节点执行）
telnet slave1 9092
telnet slave2 9092
结果：3节点均有Kafka进程，9092端口可正常监听，排除进程未启动、端口被占用问题。
6. 最终排查：advertised.listeners配置缺失（根因）
经过以上排查，所有基础环境和配置均正常，重点关注Kafka通信的隐藏配置——advertised.listeners：
查看配置文件发现，3节点均未配置advertised.listeners参数。Kafka内部通信优先使用advertised.listeners指定的地址，若未配置，Java会自动解析主机名，可能出现解析错乱，导致节点间无法建立通信，最终报“Node disconnected”。注意我下面只是salve1的，master 的和slave 2的都要对应其名字

三、根因分析
本次Kafka集群节点通信失败的核心根因：未配置advertised.listeners参数。
补充说明：
•listeners：指定Kafka服务监听的地址和端口，用于接收客户端和其他节点的连接请求。
•advertised.listeners：指定Kafka向ZK注册的地址，其他节点通过该地址与当前节点通信，若未配置，会默认使用listeners的值，但Java自动解析可能出现异常（尤其集群环境），导致通信失败。
这是Kafka教程中99%学习者都会踩的坑——教程中可能默认配置了该参数但未重点强调，导致新手容易遗漏。
四、 查看master节点日志，确认无报错
tail -f /opt/module/kafka/logs/server.log
修复后日志特征（正常状态）：
•出现[KafkaServer id=0] started，说明Kafka服务正常启动。
•出现Recorded new controller, from now on will use broker slave1:9092，说明节点间已成功识别并建立通信。
•无任何Node disconnected报错，日志干净稳定

五、排查总结与注意事项

1. 排查思路总结
   遇到Kafka集群“Node disconnected”报错，按以下优先级排查，高效定位问题：
   1.验证网络连通性（Ping、SSH）→ 排除基础网络问题。
   2.关闭防火墙 → 排除端口拦截问题。
   3.检查Kafka核心配置（broker.id、listeners、zookeeper.connect）→ 排除配置错误。
   4.验证主机名匹配 → 排除主机名解析问题。
   5.检查advertised.listeners配置 → 重点排查隐藏坑（本次根因）。
2. 关键注意事项（新手必看）
   •搭建Kafka集群时，必须同时配置listeners和advertised.listeners，且地址与主机名一致，避免Java自动解析异常。
   •3节点集群中，broker.id必须唯一，不可重复，否则会导致集群启动失败或通信异常。
   •排查时优先查看日志，Kafka的server.log会明确提示报错原因，避免盲目操作。
   •若后续仍有通信问题，可尝试清空Kafka日志目录（/opt/module/kafka/logs/*），清除旧元数据后重启集群。