我已经尝试建立尽可能多的诊断到我的Kafka连接设置，但它仍然导致神秘的问题。尤其是，我要做的第一件事是使用kafka管理客户机来获取clusterid，因为如果这个操作失败，其他任何操作都不可能成功。
def getKafkaClusterId(describeClusterResult: DescribeClusterResult): Try[String] = {
try {
val clusterId = describeClusterResult.clusterId().get(futureTimeout.length / 2, futureTimeout.unit)
Success(clusterId)
} catch {
case cause: Exception =>
Failure(cause)
}
}在测试中，这通常是有效的，一切正常。它通常只在端点不可到达时失败。它失败了，因为未来超时了，所以我没有其他的诊断依据。例如，为了测试这些问题，我通常将telnet连接到端点
$ telnet blah 9094
Trying blah...
Connected to blah.
Escape character is '^]'.
Connection closed by foreign host.一般来说，如果我可以telnet到一个kafka代理，我可以从我的服务器连接到kafka。所以我的问题是：
如果我可以通过telnet与kafka代理联系，但无法通过kafka管理客户端连接，这意味着什么
还有哪些诊断技术可以解决kafka代理连接问题？
在这个特殊的例子中，我通过docker swarm在aws上运行kafka，并试图找出我的服务器无法成功连接的原因。我可以在代理日志中看到当我尝试telnet时，所以我知道代理是可以访问的。但是当我的服务器尝试连接到3个代理中的任何一个时，日志都是完全静默的。
2条答案
按热度按时间jm81lzqq1#
如果没有正确配置侦听器和advered.listeners，基本上kafka就是不听。即使telnet正在监听您配置的端口，kafka客户机库也会无声地失败。
我认为这是Kafka设计中的缺陷，导致了不必要的混乱。
p4rjhz4m2#
这是一篇很好的文章，解释了第一次连接到kafka代理时发生的步骤
https://community.hortonworks.com/articles/72429/how-kafka-producer-work-internally.html
如果您可以telnet到引导服务器，那么它正在侦听客户端连接和请求。
但是，客户机不知道哪个真正的代理是一个主题的每个分区的领导者，因此他们总是向引导服务器发送的第一个请求是元数据请求，以获取所有主题元数据的完整列表。客户机使用来自引导服务器的元数据响应来知道在何处可以与每个kafka代理建立新的连接，这些代理具有您试图生成的主题的每个主题分区的活动前导。
这就是你配置错误的经纪人问题开始起作用的地方。当您错误配置advered.listener端口时，第一个元数据请求的结果将重定向客户端以连接到无法访问的ip地址或主机名。是第二个连接超时了，而不是第一个连接。
另一种考虑方法是，您必须将kafka服务器配置为同时作为引导服务器和常规的pub/sub消息代理正常工作，因为它为客户机提供这两种服务。您的服务器被正确配置为发布/订阅服务器，但作为引导服务器配置不正确，因为内部和外部ip地址在aws中不同（也在docker容器中或nat或代理后面）。
在小型集群中，引导服务器通常是客户端最终连接到的同一个代理，这似乎有悖常理，但实际上这是一个非常有用的体系结构设计，它允许kafka无缝地扩展和故障切换，而无需在引导服务器上提供20个或更多代理的静态列表列出或维护额外的负载平衡器和运行状况检查，以知道要将客户端请求重定向到哪个代理。