[Kafka] kafkaスクリプトkafka-configs.shの使用分析

1。概要

引用されているブログはLi Zhitaoによるものです：https ://www.cnblogs.com/lizherui/p/12275193.html

2.はじめに

インターネット上でのスクリプトkafka-configs.shの使用に関するさまざまな記事もありますが、それらは体系的で不完全ではありません。導入の内容が欠落しているため、次のように常に人々は非常に理解しやすく、使いにくいように見えます：内部関係の動的構成明確ではありませんが、コードを調べない限り、マスタースレーブ同期クォータ電流制限のいくつかの主要な構成パラメーターは明確に説明されていません。したがって、読者がこのスクリプトを使用して、この記事を詳しく読むことで、実際の運用、保守、開発で発生する問題をより便利に解決し、すべての人の学習時間を節約できることを願っています。

3.スクリプト構文分析

Kafka-configs.shパラメーター分析

4.文法フォーマット

4.1構成アイテムを追加する

トピック構成オブジェクト

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type topics --entity-name topicName  --add-config 'k1=v1, k2=v2, k3=v3' 

すべてのclientIdsの構成オブジェクト

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type clients --entity-default --add-config 'k1=v1, k2=v2, k3=v3' 

例

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type topics --entity-name topicName  --add-config 'max.message.bytes=50000000, flush.messages=50000, flush.ms=5000'

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type topics --entity-name topicName  --add-config 'max.message.bytes=50000000' --add-config 'flush.messages=50000'

4.2構成アイテムを削除する

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type topics --entity-name topicName --delete-config ‘k1,k2,k3’

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type clients --entity-name clientId --delete-config ‘k1,k2,k3’

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-name $brokerId --delete-config ‘k1,k2,k3’

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-default --delete-config ‘k1,k2,k3’

例

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type topics --entity-name test-cqy --delete-config 'segment.bytes'

4.3構成アイテムの変更

構成アイテムの変更は構文フォーマットの追加と同じであり、同じパラメーターはバックエンドによって直接カバーされます

エンティティ構成の説明を一覧表示

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --entity-type topics --entity-name topicName --describe

bin/kafka-configs.sh--bootstrap-server localhost:9092 --entity-type brokers --entity-name $brokerId --describe

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --describe

bin/kafka-configs.sh  --zookeeper localhost:2181/kafkacluster --entity-type users --entity-name user1 --entity-type clients --entity-name clientA --describe

その他は順番に類推され、1つずつリストされていません

5.構成管理の使用法

5.1クライアントクォータの現在の制限

Kafkaはクォータ管理をサポートします。これにより、プロデューサーおよびコンシューマーの生産およびフェッチ操作のフローを制限して、個々の企業がサーバーに負荷をかけすぎないようにすることができます。この記事では、主にカフカのクォータ管理機能の使用方法を紹介します

割り当て制限の概要

Kafka割り当ての現在の制限は、3つの粒度で構成されます。

users + clients
users
clients

上記の3つの方法はすべて、アクセスしたクライアントのIDを識別する方法です。その中にclientidは、Kafkaクラスターに接続されている各クライアントのIDマークがあり、ProduceRequestとFetchRequestに含める必要があります。ユーザーは、ID認証が有効になっているKafkaクラスターでのみ使用できます。プロデューサーとコンシューマーのclientidのデフォルト値はそれぞれです

producer-自增序号、groupid

構成の優先度

上記の3つの詳細な構成は、8つの構成オブジェクトに結合されます。同じ構成アイテムのスコープは異なり、高優先度が低優先度をオーバーライドします。以下が構成優先度です。

構成アイテムのリスト

配置用例

1.ユーザー+クライアントを構成する

bin/kafka-configs.sh  --zookeeper localhost:2181/kafkacluster --alter  --entity-type users --entity-name user1 --entity-type clients --entity-name clientA --add-config 'producer_byte_rate=20971520,consumer_byte_rate=20971520' 

bin/kafka-configs.sh  --zookeeper localhost:2181/kafkacluster --alter  --entity-type users --entity-name user1 --entity-type clients --entity-default --add-config 'producer_byte_rate=20971520,consumer_byte_rate=20971520' 

bin/kafka-configs.sh  --zookeeper localhost:2181/kafkacluster --alter  --entity-type users --entity-default --entity-type clients --entity-default --add-config 'producer_byte_rate=20971520,consumer_byte_rate=20971520' 

2.ユーザーを構成する

ブローカー内のすべてのユーザーの累積合計、最大プロデューサーの生産と消費率は20MB /秒です

bin/kafka-configs.sh  --zookeeper localhost:2181/kafkacluster --entity-type users --entity-default --alter --add-config 'producer_byte_rate=20971520,consumer_byte_rate=20971520'

broker内userA的最大producer生产&消费速率为20MB/sec

bin/kafka-configs.sh  --zookeeper localhost:2181/kafkacluster --entity-type users --entity-name userA --alter --add-config 'producer_byte_rate=20971520,consumer_byte_rate=20971520'

3.クライアントを構成する

broker内所有clientId累加总和最大producer生产速率为20MB/sec

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type clients --entity-default  --add-config 'producer_byte_rate=20971520'

broker内clientA的最大producer生产速率为20MB/sec

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type clients  --entity-name clientA  --add-config 'producer_byte_rate=20971520'

現在の制限を超える問題

プロデューサーとコンシューマーがトラフィック制限を超えた場合、Kafkaはどうしますか？

1. プロデューサー向け。プロデューサーが現在の制限を超えている場合は先把数据append到log文件、遅延時間を計算し、ThrottleTimeを待ってからプロデューサーに応答します。Kafkaにはクライアントフィードバックメカニズムがないため、プロデューサーは書き込みタイムアウトを再送信し、書き込みメッセージが繰り返されます。
2. 消費者向け。コンシューマーが現在の制限を超え、先计算延时时间ThrottleTimeを待機した後、Kafkaはログからデータを読み取り、コンシューマーに応答します。コンシューマーのQequestTimeout <ThrottleTimeの場合、コンシューマーは引き続きThrottleTime時間内にフェッチ要求を再送信し、Kafkaは無効な要求を大量に蓄積してリソースを占有します。

5.2ブローカータイプの設定

ブローカーの構成は複雑で、多くの構成アイテムがあります。Kafkaは、次の表に示すように、ブローカーの構成を7つのモジュールに内部的に分割します。

ブローカータイプの構成は、すべての構成アイテムをサポートしているわけではありません。たとえば、ブローカーのアップグレードに関連するプロトコルとグループ、ズーキーパー、組み込みトランザクション、制御、組み込みオフセットは動的に変更できません。ブローカーの設定は-bootstrap-serverのみを指定でき、zkはサポートしていません

5.3構成アイテムを追加する

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-default  --add-config 'max.connections.per.ip=200,max.connections.per.ip.overrides=[ip1:100,ip2:120]' 

bin/kafka-configs.sh --bootstrap-server localhost:9092--alter --entity-type brokers --entity-name  $brokerId --add-config 'max.connections.per.ip=200,max.connections.per.ip.overrides=[ip1:100]' 

5.4構成アイテムを削除する

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-default  --delete-config  'max.connections.per.ip,max.connections.per.ip.overrides' 

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type brokers --entity-name  $brokerId --delete-config  'max.connections.per.ip,max.connections.per.ip.overrides' 

5.5リスト構成の説明

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --describe

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name $brokerId --describe

5.6トピック型の構成

トピックタイプの構成は、ブローカータイプの構成のサブセットです。ブローカータイプには、トピックタイプのすべての構成が含まれます。ブローカーは、トピック構成アイテムにプレフィックスを追加するだけです。ブローカーの動的構成では、パラメーターmessage.format.versionが一時的にサポートされないという特殊なケースの違いもあります。

構成アイテムを追加する

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type topics --entity-name test-cqy --add-config 'max.message.bytes=50000000,flush.messages=50000,flush.ms=5000'

構成アイテムを削除

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type topics --entity-name test-cqy --delete-config 'max.message.bytes,flush.messages,flush.ms'

リスト構成の説明

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --entity-type topics --entity-name test-cqy --describe

6.ブローカーの割り当て制限フロー

ブローカー間でデータクォータをコピーする

Kafkaは、ブローカー間のレプリケーションと送信のためのトラフィック制限機能を提供します。これにより、あるブローカーノードから別のブローカーノードへのパーティションデータレプリケーションの帯域幅の上限が制限されます。クラスターを再調整する場合、古いブローカーを追加または削除するように新しいブローカーをガイドすると便利です。構成に関する注意事項は次のとおりです。

1. トピックは、DynamicReplicationQuotaの現在の制限のキャリアです。トピックが特定のトピックに作用する場合のみ、現在のクォータ制限が有効になります。
2. leader | follower.xxx.throttled.replicasとleader | follower.xxx.throttled.rateの両方が有効になるように構成されている
3. 構成は、xxx.throttled.replicasの範囲の電流を制限するだけで、他のトピックの電流を制限しません

Kafkaレプリケーションクォータ制限は非常に柔軟で、2つのパラメータがレートとレプリカの事前制限として使用され、構成トピックに対してのみ有効であることを確認します。たとえば、クラスターが拡張してブローカーを追加するシナリオでは、指定したトピックにIOプレッシャーを移行して割り当てる必要があります。すべてのトピックが制限されている場合、ビジネスの通常の運用に影響します。

xxx.throttled.rateの構文を設定します（brokerIdのみ設定でき、-entity-defaultの設定は無効です）

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster --alter --entity-type brokers --entity-name $brokerId  --add-config  'leader.replication.throttled.rate=10485760' 

割り当てフロー2 2つの方法

方法1

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 105 --alter --add-config 'leader.replication.throttled.rate=10485760,follower.replication.throttled.rate=10485760'

bin/kafka-configs.sh --zookeeper localhost:2181/kafkacluster  --entity-type topics --entity-name topicA --alter --add-config 'leader.replication.throttled.replicas=*,follower.replication.throttled.replicas=*'

方法2

再割り当てスクリプトを使用して、leader＆follower.xxx.throttled.rateの現在の制限を設定し、パーティションの移行の操作と同時に現在の制限を設定して、IOネットワークカードの過度の爆発を回避します。次のスロットルは実際にleader＆follower.xxx.throttled.rate = 31457280を生成します。下部では、reassignは依然としてkafka-configs.shのAPI実装を呼び出し、move.jsonがカバーするブローカーを1つずつ構成します。

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/kafkacluster --reassignment-json-file move.json --throttle 31457280 --execute

上記のパーティションデータの移行が完了したら、次のスクリプトを実行して–throttleパラメーターの構成を削除します

bin / kafka-reassign-partitions.sh --zookeeper localhost：2181 / kafkacluster --reassignment-json-file reassign.json --verify

fetchRequestとfetchResponse関数の両方：

1. fetchRequestは、follower.replication.throttled.rateフロー制限についてリーダーへの複製要求を開始します。フォロワー要求フローがしきい値より大きい場合、トピックがこのfetchRequest要求を送信することを制限することはできません。次の要求がしきい値に達しない場合、正常に送信できます。
2. リーダーは、コンテンツのfetchResponseでフォロワーに応答します。これは、leader.replication.throttled.rateで現在を制限するために使用されます。リーダーの応答フローがしきい値より大きい場合、トピックを制限してfetchResponse応答に応答することはできません。次の応答はしきい値に到達せず、正常に応答できます。

ブローカーのパーティションディレクトリのデータ移行割り当て制限

なぜディレクトリの移行があるのですか？主な理由は、ハードウェアの急速な開発により、CPUパフォーマンスが大幅に向上し、複数のディスクをマウントする物理的な機会があり、クラスターの拡張が異なるモデルに追加される可能性があり、マウント数とパフォーマンスも異なるため、kafkaはブローカー内部を提供しますディレクトリ間の移行のデータトラフィックを制限する機能は、あるディレクトリから別のディレクトリへのデータコピーの帯域幅の上限を制限します。一般に、ブローカーのマウントポイント間のパーティション数のバランスを取り、IOプレッシャーを減らすために使用されます

現在の時間の間でデータを移行する場合、特定のパーティションが設定され、これらのパーティションが電流制限のキャリアになります。具体的な操作は次のとおりです。

ブローカーでのパーティション移行スクリプトの具体的な使用方法については、パーティションディレクトリデータの移行を確認してください

bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 105 --alter --add-config 'replica.alter.log.dirs.io.max.bytes.per.second=104857600'

ディレクトリデータの移行は、独立したFutureLocalReplicaロールとして設定されます。これは、ブローカー間のレプリケーションクォータの現在の制限機能の影響を受けません。

7.まとめ

1. kafka-configs.shの詳細な構文フォーマットは、記事の最初にリストされています。これは、読者が読んで使用するのに便利です。
2. クライアントクォータの現在の制限3つの細かい構成で8つの優先順位の組み合わせ
3. Brokersタイプの7つの構成モジュールには、2つの優先度レベルがあります。brokerIdのローカルスコープのみであるDynamicReplicationQuotaを除き、他のモジュールはグローバルスコープで使用できます。
4. ブローカー間のレプリケーション制限では、ブローカーとトピックの2種類の組み合わせ構成を実現する必要があります。
5. ブローカーのパーティションディレクトリの移行制限では、特定のパーティションのレプリカと移行ディレクトリを構成するためにkafka-reassign-partitions.shスクリプトの組み合わせが必要です

Li Zhitaoからの引用ブログ：https://www.cnblogs.com/lizherui/p/12275193.html