Kafka经纪人ip可以用在消费者还是生产者？
我有两台机器localhost和192.168.1.110来运行两台独立的单机kafka。
kafka2.11-0.10.0.0 bin/kafka-console-producer.sh--broker-list 192.168.1.110:9092--topic test这是一条消息[2016-08-24 18:15:27,441]错误将消息发送到topic test时出错，关键字：null，值：2个字节，错误字段：（org.apache.kafka.clients.producer.internals.errorLoggingCallback）org.apache.kafka.common.errors.TimeoutException：包含1条记录的批处理由于从测试的代理请求元数据时超时而过期-0
为什么消息不能发送到192.168.1.110的broker？我可以直接在消费者或生产者中使用代理ip吗？如果只能使用hostname，是否与advertised.host.name相关？那么如何设置advertised.host.name呢？这个主机名应该是全局可解析的吗（我可以使用/etc/hosts来解析主机名吗？）
（2）我编辑了/etc/hosts以让localhost指向192.168.1.110，然后运行:kafka2.11-0.10.0.0bin/kafka-console-producer.sh--broker-list localhost:9092-topic test
我可以成功地将消息发送到192.168.1.110并在那里使用这些消息。
（3）我编辑了/etc/hosts以让rrlocalhost指向192.168.1.110，然后运行:kafka2.11-0.10.0.0bin/kafka-console-producer.sh--broker-list rrlocalhost：9092--topic test
然后我向rrlocalhost发送消息，出现了与（1）相同的错误。
共有1个答案
当然你可以直接使用ip地址。
broker配置advertised.host.name将在zookeeper中注册，生产者和消费者将作为集群元数据获取它们。如果您使用本地nick名称来配置它，生产者和消费者将很难与它通信。
-
我有一组Kafka代理实例作为集群运行。我有一个客户正在生产数据给Kafka： 当我们使用tcpdump进行监控时，我可以看到只有到broker1和broker2的连接被建立，而对于broker3，没有来自我的生产者的连接。我有一个只有一个分区的单一主题。 我的问题是: > 为什么在我的情况下，我无法连接到broker3？或者至少我的网络监控没有显示我的制作人与broker3建立了连接？ 如果我能
-
在这种情况下，我是否需要求助于Kafka事务API来在消费者轮询循环中创建事务生产者，在该循环中，我在事务中执行：（1）处理消耗的记录和（2）在关闭事务之前提交它们的偏移量。在这种情况下，普通的commitsync/commitasync是否有效？
-
我在一台Windows主机上安装了两个Kafka 2.1.0代理。默认复制因子设置为2。所有其他设置均为默认设置。 networkClient:[Consumer ClientID=Consumer-1,GroupID=SOUT]无法建立到节点-2(/192.168.0.1:19092)的连接。代理可能不可用。 消费者： 一个制作人：
-
我目前正在开发Kafka模块，我正在使用Kafka通信的抽象。我能够集成生产者 Spring Boot测试类 监听器类 我的问题是：在测试类中，我断言分区、有效负载等是从BlockingQueue轮询的，然而，我的问题是如何验证用KafkaListener注释的类中的业务逻辑是否得到正确执行，并根据错误处理和其他业务场景将消息路由到不同的主题。在一些示例中，我看到了CountDownLatch的断
-
向Kafka推送100,000条消息 在使用者使用所有100,000条消息之前，使用Ctrl-C关闭zookeeper和kafka服务（这是通过在consumer方法中使用来模拟的）。 发现 在zookeeper和kafka服务被关闭后，消费者继续在控制台上写消息。 问题 我如何使消费者从上次消费的消息的索引+1继续。 向Kafka推送100,000条消息 在使用者使用所有100,000条消息之前
-
我们正在运行活动 MQ 5.6.0。在我们的测试环境中，我们有 3 个代理在静态网络中运行。下面是当前方案。我们有6个消费者随机连接到3个经纪人。一个经纪人有3个消费者，第二个有2个，第三个有1个。当我们向队列堆积消息时，我们看到消息积压在第三个代理上，有 1 个使用者，另外两个代理没有获得任何积压，其余 5 个使用者处于空闲状态。 在下面，您将找到我们所有一个代理（dev.queue01）的配置