Kafka_2.11-1.0.0消费者用--bootstrap-server失效，--zookeeper可用问题咨询

嘿，这个问题我之前帮不少同行排查过，结合你用的Kafka 2.11-1.0.0版本，主要有这几个常见的原因：

• 新旧消费者API的兼容性差异
  Kafka 1.0.0处于新旧消费者API过渡阶段：--zookeeper参数对应旧的High-Level Consumer（直接依赖ZooKeeper获取元数据），而--bootstrap-server对应新的Consumer API（通过Broker获取元数据）。新API对配置要求更严格，比如必须指定--group-id参数，否则会直接启动失败。你可以检查下自己的消费者命令是否遗漏了这个参数，正确的新消费者启动命令示例：

  kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic your_topic --group-id my_consumer_group
  

• Broker监听配置不正确
  如果Broker的listeners或advertised.listeners配置存在问题，新消费者通过--bootstrap-server连接时无法获取到可用的Broker地址。比如你只配置了内网IP的监听，但消费者在外部网络访问；或者advertised.listeners未设置，导致消费者拿到的是Broker的内部私有IP，无法建立通信。而旧的ZK方式是直接从ZooKeeper读取元数据，可能刚好绕过了这个地址匹配问题。建议去Broker的server.properties文件中检查这两个配置项，确保和消费者所在网络环境匹配。

• ACL权限限制差异
  如果你的Kafka集群开启了ACL权限控制，新消费者API需要明确的Read权限才能访问目标主题和Broker节点；而旧的ZK方式依赖的是ZooKeeper自身的权限体系，可能刚好拥有访问权限。你可以用kafka-acls.sh工具检查当前消费者对应的账号是否具备目标主题的读取权限。

• 版本固有Bug影响
  Kafka 1.0.0作为较早的版本，确实存在一些和新消费者API相关的小Bug，比如特定场景下的元数据同步失败问题。你可以尝试重启Broker和消费者进程，同时查看Broker日志（logs/server.log）和消费者日志（logs/consumer.log），里面的具体错误信息（比如Failed to update metadata）会帮你更精准地定位问题。

内容的提问来源于stack exchange，提问作者Indrajeet Gour