【kafka】kafka broker 节点主机名解析导致kaf

2025-05-06  本文已影响0人  Bogon

3 节点的 kafka集群（依赖zookeeper）:

192.168.31.183   
192.168.31.199   
192.168.31.178

本机就是 192.168.31.178 ，在本机上执行，为什么会耗时这么长？！

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether fa:20:9a:77:32:00 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 192.168.31.178/24 brd 192.168.31.255 scope global noprefixroute ens3


$ time /path/to/kafka/bin/kafka-topics.sh  --list  --zookeeper 192.168.31.178:2181

real    0m21.216s
user    0m1.467s
sys     0m0.281s

在本机执行 kafka-topics.sh --list --zookeeper 命令耗时长达21秒，远高于正常水平（通常应小于1秒）。

尽管直接使用IP地址，但Kafka/ZooKeeper内部可能触发反向DNS查询（如日志记录或安全认证）。检查 /etc/hosts 是否配置本机IP与主机名映射，避免DNS阻塞 。

kafka集群明明是基于ip组件的集群。

在 kafka 3节点 /etc/hosts 下添加kafka集群3节点解析：

192.168.31.183   bogon-cache01
192.168.31.199   bogon-cache02
192.168.31.178   bogon-cache03

$ time /kingdee/kafka/bin/kafka-topics.sh --list --zookeeper 192.168.31.178:2181

real    0m1.233s
user    0m1.501s
sys     0m0.338s

问题就解决了 ，为什么？

在 Kafka 和 ZooKeeper 的架构中，即使集群节点间通过 IP 地址进行通信，某些组件或操作仍可能依赖 主机名解析（hostname resolution），尤其是在以下场景中：

关键原因分析

1. Kafka/ZooKeeper 内部对主机名的隐式依赖

2. Kafka Broker 的 advertised.listeners 配置问题

3. ZooKeeper 的 Session 建立延迟

验证步骤

  1. 检查 Kafka 配置：

    grep advertised.listeners /path/to/kafka/config/server.properties

    如果输出类似 PLAINTEXT://bogon-cache03:9092，则需确保 bogon-cache03 能被解析为 IP。

  2. 手动测试主机名解析：

    # 清除本地 DNS 缓存（Linux）
sudo systemd-resolve --flush-caches

# 测试主机名解析
time nslookup bogon-cache03

    如果解析耗时超过 1 秒，则表明系统依赖 DNS 且存在延迟。

  3. 检查 ZooKeeper 中存储的 Broker 元数据：

    # 进入 ZooKeeper CLI
zkCli.sh -server 192.168.31.178:2181

# 查看 Broker 注册信息
get /brokers/ids/0

    输出内容可能包含主机名（如 "host":"bogon-cache03"），此时 Kafka CLI 工具需解析该主机名。

解决方案的本质

将主机名与 IP 的映射写入 /etc/hosts 后，系统会优先从本地文件解析主机名，避免触发 DNS 查询，从而消除网络延迟。这是生产环境中常见的优化手段，尤其适用于以下情况：

最佳实践建议

  1. 统一使用 IP 配置（推荐）：
    在 Kafka 的 server.properties 中显式指定 advertised.listeners 为 IP 地址，避免依赖主机名：

    advertised.listeners=PLAINTEXT://192.168.31.178:9092

  2. 完善 /etc/hosts 配置：
    在所有节点的 /etc/hosts 中定义集群节点的主机名与 IP 映射，确保本地解析快速可靠：

    192.168.31.178 bogon-cache03
192.168.31.183 bogon-cache01
192.168.31.199 bogon-cache02

  3. 禁用反向 DNS 解析（高级）：
    修改 Kafka/ZooKeeper 的 JVM 参数，禁用 Java 的默认反向 DNS 解析：

    -Dsun.net.inetaddr.ttl=5  # 设置 DNS 缓存时间
-Djava.net.preferIPv4Stack=true
-Djava.net.preferIPv6Addresses=false

总结

尽管 Kafka 集群基于 IP 通信，但其元数据管理（通过 ZooKeeper）和部分网络操作仍可能依赖主机名解析。
若未正确配置 /etc/hosts 或 DNS，会导致 CLI 工具因解析延迟而卡顿。
通过本地绑定主机名与 IP，可彻底规避 DNS 查询的不确定性，显著提升操作效率。

如果不在 etc/hosts 手动写解析，注释掉 /etc/resolv.conf 也可以解决。为什么 ?

在 Kafka 集群中，若选择不手动配置 /etc/hosts，而是通过注释 /etc/resolv.conf 中的 DNS 配置来解决主机名解析延迟问题，其核心逻辑与 Linux 系统的解析机制和 Kafka 的依赖关系密切相关。以下是具体分析：

1. 系统解析流程的优先级：/etc/hosts 优先于 DNS

2. Kafka/ZooKeeper 的主机名依赖场景

3. 注释 resolv.conf 的潜在效果

4. 为何实际测试中问题被解决？

5. 风险与注意事项

总结

注释 /etc/resolv.conf 能解决 Kafka 命令延迟问题，本质是通过阻断 DNS 查询路径，避免因解析失败或超时导致的阻塞。但这一方法依赖 Kafka 的实际配置（如是否使用 IP 地址）和工具链的容错能力，存在较大风险，不建议作为长期方案。推荐优先完善 /etc/hosts 配置，并排查 Kafka 的主机名依赖场景，以实现更稳定的集群管理。

kafka 配置参数 advertised.listeners 解析

Kafka advertised.listeners 参数详解

advertised.listeners 是 Apache Kafka 中一个非常重要的配置参数，它决定了客户端如何连接到 Kafka 集群。下面我将详细解析这个参数的作用、配置方式，并通过多个示例说明其用法。

基本概念

advertised.listeners 参数用于指定 Kafka 代理(broker)向客户端公布的监听地址。当客户端连接到 Kafka 集群时，会从 broker 获取这个地址，然后使用该地址进行后续通信。

与 listeners 参数的区别

这两个参数通常需要配合使用，特别是在复杂的网络环境中。

参数格式

advertised.listeners 的格式为：

协议://主机名或IP:端口

支持的协议包括：

典型配置示例

示例1：简单本地环境

listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://localhost:9092

示例2：多协议配置

listeners=PLAINTEXT://:9092,SSL://:9093
advertised.listeners=PLAINTEXT://kafka.example.com:9092,SSL://kafka-secure.example.com:9093

示例3：Docker/Kubernetes 环境

listeners=PLAINTEXT://0.0.0.0:9092
advertised.listeners=PLAINTEXT://kafka-broker-1:9092

示例4：AWS EC2 环境

listeners=PLAINTEXT://0.0.0.0:9092
advertised.listeners=PLAINTEXT://ec2-12-34-56-78.compute-1.amazonaws.com:9092

高级场景

场景1：内外网分离

当 Kafka 集群部署在云环境中，内部服务和外部客户端需要不同的访问地址：

listeners=PLAINTEXT://0.0.0.0:9092,INTERNAL://0.0.0.0:19092
advertised.listeners=PLAINTEXT://public.example.com:9092,INTERNAL://kafka-internal:19092
listener.security.protocol.map=PLAINTEXT:PLAINTEXT,INTERNAL:PLAINTEXT

场景2：Kubernetes StatefulSet

在 Kubernetes 中使用 StatefulSet 部署 Kafka：

listeners=PLAINTEXT://0.0.0.0:9092
advertised.listeners=PLAINTEXT://${HOSTNAME}.kafka-headless.default.svc.cluster.local:9092

常见问题解决

  1. 客户端连接问题：如果客户端无法连接，检查 advertised.listeners 是否配置了客户端可访问的地址

  2. DNS解析问题：确保 advertised.listeners 中的主机名可以被客户端解析

  3. 防火墙问题：确保 advertised.listeners 指定的端口在防火墙中是开放的

  4. 协议不匹配：确保客户端使用的协议与 advertised.listeners 中配置的协议一致

最佳实践

  1. 在生产环境中，总是明确配置 advertised.listeners
  2. 在云环境中，使用环境变量动态设置 advertised.listeners
  3. 对于容器化部署，考虑使用 headless 服务的 DNS 记录
  4. 定期测试从客户端网络到 advertised.listeners 的连接性

通过合理配置 advertised.listeners，可以确保 Kafka 集群在各种网络环境下都能被正确访问。

如何解读下面这段话？

kafka 中通过一个参数 advertised.listeners，来控制接收消息的ip和端口，同时这个地址也会注册到 zookeeper 中，当有请求连接到kafka时，如果和注册到zookeeper的kafka信息不匹配无法进行连接。

advertised.listeners 是 Kafka 中一个非常重要的配置参数，它决定了客户端和其他 Broker 如何连接到当前 Broker。
如果配置不正确，可能会导致客户端无法正常连接或通信失败。

下面详细总结其核心机制和关键注意事项：

1. advertised.listeners 的核心作用

2. 关键配置规则

(1) 必须与 listeners 配合使用

(2) 地址必须可被客户端访问

3. 典型配置场景

场景 1：本地开发（单机）

# Broker 监听本地回环地址
listeners=PLAINTEXT://127.0.0.1:9092
# 注册到 ZooKeeper 的地址（客户端直接连接）
advertised.listeners=PLAINTEXT://127.0.0.1:9092

场景 2：云服务器（公网访问）

# 监听内网 IP 和端口
listeners=PLAINTEXT://10.0.0.1:9092
# 注册公网 IP（客户端通过公网连接）
advertised.listeners=PLAINTEXT://54.32.10.5:9092

场景 3：Docker/K8s 环境

# 监听容器内所有网卡
listeners=PLAINTEXT://0.0.0.0:9092
# 注册宿主机映射的地址（需端口映射）
advertised.listeners=PLAINTEXT://host-machine-ip:31092

场景 4：内外网分离（多协议）

# 内网走 PLAINTEXT，外网走 SSL
listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093
advertised.listeners=INTERNAL://192.168.1.100:9092,EXTERNAL://api.kafka.example.com:9093
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:SSL
inter.broker.listener.name=INTERNAL  # Broker 间通信使用内网

4. 常见问题与排查

问题 1：客户端连接超时或无法连接

问题 2：Broker 间通信失败

问题 3：ZooKeeper 中的地址与实际不符

5. 验证工具

  1. kafkacat 测试连接： 
    kafkacat -L -b <bootstrap-server>  # 查看 Broker 返回的元数据地址
  2. Telnet/Netcat 检查端口： 
    nc -vz <advertised-ip> <advertised-port>

总结

参考

Kafka超时异常全解析：从TimeoutException到集群配置优化
https://mp.weixin.qq.com/s/ZlaPBW3xTLwypgjZl4Dlkg

关于一个kafka无法正常连接问题的部署处理
https://mp.weixin.qq.com/s/bpm7WF-C4OlIvnIl7tC0CQ

kafka中的advertised.listeners你真的理解吗
https://mp.weixin.qq.com/s/OiAoqLqoegDF2i03z7eMcA

Kafka的数据可靠性保障与网卡隔离问题
https://mp.weixin.qq.com/s/ADTAJPZ7aJG8elj6GtbOkQ

Kafka系列之生产级集群参数配置
https://mp.weixin.qq.com/s/qzXiCB45zhYwv9yApyCvLA

上一篇 下一篇

猜你喜欢

热点阅读