在 kafka 代理中配置 listeners 属性的正确方法答案

【问题标题】：Right way to configure listeners property in kafka brokers在 kafka 代理中配置 listeners 属性的正确方法
【发布时间】：2019-07-10 21:35:07
【问题描述】：

我们有一个由 5 个代理组成的集群，并配置了 server.properties，如下所示

listeners=PLAINTEXT://kafka1:9092
Advertising.listeners=PLAINTEXT://kafka1:9092

我在所有代理、生产者和消费者的 /etc/hosts 文件中添加了如下条目

“私有:IP:kafka:broker1”kafka1

这在很大程度上对我们有用，我们在配置新消费者时不必记住引导服务器的私有 IP。

我想知道这是否是在 kafka 经纪人和客户之间进行交流的好方法？

由于我不是 DevOps 人员，我不确定这是否会导致潜在的问题。请对此发表评论。

另一件事是我看到 Kafka 代理和客户端之间的随机断开连接会导致不同的问题。我只是想清除这以某种方式引起问题的可能性。

【问题讨论】：

【解决方案1】：

我在所有代理、生产者和消费者的 /etc/hosts 文件中添加了如下条目

这是不好的。请不要这样做

如果您无法单独通过 bootstrap.servers 属性解析主机，则侦听器不正确。

请阅读this explanation of Kafka Listeners 了解您想要的所有详细信息。

在配置新消费者时，我们不必记住引导服务器的私有 IP

您可以使用服务发现 工具来解决这个问题。 Consul 很受欢迎，然后您只需指向kafka.service.consul:9092，它就可以通过 DNS 的魔力“正常工作”。

或者您应该在已经预先配置至少引导服务器设置的 Kafka 客户端库上进行标准化，然后在内部将此“库”发布给您的开发人员以供使用

【讨论】：

好的。根据文章，似乎在本地 /etc/hosts 文件中硬编码 I.P 的唯一问题是它是一种脆弱的方法，并且有点像 hack。因为我们所有的 Kafka 客户端都在同一个 VPC 中，所以我会将所有代理的广告侦听器更改为他们的私有 I.P。就随机断开而言，我认为这种黑客攻击不会导致这样的问题。或者可以吗？
随机断开连接可能是客户端超时异常或 Zookeeper 延迟（正如我之前提到的），或者您的 VPC 背后的硬件无法跟上复制以及客户端请求，例如iowait 和 cpu 负载等。但是不，/etc/hosts "hack" 仅在您尝试扩展集群，或者您在云中重新启动服务器，并且 IP 更改时才坏
谢谢，伙计。我认为断开连接问题是由于 Kafka 本身存在的问题。就配置 Kafka 侦听器属性而言，您的想法看起来很完美。
如果您认为问题出在 Kafka 本身，我们非常欢迎您打开 JIRA 或通过电子邮件发送 Kafka 邮件列表以供核心开发人员进一步调查