记录一次kafka内网向外网提供服务问题解决

	由于近期公司需要通过kafka接收一批数据,需要另外一个公司通过spark往公司内网写数据,部署了三台kafka集群,对外提供的接口是通过nginx通过代理域名和端口提供给数据提供者.
	由于代理域名和端口无法与kafka地址进行关联,需要进行如下配置:
	1.首先是使用ambari搭建kafka进行配置,发现对方调用一直无法解析集群的域名,而且修改kafka内外网配置导致kafka无法启动;
	2.其次是通过ambari部署的kafka修改服务器上面的配置,然后启动,脱离ambari管控,发现连接超时,无法连接;
	3.搭建kafka原生集群,刚开始使用3版本以上的,由于对方版本使用的比较低,考虑到版本高兼容性的问题,就使用kafka2.5版本,并修改相关配置,具体配置如下:
############################# Server Basics #############################
broker.id=402
############################# Socket Server Settings #############################
#kafka默认监听的端口为9092
listeners=INTERNAL://0.0.0.0:6666,EXTERNAL://0.0.0.0:6667
advertised.listeners=INTERNAL://kafkaip.40:6666,EXTERNAL://外网代理域名:39665
inter.broker.listener.name=INTERNAL
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL​
# 处理网络请求的线程数量,默认为3个
num.network.threads=3
# 执行磁盘IO操作的线程数量,默认为8个
num.io.threads=8
# socket服务发送数据的缓冲区大小,默认100KB
socket.send.buffer.bytes=102400
# socket服务接受数据的缓冲区大小,默认100KB
socket.receive.buffer.bytes=102400
# socket服务所能接受的一个请求的最大大小,默认为100M
socket.request.max.bytes=104857600
############################# Log Basics #############################
# 日志存储地址
log.dirs=/data1/software/kafka_2.12-2.5.0/logs
# 每个topic默认的partition数量
num.partitions=3
# 在启动时恢复数据和关闭时刷新数据时每个数据目录的线程数量
num.recovery.threads.per.data.dir=1
############################# Internal Topic Settings  #############################
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
default.replication.factor=3
############################# Log Flush Policy #############################
# 消息刷新到磁盘中的消息条数阈值
log.flush.interval.messages=10000
# 消息刷新到磁盘中的最大时间间隔
log.flush.interval.ms=1000
############################# Log Retention Policy #############################
# 日志分片策略,单个日志文件的大小最大为1G,超出后则创建一个新的日志文件
log.segment.bytes=1073741824
# 日志保留大小,超出大小会自动删除,默认为1G,log.retention.bytes这是指定 Broker 为消息保存的总磁盘容量大小
#log.retention.bytes=1073741824
# 每隔多长时间检测数据是否达到删除条件
log.retention.check.interval.ms=300000
# 日志保留小时数,超时会自动删除,默认为7天
log.retention.hours=168

############################# Zookeeper #############################
# Zookeeper连接地址
zookeeper.connect=zkip:2181/kafka
# Zookeeper连接超时时间
zookeeper.connection.timeout.ms=18000
# Zookeeper是否允许删除topic
delete.topic.enable=true
############################# Group Coordinator Settings #############################
group.initial.rebalance.delay.ms=0

发现还是无法连接,当时考虑到与之前搭建复用的部分只有zk了,然后就重新搭建了一个单节点的zk,将kafka配置改为新搭建的单节点zk后,网络居然通啦,问题解决.

<think>嗯,用户现在遇到了一个Kafka的错误,错误信息是“Error while fetching metadata with correlation id 2 : {test1=LEADER_NOT_AVAILABLE}”。我需要先理解这个错误的原因,然后给出解决方案。 首先,这个错误通常出现在Kafka客户端尝试获取主题元数据时,但对应的分区的Leader副本不可用。可能的情况有很多,我需要逐一分析。可能的因素包括Kafka集群不可达、主题未正确创建、Broker配置问题、网络问题,或者防火墙设置阻止了通信。 用户之前的问题是关于如何清除Kafka消息队列的记录,现在转向了错误处理,说明他们在操作过程中可能遇到了这个问题。他们可能是在尝试删除主题或者生产/消费消息时遇到了这个错误。需要考虑到用户可能对Kafka的运维不熟悉,因此需要给出详细的排查步骤。 接下来,我应该分步骤解释可能的原因和解决方法。首先检查Broker是否运行正常,确保所有Kafka节点都启动并且健康状态良好。然后确认主题是否存在,特别是用户提到的test1主题。如果主题不存在,客户端请求元数据时会导致这个错误,因此需要创建主题。 然后,检查Broker的配置,特别是advertised.listeners是否正确设置。如果配置错误,客户端可能无法连接到Broker,导致无法找到Leader。另外,网络问题也不能忽视,需要检查客户端和Broker之间的网络连通性,包括端口是否开放,防火墙是否允许通信。 另外,可能需要检查Zookeeper的连接状态,虽然新版本的Kafka逐渐减少了对Zookeeper的依赖,但在某些情况下,Zookeeper的问题也可能影响Broker的状态管理。此外,日志分析也很重要,查看Broker的日志和客户端的日志,寻找更详细的错误信息。 用户可能是开发者或者运维人员,他们需要快速解决问题,所以步骤需要清晰,避免使用过于专业的术语,但又要足够详细。同时,要提醒他们在生产环境中操作时需谨慎,比如正确配置Broker,确保主题创建正确,以及处理网络问题的方法。 最后,总结常见原因和解决方案,帮助用户系统地排查问题。可能还需要给出具体的命令示例,比如使用kafka-topics.sh创建主题,检查Broker状态等,让用户可以直接执行这些命令来解决问题。</think>这个错误 `LEADER_NOT_AVAILABLE` 是 Kafka 客户端(生产者或消费者)尝试与集群通信时,无法找到主题分区的 Leader 副本导致的。常见于集群初始化、Broker 配置问题或网络故障场景。以下是可能的原因和解决方案: --- ### **1. 常见原因** - **Broker 未完全启动**:Kafka Broker 未完成启动或初始化(如 Zookeeper 未连接成功)。 - **主题未正确创建**:客户端请求的主题(如 `test1`)未被正确创建或元数据未同步。 - **Broker 配置问题**:Broker 的 `advertised.listeners` 配置错误,导致客户端无法连接 Leader。 - **网络问题**:客户端与 Broker 之间的网络不通,或防火墙阻止了端口访问。 - **分区无 Leader**:主题分区的 Leader 副本因故障未选举成功(例如 Broker 宕机)。 --- ### **2. 排查与解决步骤** #### **步骤 1:检查 Broker 状态** 确保所有 Kafka Broker 已正常启动并注册到 Zookeeper/Kraft(新版本): ```bash # 查看 Broker 是否在线 bin/zookeeper-shell.sh localhost:2181 ls /brokers/ids # 检查 Broker 日志(日志路径默认在 logs/server.log) tail -f logs/server.log ``` - 如果 Broker 未启动,重启并观察日志中的错误(如端口冲突、Zookeeper 连接失败)。 --- #### **步骤 2:确认主题是否存在** 检查主题 `test1` 是否已正确创建: ```bash # 列出所有主题 bin/kafka-topics.sh --bootstrap-server BROKER_HOST:9092 --list # 查看主题详情(确认分区 Leader 信息) bin/kafka-topics.sh --bootstrap-server BROKER_HOST:9092 --describe --topic test1 ``` - 如果主题不存在,**手动创建主题**: ```bash bin/kafka-topics.sh -- #### **步骤 3:检查 Broker 配置** 确保 Broker 的 `advertised.listeners` 配置正确(客户端实际连接的地址): ```properties # server.properties 关键配置 listeners=PLAINTEXT://0.0.0.0:9092 advertised.listeners=PLAINTEXT://BROKER_HOST:9092 # 必须能被客户端访问 ``` - 修改配置后重启 Broker。 --- #### **步骤 4:验证网络连通性** 确保客户端可以访问 Broker 的地址和端口: ```bash # 测试端口是否可达(替换为实际 Broker IP 和端口) telnet BROKER_HOST 9092 # 检查防火墙规则(如 AWS/Aliyun 安全组是否开放 9092 端口) ``` --- #### **步骤 5:查看客户端日志** 在客户端代码或日志中搜索更详细的错误信息: - 如果是生产环境,检查客户端与 Broker 的版本兼容性。 - 如果是代码连接,检查 `bootstrap.servers` 配置是否正确: ```java properties.put("bootstrap.servers", "broker1:9092,broker2:9092"); ``` --- #### **步骤 6:强制触发 Leader 选举** 如果分区 Leader 丢失,尝试重启 Broker 或手动触发选举: ```bash # 触发 Leader 重新选举(谨慎操作) bin/kafka-leader-election.sh --bootstrap-server BROKER_HOST:9092 --topic test1 --partition 0 --election-type PREFERRED ``` --- ### **3. 典型场景示例** - **场景 1**:首次创建主题后立即生产消息 **原因**:主题元数据未同步到所有 Broker。 **解决**:等待几秒后重试,或客户端配置重试机制: ```properties # 生产者/消费者配置 retries=3 retry.backoff.ms=1000 ``` - **场景 2**:Broker 的 `advertised.listeners` 配置为内网 IP,但客户端从外网连接。 **解决**:配置为公网 IP 或域名,确保客户端可访问。 --- ### **总结** - **核心问题**:客户端无法找到主题分区的 Leader 副本。 - **优先检查**:Broker 状态、主题是否存在、网络和配置。 - **临时规避**:客户端配置重试(`retries`)和超时(`request.timeout.ms`)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

jiedaodezhuti

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值