Kafka最適な保持および削除ポリシー
私はkafkaにかなり新しいので、この質問が些細なことなら許してください。次のように、タイミングテストの目的で非常に単純な設定をしています。
マシンA->トピック1に書き込み（ブローカー）->マシンBがトピック1から読み取りますマシンB->読み取ったばかりのメッセージをトピック2（ブローカー）に書き込みます->マシンAがトピック2から読み取ります
今、私は私の小さなブローカーのスペースを非常に素早く埋める無限ループで約1400バイトのメッセージを送信しています。 log.retention.ms、log.retention.bytes、log.segment.bytes、log.segment.delete.delay.msに異なる値を設定して実験しています。最初にすべての値を許容される最小値に設定しましたが、これはパフォーマンスの低下のように思われ、次にブローカーが完全に一杯になる前に取得できる最大値に設定しましたが、削除が発生するとパフォーマンスが低下します。これらの値を設定して絶対最小遅延を取得するためのベストプラクティスはありますか？
助けてくれてありがとう！
Apache Kafkaは、ログデータ構造を使用してメッセージを管理します。ログデータ構造は基本的にセグメントの順序付けされたセットですが、セグメントはメッセージのコレクションです。ApacheKafka=メッセージレベルではなくセグメントレベルで保持を提供します。したがって、Kafkaは、これらの保持ポリシーに違反しているため、最後からセグメントを削除し続けます。
Apache Kafkaは、次の保持ポリシーを提供します-
- 時間ベースの保持
このポリシーでは、セグメント（したがってメッセージ）が存続できる最大時間を設定します。セグメントが構成された保持期間にまたがると、構成されたクリーンアップポリシーに応じて、削除または圧縮の対象としてマークされます。セグメントのデフォルトの保持期間は7日です。
Kafkaブローカープロパティファイルで設定できるパラメーター（優先度の高い順））を次に示します。
保持時間をミリ秒単位で構成します
log.retention.ms = 1680000
Log.retention.msが設定されていない場合に使用されます
log.retention.minutes = 1680
Log.retention.minutesが設定されていない場合に使用されます
log.retention.hours = 168
- サイズベースの保持
このポリシーでは、トピックパーティションのログデータ構造の最大サイズを構成します。ログサイズがこのサイズに達すると、最後からセグメントの削除を開始します。このポリシーは、メッセージの有効期限に関する十分な可視性を提供しないため、一般的ではありません。ただし、ディスク容量が限られているためにログのサイズを制御する必要があるシナリオでは便利です。
Kafkaブローカープロパティファイルで設定できるパラメーターは次のとおりです。
ログの最大サイズを設定します
log.retention.bytes = 104857600
したがって、ユースケースに応じて、ディスクがいっぱいにならないようにlog.retention.bytesを構成する必要があります。