listeners 是代理将用于创建服务器套接字的内容。 advertised.listeners 是客户用来连接经纪人的。
如果您有一个“复杂”的网络设置（如公用和专用子网以及中间的路由），那么这两种设置可能不同。

通过此链接：https://cwiki.apache.org/confluence/display/kafka/kip-103%3a+separation+of+internal+and+external+traffic
在0.9.0.0发布周期中，引入了对每个代理多个侦听器的支持。每个侦听器都与一个安全协议、ip/主机和端口相关联。当与播发侦听器机制结合使用时，具有相当大的灵活性，但有一个限制：在两个配置（listeners和advanced.listeners）中，每个安全协议最多有一个侦听器。
在某些环境中，出于成本、性能和安全原因，可能需要区分外部客户机、内部客户机和独立于安全协议的复制流量。一些例子说明了这一点：
复制通信量被分配给一个单独的网络接口，这样它就不会干扰客户端通信量。
外部流量通过代理/负载平衡器（安全性、灵活性），而内部流量直接影响代理（性能、成本）。
即使安全协议相同（例如，不同的已启用sasl机制集、身份验证服务器、不同的密钥库等），外部通信和内部通信的安全设置也不同
因此，我们建议kafka代理应该能够为同一安全协议定义多个侦听器，用于绑定（即侦听器）和共享（即播发的侦听器），以便在需要时可以分离内部、外部和复制通信。
所以，
侦听器—我们将侦听的URI及其协议的逗号分隔列表。将主机名指定为 0.0.0.0 绑定到所有接口。将主机名保留为空以绑定到默认接口。法律听众列表示例：
PLAINTEXT://myhost:9092,TRACE://:9091 PLAINTEXT://0.0.0.0:9092, TRACE://localhost:9093 advised.listeners—要发布到zookeeper供客户端使用的侦听器（如果与上面的侦听器不同）。在iaas环境中，这可能需要与代理绑定到的接口不同。如果未设置，则 listeners 将使用。

因为我还不能发表评论，所以我将把这个作为一个“答案”，添加到m。
在他链接的同一个文档中，有一个关于Kafka客户使用哪个监听器的简介(https://cwiki.apache.org/confluence/display/kafka/kip-103%3a+separation+of+internal+and+external+traffic):
如前所述，客户机永远看不到侦听器名称，并且会像以前一样发出元数据请求。不同之处在于，它们返回的端点列表仅限于发出请求的端点的侦听器名称。
这一点很重要，因为这取决于您在bootstrap.servers配置中使用的url*，如果在advised.listeners中Map，则客户端将返回该url*（如果侦听器不存在，则不知道该行为是什么）。
请注意：
例外是基于zookeeper的消费者。这些使用者直接从zookeeper检索代理注册信息，并将选择第一个明文侦听器作为安全协议（他们支持的唯一安全协议）。
例如broker config（对于集群中的所有代理）：
播发的.listeners=external://xx.compute-1.amazonaws.com:9990,internal://ip-xx.ec2.internal:9993
inter.broker.listener.name=内部
listener.security.protocol.map文件=external:ssl,internal:plaintext
如果客户端使用xx.compute-1.amazonaws。com:9990 to 连接，元数据获取将转到该代理。但是，要与组协调器或领导一起使用的返回url可以是123.compute-1.amazonaws。com:9990*（另一台机器！）。这意味着匹配是在kip-103公布的侦听器名称上完成的，与实际的url（节点）无关。
由于外部ssl的协议Map是ssl，因此这将强制您使用ssl密钥库进行连接。
另一方面，如果您在aws中，那么您可以发布ip-xx.ec2。internal:9993 and 根据协议Map，相应的连接将是明文的。
这在iaas中尤其需要，在我的案例中，代理和消费者住在aws上，而我的生产者住在客户机站点上，因此需要不同的安全协议和侦听器。
编辑：添加入站规则也容易得多，因为您有不同的端口用于不同的客户机（代理、生产者、消费者）。
edit2：如果上面的内容还不清楚的话，这篇文章是一个非常深入的指南：https://rmoff.net/2018/08/02/kafka-listeners-explained/