Kafkaサーバー構成-リスナーとadvertised.listeners
Kafkaを実行するには、config/server.propertiesファイルにいくつかのプロパティを設定する必要があります。理解できない設定が2つあります。
リスナーとadvertised.listenersプロパティの違いを誰かが説明できますか？
ドキュメントには次のように書かれています：
リスナー：ソケットサーバーがリッスンするアドレス。
そして
advertised.listeners：ブローカーがプロデューサーとコンシューマーにアドバタイズするホスト名とポート。
どの設定をいつ使用する必要がありますか？
私はまだコメントできないので、これを「回答」として投稿し、M.Situationsの回答に追加します。
彼がリンクしている同じドキュメント内には、KAFKAクライアントが使用しているリスナーについての宣伝文句があります（ https://cwiki.Apache.org/confluence/display/KAFKA/KIP-103% 3A + Separation + of + Internal + and + External + traffic ）：
前述のように、クライアントはリスナー名を参照することはなく、以前とまったく同じようにメタデータ要求を行います。違いは、返されるエンドポイントのリストは、リクエストを行ったエンドポイントのリスナー名に制限されることです。
これは、クライアントがadvertised.listenersにマッピングされている場合にクライアントが取得するURL *になるbootstrap.servers構成で使用するURLに依存するため重要です（リスナーが存在しない場合の動作がわからない） ）。
これにも注意してください：
例外は、ZooKeeperベースのコンシューマーです。これらのコンシューマは、ZooKeeperからブローカー登録情報を直接取得し、セキュリティプロトコル（サポートする唯一のセキュリティプロトコル）としてPLAINTEXTを持つ最初のリスナーを選択します。
ブローカー設定の例として（クラスター内のすべてのブローカー用）：
advertised.listeners = EXTERNAL：//XXXXX.compute-1.amazonaws.com：9990、INTERNAL：//ip-XXXXX.ec2.internal：9993
inter.broker.listener.name = INTERNAL
listener.security.protocol.map = EXTERNAL：SSL、INTERNAL：PLAINTEXT
クライアントがXXXXX.compute-1.amazonaws.com:9990を使用して接続する場合、メタデータフェッチはそのブローカーに送られます。ただし、Group CoordinatorまたはLeaderで使用する戻りURLは123.compute-1.amazonaws.com:9990*（別のマシン！）です。これは、実際のURL（ノード）に関係なく、KIP-103によってアドバタイズされたリスナー名で一致が行われることを意味します。
EXTERNALのプロトコルマップはSSLであるため、SSLキーストアを使用して接続する必要があります。
一方、AWS内にいる場合、たとえばip-XXXXX.ec2.internal：9993を発行すると、対応する接続はプロトコルマップに従ってプレーンテキストになります。
これは、ブローカーと消費者がAWSに住んでいるIaaSで特に必要ですが、プロデューサーはクライアントサイトに住んでいるため、異なるセキュリティプロトコルとリスナーが必要です。
編集：また、クライアント（ブローカー、プロデューサー、コンシューマ）ごとに異なるポートがあるため、インバウンドルールの追加もはるかに簡単になりました。
listenersは、ブローカーがサーバーソケットの作成に使用するものです。
advertised.listenersは、クライアントがブローカーに接続するために使用するものです。
「複雑な」ネットワーク設定がある場合、2つの設定は異なる場合があります（パブリックサブネットとプライベートサブネット、およびその間のルーティングなど）。
0.9.0.0リリースサイクル中に、ブローカーごとに複数のリスナーのサポートが導入されました。各リスナーは、セキュリティプロトコル、IP /ホスト、およびポートに関連付けられています。アドバタイズされたリスナーメカニズムと組み合わせると、2つの構成（リスナーとadvertised.listeners）のセキュリティプロトコルごとに最大1つのリスナーという1つの制限があり、かなりの柔軟性があります。
環境によっては、コスト、パフォーマンス、およびセキュリティ上の理由から、セキュリティプロトコルに関係なく、外部クライアント、内部クライアント、レプリケーショントラフィックを区別したい場合があります。これを説明するいくつかの例：
- レプリケーショントラフィックは、クライアントトラフィックに干渉しないように、個別のネットワークインターフェイスに割り当てられます。
- 外部トラフィックはプロキシ/ロードバランサーを通過し（セキュリティ、柔軟性）、内部トラフィックはブローカーに直接ヒットします（パフォーマンス、コスト）。
- セキュリティプロトコルが同じであっても、外部トラフィックと内部トラフィックのセキュリティ設定が異なる（有効なSASLメカニズム、認証サーバー、異なるキーストアなどの異なるセット）
そのため、Kafkaブローカーは、バインディング（リスナー）と共有（つまりadvertised.listeners）の同じセキュリティプロトコルに対して複数のリスナーを定義して、内部、外部、およびレプリケーショントラフィックができるようにすることを提案します必要に応じて区切られます。
そう、
listeners-リッスンするURIとそのプロトコルのコンマ区切りリスト。ホスト名を0.0.0.0として指定して、すべてのインターフェースにバインドします。ホスト名を空のままにして、デフォルトのインターフェースにバインドします。正当なリスナーリストの例：
PLAINTEXT://myhost:9092,TRACE://:9091PLAINTEXT://0.0.0.0:9092, TRACE://localhost:9093
advertised.listeners-上記のリスナーと異なる場合、クライアントが使用するためにZooKeeperに公開するリスナー。 IaaS環境では、これはブローカーがバインドするインターフェースと異なる必要がある場合があります。これが設定されていない場合、listenersの値が使用されます。