| 財産 | デフォルト | 形容 |
| broker.id | | 各ブローカーは一意の非負整数IDで識別できます。 このIDはブローカーの「名前」として使われることができ、その存在によりブローカーは消費者を混乱させることなく別のホストやポートに移行できます。 IDは一意であれば、好きな番号をIDとして選んで構いません。 |
| log.dirs | /tmp/kafka-logs | カフカがデータを保存する道筋。 この経路は一意ではなく、複数存在し、経路はコンマで区切るだけで十分です。 新しいパーティションが作成されるたびに、パーティションの数が最も少ないパスで作成されます。 |
| 港湾 | 6667 | サーバーはクライアントが接続するポートを受け入れます |
| Zookeeper.connect(動物園の連通) | ヌル | ZooKeeperの接続文字列の形式はhostname:portで、ホスト名とポートはそれぞれZooKeeperクラスタ内のノードのホストとポートを表します。 ホストがダウンした際に他のZooKeeperノードに接続するには、以下のように複数のホストを作成できます:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeperでは、クラスタ内のすべてのkafkaデータを特定のパスで保存するための「chroot」パスを追加できます。 複数のKafkaクラスタや他のアプリケーションが同じZooKeeperクラスタを使用している場合、この方法でデータストレージパスを設定できます。 これは接続文字列を次のようにフォーマットすることで実装できます:
hostname1:port1, hostname2: port2, hostname3: port3/chroot/path
このセットアップでは、すべてのkafkaクラスタデータを/chroot/pathパスの下に格納します。 ブローカーを開始する前にこの経路を作成し、消費者も同じ接続形式を使用していなければなりません。 |
| message.max.バイト | 1000000 | サーバーが受信できる最大メッセージの容量。 この特性に関する消費者と生産者の設定は同期されなければならず、そうでなければ生産者が発信するメッセージが消費者にとって大きすぎます。 |
| num.network.threads | 3 | サーバーがネットワークリクエストを処理するために使用するネットワークスレッドの数; 一般的にこの性質を変更する必要はありません。 |
| num.io.threads | 8 | サーバーがリクエストを処理するために使用するI/Oスレッドの数; スレッド数はハードディスク数と同等であるべきです。 |
| 背景.スレッド | 4 | ファイル削除などのバックグラウンド処理に使用されるスレッド数; この物件を変更する必要はありません。 |
| queued.max.requests | 500 | ネットワークスレッドが新しいリクエストの読み取りを停止する前に処理できる最大リクエスト数。 |
| host.name | ヌル | ブローカーのホストネームは以下の通りです。 ホスト名がすでに設定されている場合、ブローカーはこのアドレスにのみ割り当てられます。 設定がなければ、すべてのインターフェースにバインドし、ZKに1コピーを公開します |
| advertised.host.name | ヌル | 設定されると、ブローカーのホスト名として生産者、消費者、その他のブローカーに送信されます |
| advertized.port | ヌル | このポートは生産者、消費者、その他のブローカーに提供され、接続確立に使用されます。 実際のポートとサーバーがバインドするポートが異なる場合にのみ設定すればいいのです。 |
| ソケット.センド.バッファ.バイト | 100 * 1024 | SO_SNDBUFF サーバーがソケット接続を行うために使うキャッシュサイズ |
| socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFFキャッシュサイズで、サーバーがソケットに接続するために使います |
| socket.request.max.バイト | 100 * 1024 * 1024 | サーバーが許可する最大リクエストサイズ; これにより、サーバーオーバーフローを回避でき、オーバーフローはJavaヒープサイズよりも小さいはずです |
| num.partitions | 1 | トピック作成時にパーティション数が示されていない場合、この数がトピック下のデフォルトのパーティション数となります。 |
| log.segment.bytes | 1014*1024*1024 | トピックパーティションのログは特定のディレクトリ内の多くのファイルに保存されており、パーティションのログはセグメントに分割されます。 この属性は各ファイルの最大サイズです。 寸法がこの値に達すると、新しいファイルが作成されます。 この設定は各トピックの基礎によって上書き可能です。
眺め ハイパーリンクのログインが見えます。 |
| ログロール時間 | 24 * 7 | ファイルがlog.segment.bytesに到達しなくても、ファイル作成時間がこのプロパティに達するたびに新しいファイルが作成されます。 この設定はトピックレベルの設定によっても上書き可能です。
眺めるハイパーリンクのログインが見えます。 |
| log.cleanup.policy(log.cleanup.policy) | 削除 | |
| log.retention.minutes および log.retention.hours | 7日間 | 各ログファイルが削除されるまでに保存された時間。 すべてのトピックでデフォルトのデータ節約時間は同じです。
log.retention.minutes と log.retention.bytes は、どのプロパティがオーバーフローされていてもログファイルの削除設定に使用されます。
このプロパティ設定は、トピックが基本的に設定されたときに上書きできます。
眺めるハイパーリンクのログインが見えます。 |
| log.retention.bytes | -1 | 各トピックの各パーティションで保存されたデータの総量; これはパーティションごとの上限であり、この数にパーティション数を掛けると、トピックごとに保存されたデータ量の合計になります。 また注意:log.retention.hoursとlog.retention.bytesの両方が設定されている場合、どちらかの制限を超えるとセグメントファイルが削除されます。
この設定は各トピックで上書き可能であることにご注意ください。
眺めるハイパーリンクのログインが見えます。 |
| log.retention.check.interval.ms | 5分 | ログ分割ファイル間の間隔を確認し、ファイル属性が削除要件を満たしているか確認してください。 |
| log.cleaner.enable | false | このプロパティがfalseに設定されている場合、ログが最大保存時間またはサイズで完了すると削除されます。 trueに設定すると、セーブ属性の上限に達したときに発生しますハイパーリンクのログインが見えます。。 |
| log.cleaner.threads | 1 | ログ圧縮を実行するスレッドの数 |
| log.cleaner.io.max.bytes.per.second | 何一つ | ログクリーナーがログ圧縮を行う際に持てる最大I/Oの数。 この設定により、清掃員はアクティブなリクエストサービスの妨げを避けられます。 |
| log.cleaner.io.buffer.size | 500*1024*1024 | ログクリーナーはクリーンアップの過程でログをインデックスし、使用されるキャッシュのサイズを削減します。 十分なメモリを確保するために、大容量に設定するのが最善です。 |
| log.cleaner.io.buffer.load.factor | 512*1024 | ログクリーニングに必要なI/Oチャンクの大きさ。 この設定を変更する必要はありません。 |
| log.cleaner.io.buffer.load.factor | 0.9 | ログクリーニングに使用されるハッシュテーブルの負荷係数; このオプションを変更する必要はありません。 |
| log.cleaner.backoff.ms | 15000 | ログが清掃される時間間隔が行われます |
| log.cleaner.min.cleanable.ratio | 0.5 | この構成は、ログ圧縮機がログを片付ける頻度を制御します(仮定)ハイパーリンクのログインが見えます。は開いている)。 デフォルトでは、ログの50%以上を清掃しないでください。 この比率はバックアップログが消費する最大容量(ログの50%が50%で圧縮)に連動しています。 高い料金は廃棄物が減り、より多くのスペースを効率的に片付けることができます。 この設定は各トピック設定で上書き可能です。
眺めるハイパーリンクのログインが見えます。。 |
| log.cleaner.delete.retention.ms | 1日 | 保管時間; 圧縮ログを保持する最大時間; また、クライアントがメッセージを消費する最大時間でもあり、log.retention.minutesの違いは、一方が非圧縮データを制御し、もう一方が圧縮データを制御し、トピック作成時に指定された時間に上書きされるという点です。 |
| log.index.size.max.バイト | 10*1024*1024 | ログセグメントあたりの最大サイズ。 ログサイズがこの値に達すると、log.segment.bytesの制限を超えなくても新しいログセグメントを生成する必要があります。 |
| log.index.interval.bytes | 4096 | フェッチを行う際は、一定のスペースを確保した最も近いオフセットをスキャンする必要があります。設定が大きいほど良いです。一般的にはデフォルトの値を使います |
| log.flush.interval.messages | ロング・マックスバリュー | メッセージを蓄積する前にファイル「同期」をディスクに記録してください。 ディスクのIO操作は遅い作業ですが、「データ信頼性」のために必要な手段であるため、硬化までの時間間隔が必要かどうかを確認してください。 この値が大きすぎると「同期」時間が長くなり(IOブロッキング)、小さすぎると「fsync」(IOブロッキング)が長くなります。この値が小さいと多くの「同期」回数が発生し、クライアント全体のリクエストに一定の遅延が生じ、物理サーバーの障害によりfsyncなしのメッセージが失われます。 |
| log.flush.scheduler.interval.ms | ロング・マックスバリュー | fsync間隔が必要かどうか確認してください |
| log.flush.interval.ms | ロング・マックスバリュー | この数値は「fsync」の時間間隔を制御するために使われます。メッセージ数がディスクに固定されたメッセージ数に達していなくても、最後のディスク同期からの時間間隔が閾値に達した場合、ディスク同期もトリガーされます。 |
| log.delete.delay.ms | 60000 | インデックスでファイルがクリアされた後の保持時間は、一般的に変更する必要はありません |
| auto.create.topics.enable | true | トピックの自動作成を許可するかどうか。 もし本当なら、produce or fetchが存在しないと自動的に存在しないトピックが作成されます。 そうでなければ、コマンドラインを使ってトピックを作成する必要があります |
| controller.socket.timeout.ms | 30000 | パーティション管理コントローラがバックアップを実行する際のソケットのタイムアウト時間。 |
| controller.message.queue.size | Int.MaxValue | コントローラーからブローカーへ |
| default.replication.factor | 1 | バックアップコピーのデフォルト数は自動生成トピックのみを指します |
| replica.lag.time.max.ms | 10000 | もしフォロワーがこの時間内にフェッチリクエストを送信しなければ、リーダーはそのフォロワーをISRから再削除し、フォロワーをハングしたものとみなします |
| replica.lag.max.メッセージ | 4000 | レプリカにこの数を超えるバックアップ未バックアップがある場合、リーダーはフォロワーを外し、フォロワーを吊るすとみなします |
| replica.socket.timeout.ms | 30*1000 | バックアップ時のソケットネットワーク要求のリーダータイムアウト時間 |
| replica.socket.receive.buffer.bytes | 64*1024 | バックアップ中にリーダーにネットワークリクエストを送信する際のソケット受信バッファ |
| replica.fetch.max.バイト | 1024*1024 | バックアップ時の各フェッチの最大値 |
| replica.fetch.min.bytes | 500 | リーダーがバックアップ要求を行った際のデータがリーダーに到達する最大待ち時間 |
| replica.fetch.min.bytes | 1 | バックアップ時の各フェッチ後の応答の最小サイズ |
| num.replica.fetchers | 1 | リーダーからのデータをバックアップするスレッドの数 |
| replica.high.watermark.checkpoint.interval.ms | 5000 | 各レプリカは、最高水位がどのくらいの頻度で硬化するかを確認します |
| fetch.purgatory.purge.interval.requests | 1000 | fetch リクエスト パージ間隔 |
| producer.purgatory.purge.interval.requests | 1000 | プロデューサーがパージ間隔を要求 |
| zookeeper.session.timeout.ms | 6000 | Zookeeperセッションのタイムアウト。 |
| zookeeper.connection.timeout.ms | 6000 | クライアントがzookeeperと接続を確立するまで待つ最大時間 |
| zookeeper.sync.time.ms | 2000 | ZKフォロワーは長い間ZKリーダーに遅れをとっています |
| controlled.shutdown.enable | true | ブローカーの閉鎖を制御できるかどうか。 可能であれば、ブローカーはクロージング前にすべてのリーダーを他のブローカーに移すことができます。 これにより、シャットダウン中の利用不能が減ります。 |
| controlled.shutdown.max.retries | 3 | 未完成のシャットダウンを実行する前にシャットダウンを成功裏に実行できるコマンドの数。 |
| controlled.shutdown.retry.backoff.ms | 5000 | シャットダウン間のバックオフ時間 |
| auto.leader.rebalance.enable | true | もしこれが当てはまるなら、コントローラーは自動的にパーティションに関するブローカーのリーダーシップをバランスさせます |
| leader.imbalance.per.broker.percent | 10 | 各ブローカーが許容する最大不均衡比率 |
| リーダー。不均衡。チェック。間隔。秒 | 300 | リーダーの不均衡の頻度を確認してください |
| offset.metadata.max.バイト | 4096 | クライアントがオフセットの最大数を節約できるようにします |
| max.connections.per.ip | Int.MaxValue | 各IPアドレスに対して、ブローカーごとに最大接続数を設定できます |
| max.connections.per.ip.overrides | | IPまたはホスト名ごとのデフォルト接続の最大カバレッジ |
| connections.max.idle.ms | 600000 | 空の接続に対するタイムアウト制限 |
| ログロール。ジッター。 {ms,hours} | 0 | logRollTimeMillisから抽象化された最大ジッター数 |
| num.recovery.threads.per.data.dir | 1 | 各データディレクトリが回復をログするために使用するスレッド数 |
| unclean.leader.election.enable | true | ISRの非レプリカ設定をリーダーとして使用できるかどうかを示します |
| delete.topic.enable | false | トピックを削除できる |
| offsets.topic.num.partitions | 50 | オフセットコミットトピックのパーティション数。 現在はデプロイ後にこの設定を変更することがサポートされていないため、本番環境ではより高い設定(例:100-200)を使うことを推奨します。 |
| offsets.topic.retention.minutes | 1440 | この期間を超えて存在したオフセットは削除保留としてマークされます |
| offsets.retention.check.interval.ms | 600000 | オフセットマネージャーは、古いオフセットの頻度を確認します |
| offsets.topic.replication.factor | 3 | トピックのオフセットのバックアップコピー数。 より高い利用可能性を保証するために、より高い数値を設定することが推奨されます |
| offset.topic.segment.bytes | 104857600 | 相殺の話題。 |
| offsets.load.buffer.size | 5242880 | この設定はバッチサイズに関連しており、オフセットセグメントから読み取る際に使われます。 |
| offsets.commit.required.acks | -1 | オフセットコミットが許容される前に確認回数を設定する必要があり、通常は変更する必要もありません |
| 財産 | デフォルト | 形容 |
| group.id | | コンシューマープロセスが存在するグループを一意に識別する文字列で、同じグループIDが設定されている場合、これらのプロセスは同じコンシューマーグループに属していることを示します |
| Zookeeper.connect(動物園の連通) | | Zookeeper接続の文字列を指定します。フォーマットはhostname:portです。ここではホストとポートがZookeeperサーバーのホストとポートの両方を表します。Zookeeperマシンがダウンした後に連絡が途絶えないように、複数のhostname:portを指定することも可能です。区切りはカンマで示します:
ホスト名1:ポート1、ホスト名2:ポート2、ホスト名3:ポート3
ZooKeeperのchrootパスを、ZooKeeperの接続文字列に追加できます。この接続文字列は独自のデータを保存するために使われます。
hostname1:port1, hostname2: port2, hostname3: port3/chroot/path |
| consumer.id | ヌル | 設定は不要で、一般的に自動的に生成されます |
| socket.timeout.ms | 30*100 | ネットワークリクエストのタイムアウト制限。 真のタイムアウト制限はmax.fetch.wait+socket.timeout.msです |
| socket.receive.buffer.bytes | 64*1024 | ソケットはネットワークリクエストのキャッシュサイズを受信するために使われます |
| fetch.message.max.バイト | 1024*1024 | フェッチリクエストごとのフェッチメッセージあたりの最大バイト数。 これらのバイトは各パーティションで使用されるメモリ上で監視されるため、この設定で消費者が使用するメモリ量を制御します。 フェッチリクエストのサイズは、サーバーが許容する最大メッセージサイズに等しくなければならず、そうでなければプロデューサーが送信できるメッセージのサイズが消費者が消費できるサイズを上回ってしまいます。 |
| num.consumer.fetchers | 1 | フェッチデータに使用されるフェッチャースレッドの数 |
| auto.commit.enable | true | もしそれが正当なら、消費者が取得したメッセージのオフセットは自動的にZookeeperに同期されます。 このコミットオフセットは、プロセスが停止した際に新しいコンシューマーによって使用されます |
| auto.commit.interval.ms | 60*1000 | 消費者がズーキーパーにオフセットを送信する頻度は秒単位です |
| queued.max.メッセージ.チャンクス | 2 | キャッシュ用に使われる最大メッセージ数。 各チャンクはfetch.message.max.bytesと同じでなければなりません |
| rebalance.max.retries | 4 | 新しいコンシューマーがコンシューマーグループに追加されると、コンシューマーのコレクションは各コンシューマーに割り当てられたパーティションの数を再バランスしようとします。 消費者のコレクションが変化すると、このリバランスは失敗し、割り当てが実行される際に再調整されます |
| fetch.min.bytes | 1 | サーバーが各フェッチリクエストで返すべき最小バイト数。 十分なデータが返ってこなければ、十分なデータが得られるまでリクエストは待ちます。 |
| fetch.wait.max.ms | 100 | fetch.min.bytesを満たすのに十分なデータがない場合、この構成はサーバーがfetchリクエストに応答するまでの最大ブロック時間を指します。 |
| rebalance.backoff.ms | 2000 | Reblanceを再挑戦する前に、距離を置く時間です |
| refresh.leader.backoff.ms | 200 | 分割の指導者が指導者を失ったかどうかを判断する前に、後退の時間がある |
| auto.offset.reset | 最大 | Zookeeperに初期化されたオフセットがない場合、オフセットが次の値への応答である場合:
最小:自動リセットオフセットを最小オフセットに
最大:自動リセットオフセットを最大オフセットに
その他の場合:消費者に例外を適用します |
| consumer.timeout.ms | -1 | メッセージが表示されない場合、特定の時間待ってもタイムアウト例外が出されます |
| exclude.internal.topics | true | 内部の話題からのメッセージを消費者に露出させるかどうか |
| Parition.assignment.strategy | 分布 | 消費者フローにパーティションを割り当てるポリシーを選択し、オプションで範囲、ラウンドロビンを選択してください |
| client.id | グループIDの値 | は各リクエスト内の通話を追跡するユーザー固有の文字列です。 リクエストを生成したアプリケーションが論理的に確認されるはずです |
| zookeeper.session.timeout.ms | 6000 | 飼育員セッションのタイムアウト制限。 この期間中に消費者が心拍メッセージを動物飼育員に送らなければ、切断されたとみなされ、リブランスが生成されます |
| zookeeper.connection.timeout.ms | 6000 | クライアントがZookeeper接続を確立するための最大待ち時間 |
| zookeeper.sync.time.ms | 2000 | ZKフォロワーは最大時間ZKリーダーの後ろに遅れることがあります |
| offsets.storage | 動物園飼育員 | オフセットを保管していた場所:ズーキーパーやカフカ |
| offset.channel.backoff.ms | 1000 | オフセットチャネルへの再接続や失敗したオフセットのフェッチ/コミット要求の再試行のバックオフ時間 |
| offsets.channel.socket.timeout.ms | 10000 | オフセットを読み取る際のフェッチ/コミット要求応答に対するソケットタイムアウトの制限。 このタイムアウト制限は、consumerMetadataリクエストによってオフセット管理を要求するために使われます |
| offsets.commit.max.retries | 5 | オフセットコミットが再試行された回数。 このリトライはシャットダウン間のオフセットコミットにのみ適用されます。 彼 |
| dual.commit.enabled | true | offsets.storageとして「kafka」を使うと、Zookeeperにオフセットを2回(kafkaに1回)コミットできます。 これはZookeeperベースのオフセットストレージからkafkaベースのオフセットストレージに移行する際に必須です。 どの消費者グループにとっても、移行が完了したらこのオプションをオフにするのが安全な推奨です |
| partition.assignment.strategy | 分布 | 消費者データフローにパーティションを割り当てるポリシーとして「レンジ」ポリシーと「ラウンドロビン」ポリシーのどちらかを選択してください。 循環パーティションアロケーターは、利用可能なすべてのパーティションとすべての利用可能なコンシューマースレッドを割り当てます。 パーティションループをコンシューマースレッドに割り当てます。 すべての消費者インスタンスが決定されたものにサブスクライブされている場合、分割は決定論的分布に分割されます。 ラウンドロビン割り当て戦略は、以下の条件が満たされている場合にのみ可能です:(1) 各トピックが消費者強度あたりのデータフロー数が同じであること。 (2) 購読されたトピックの集合は、消費者グループの各消費者インスタンスごとに決定されます。 |
| 財産 | デフォルト | 形容 |
| metadata.broker.list | | ブートストラップを提供。 Producerはメタデータ(トピック、パーティション、レプリカ)を取得するためのみ使用されます。 実際のデータを送信するためのソケット接続は、返送されたメタデータデータに基づいて確立されます。 フォーマットは以下の通りです:
ホスト1:ポート1、ホスト2:ポート2
このリストはブローカーのサブリストであったり、ブローカーを指すVIPであったりします |
| request.required.acks | 0 | この構成は、プロデュースリクエストが完了したとみなされる確認応答値です。 特に、他のどれだけ多くのブローカーがログにデータを提出し、その情報をリーダーに確認しているのか。 典型的な値は以下の通りです:
0:生産者がブローカーからの確認を一切待たないことを示します(0.7と同じ動作)。 この方法は遅延が最小限ですが、同時に最大のリスク(サーバーがダウンするとデータが失われるため)も最大です。
1: リーダーレプリカがデータ確認を受け取ったことを示します。 このオプションはレイテンシが低く、サーバーが受信を確認しることを保証します。
-1: プロデューサーはすべての同期レプリカがデータを受け取ったことを確認する。 遅延が最も大きいですが、この方法は同期されたレプリカの数が1つになるため、メッセージの損失リスクを完全に排除するわけではありません。一部のレプリカがデータを受け取ることを確実にしたい場合は、トピックレベルの設定で min.insync.replicas オプションを設定してください。 より詳しい議論は設計ドキュメントを読んでください。 |
| request.timeout.ms | 10000 | ブローカーはrequest.required.acksの要件を実装しようと最善を尽くします。そうでなければクライアントにエラーが送信されます |
| producer.type | 同期 | このオプションは、メッセージが非同期でバックグラウンドスレッドで送信されているかどうかをピン留めします。 正しい値:
(1) 非同期:非同期送信
(2) 同期:同期送信
プロデューサーを非同期に設定することで、リクエストをバッチ単位で処理できます(これはスループットの向上に有利です)が、クライアントマシンが未送信データを失う可能性も生じます |
| serializer.class | kafka.serializer.DefaultEncoder | メッセージのシリアライズカテゴリ。 デフォルトのエンコーダは1バイト[]を入力し、同じバイト[]を返します[] |
| key.serializer.class | | キーワードのシリアライズクラス。 もしこれが与えられていない場合、デフォルトではメッセージに合わせることになります |
| partitioner.class | kafka.producer.DefaultPartitioner | メッセージをサブトピック間で分割するためのパーティショナークラス。 デフォルトのパーティショナーはキーのハッシュテーブルに基づいています |
| 圧縮.codec | 何一つ | このパラメータはデータ圧縮のためのコーデックを設定でき、「なし」、「gzip」、「snappy」と選択できます。 |
| compressed.topics | ヌル | このパラメータは、特定のトピックが圧縮されているかどうかを設定するために使用できます。 圧縮されたコーデックがNoCompressCodec以外のコーデックであれば、これらのコーデックは指定されたトピックデータに適用されます。 圧縮トピックのリストが空の場合は、すべてのトピックに特定の圧縮コーデックを適用します。 圧縮コーデックがNoCompressionCodecの場合、すべてのトピックで圧縮が利用可能ではありません。 |
| message.send.max.retries | 3 | このパラメータにより、プロデューサーは失敗した送信リクエストを自動的に再試行します。 このパラメータは再試行回数を固定します。 注:0でない値を設定すると、送信が起きたり確認応答が失われたりする特定のネットワークエラーが繰り返されます |
| retry.backoff.ms | 100 | 各リトライの前に、プロデューサーは関連するトピックのメタデータを更新し、新しいリーダーが割り当てられているかを確認します。 リーダー選択に少し時間がかかるため、このオプションはプロデューサーがメタデータを更新するまでにどれくらい待つ必要があるかを指定します。 |
| topic.metadata.refresh.interval.ms | 600*1000 | プロデューサーは、パーティションの欠如、リーダーが利用できない場合など、いくつかの失敗シナリオでトピックのメタデータを更新することが多いです。 彼は規則的な周期を経るでしょう。 負の値に設定すると、メタデータは失敗した場合にのみ更新されます。 0に設定されている場合、各メッセージ送信後にメタデータが更新されます(この方法は推奨されません。システムが消費しすぎます)。 重要:更新はメッセージ送信後にのみ行われるため、プロデューサーがメッセージを送信しなければメタデータは更新されません。 |
| queue.buffering.max.ms | 5000 | 非同期モードが適用された際、ユーザーがデータをキャッシュする最大時間間隔。 例えば、メッセージが100に設定されている場合、100ms以内のメッセージはバッチ処理されます。 これによりスループットは向上しますが、キャッシュによる遅延が増加します。 |
| queue.buffering.max.メッセージ | 10000 | 非同期モードを使用する場合、プロデューサーがキューにキャッシュできる最大数の未送信メッセージをブロックするか、データを失わなければなりません |
| batch.num.messages | 200 | 非同期モードを使うと、最大数のメッセージを一括処理できます。 あるいは、オンラインに到達したメッセージの数や queue.buffer.max.ms が届き、プロデューサーが処理します |
| send.buffer.bytes | 100*1024 | ソケット書き込みキャッシュサイズ |
| client.id | “” | このクライアントIDはユーザー固有の文字列で、各リクエストに含まれて通話を追跡し、論理的にアプリケーションがリクエストを行ったことを確認できるはずです。 |
| 名前 | 種類 | デフォルト | 重要性 | 形容 |
| boostrap.servers | 一覧 | | 高く | ホスト/ポートグループはKafkaクラスターへの接続を確立します。 どのサーバーがブートストラップに割り当てられていても、データはすべてのサーバーで均等に読み込まれます。 このリストは初期化されたホストにのみ影響します(すべてのサーバーを検出するために使われます)。 このリスト形式は以下の通りです:
host1:port1,host2:port2,...
これらのサーバーは接続の初期化に限られ、クラスタのすべてのメンバーシップを発見するため(メンバーシップは動的に変化することがあるため)、このリストはすべてのサーバーを含める必要はありません(複数のサーバーを用意したい場合もありますが、この場合は1台のサーバーがダウンしている場合もあります)。 このリストにサーバーが表示されない場合、リストが利用可能になるまで送信は失敗します。 |
| アクス | ストリング | 1 | 高く | プロデューサーは、データ受信後にサーバーからの受信確認信号を必要とし、この構成はプロダダーが必要とする確認応答信号の数を指します。 この構成は実際にはデータバックアップの利用可能性を表しています。 以下の設定が一般的な選択肢です:
(1) acks=0:0に設定すると、プロデューサーは受信した情報の確認を待つ必要がなくなります。 レプリカは即座にソケットバッファに追加され、送信されたとみなされます。 この場合、サーバーがデータを完全に受信した保証はなく、設定の再試行は失敗したかどうか分からないためうまくいかず、フィードバックのオフセットは常に-1に設定されます。
(2) acks=1:これはリーダーがローカルログにデータを書き込むのを少なくとも待つが、すべてのフォロワーが成功するまで待つ必要はないことを意味します。 この場合、フォロワーがデータのバックアップに成功せず、リーダーが再び電話を切ると、メッセージは失われます。
(3) acks=all:これはリーダーがすべてのバックアップがログを正常に書き込むのを待つ必要があり、この戦略により1つのバックアップが生き残っている限りデータが失われないことを保証します。 これが最も強力な保証です。
(4) acks=2などの他の設定も可能で、これらは一定数のackを必要としますが、この戦略は一般的にほとんど使われません。 |
| buffer.memory | 長い | 33554432 | 高く | プロデューサーはデータのメモリサイズをキャッシュするために使用できます。 もしデータがブローカーに送られるより速く生成された場合、プロデューサーは「block.on.buffer.full」で示される例外をブロックまたはスローします。
この設定はプロデューサーが使用できる総メモリに関連していますが、プロデューサーが使用するすべてのメモリがキャッシュに使われるわけではないため、厳密な制限ではありません。 圧縮が導入された場合は圧縮に一部の追加メモリが使用され、保守要求には一部が使われます。 |
| 圧縮型 | ストリング | 何一つ | 高く | プロデューサーはデータを圧縮するために使われる圧縮の一種です。 デフォルトは非圧縮です。 正しいオプション値は「なし」「gzip」「snappy」です。
圧縮はバッチ処理に最適であり、バッチ処理されるメッセージが多いほど圧縮性能が向上します。 |
| 再挑戦 | 知力 | 0 | 高く | 値が0より大きいと、そのデータが失敗するとクライアントは再送信します。 これらのリトライは、クライアントが送信エラーを受けた場合と何ら変わりません。 リトライでデータの順序を変更できる可能性があります。両方のメッセージレコードが同じパーティションに送信され、最初のメッセージが失敗し、2番目のメッセージが最初のメッセージより先に現れた場合です。 |
| batch.size | 知力 | 16384 | 中程度 | プロデューサーはリクエスト数を減らすためにメッセージレコードをバッチ処理しようとします。 これによりクライアントとサーバー間の性能が向上します。 この構成はバッチ処理メッセージのデフォルトバイト数を制御します。
このバイト数を超えるメッセージバイトの処理は試みられません。
ブローカーに送られるリクエストは複数のバッチで構成され、各パーティションごとに1つのリクエストが入ります。
小さいバッチ値ほど使用頻度が低く、スループットが低下することがあります(0はバッチ処理のみを使用します)。 大きなバッチはメモリ容量を無駄にするため、特定のバッチ値にメモリを割り当てる必要があります。 |
| client.id | ストリング | | 中程度 | この文字列はリクエストが行われる際にサーバーに送信されます。 目的は、IPやポートの許可リスト外のアプリケーションが情報を送信できるように、リクエストの出所を追跡できるようにすることです。 このアプリは録音やトラッキング以外の機能的な目的がないため、どんなストリングでも設定できます |
| linger.ms | 長い | 0 | 中程度 | プロデューサーグループは、リクエストと送信の間に届いたメッセージを集約し、別のリクエストバッチを記録します。 通常、これはレコードが送信速度より速く生成された場合にのみ発生します。 しかし、特定の条件下では、クライアントはリクエスト数を減らしたり、適度な負荷にしたいと思うでしょう。 このセットアップは小さな遅延を加えることで行われます。つまり、レコードをすぐに送信するのではなく、プロデューサーが一定の遅延時間で待って他のメッセージレコードを送信し、それらをバッチ処理できるようにします。 これはTCP Nagleに似たアルゴリズムと考えられます。 この設定はバッチ処理の遅延境界を高く設定します。パーティションのbatch.sizeを取得すれば、この設定に関係なくすぐに送信されますが、この設定よりはるかに少ないバイト数のメッセージが届く場合は、より多くのメッセージを得るために特定の時間を「留めておく」必要があります。 この設定はデフォルトで0、つまり遅延なしとなります。 例えばlinger.ms=5を設定するとリクエスト数は減りますが、同時に遅延が5ms増加します。 |
| 最大リクエストサイズ | 知力 | 1028576 | 中程度 | 要求された最大バイト数。 これは最大記録サイズのカバーにも効果的です。 注意:サーバーはメッセージレコードサイズのオーバーライドを持ち、この設定とは異なります。 この設定により、生産者が一度に大量に送信できるリクエスト数が制限され、大量のリクエストが出るのを防ぎます。 |
| receive.buffer.bytes | 知力 | 32768 | 中程度 | データを読み込む際に使われるTCP受信キャッシュサイズ |
| send.buffer.bytes | 知力 | 131072 | 中程度 | TCP 送信キャッシュサイズは、データ送信時に使用されます |
| timeout.ms | 知力 | 30000 | 中程度 | この設定オプションは、フォロワーからの確認を待つサーバーの最大待ち時間を制御します。 この期間内に確認されたリクエスト数が満たされない場合、エラーが返されます。 このタイムアウト制限はサーバー側で測定され、リクエストを含むネットワーク遅延はありません |
| block.on.buffer.full | ブール値 | true | ロー | メモリキャッシュが尽きると、新しいメッセージレコードの受信を停止するかエラーを投げなければなりません。 デフォルトではtrueに設定されていますが、一部のブロッキングが予想に値しない場合もあるため、すぐにエラーを出す方が良いです。 これは、レコードが送信されてキャッシュが満杯の場合、プロデューサーが例外エラー(BufferExhaustedException)を投げます |
| metadata.fetch.timeout.ms | 長い | 60000 | ロー | これは、私たちが取得した一部の要素の初めてのデータを指します。 要素にはトピック、ホスト、パーティションが含まれます。 この構成は、フェッチによって要素が成功するまでの時間を指します。そうでなければクライアントに例外が送信されます。 |
| metadata.max.age.ms | 長い | 300000 | ロー | マイクロ秒単位の時間は、メタデータを強制的に更新する間隔です。 たとえ分割指導部の変化が見られなくても。 |
| metric.reporters | 一覧 | [] | ロー | 指標を測定するために使われるクラスの一覧。 MetricReporterインターフェースを実装することで、新しい指標が生成されるたびにクラスが変更されるようになります。 JmxReporterは常にJMX統計を登録する方法を含みます |
| metrics.num.samples | 知力 | 2 | ロー | 指標を維持するために使用されるサンプル数 |
| metrics.sample.window.ms | 長い | 30000 | ロー | メトリクスシステムは、修正可能なウィンドウサイズ内で設定可能なサンプル数を維持します。 この構成では例えばウィンドウサイズの設定が行われます。 30秒間、2つのサンプルを保持することがあります。 ウィンドウをロールアウトすると、最も古いウィンドウを消去して書き換えます |
| recoonect.backoff.ms | 長い | 10 | ロー | 接続が失敗すると、再接続時の待ち時間がかかります。 これにより、クライアントの再接続を繰り返し回避できます |
| retry.backoff.ms | 長い | 100 | ロー | 失敗した生果物リクエストを再試すまでの待ち時間。 送信・失敗のデッドループに陥らないようにしましょう。
|
掲載地 2021/06/24 11:47:12
|
|
|
地主