それは問題を解決するためにいくつかの時間がかかったように、いくつかの時間前に、非常に時間がかかるメッセージを送信するためにカフカクラスタ生産終了の顧客からのフィードバックを受け、最終的にデータの電流量によるクラスター展開は、のために、特定のトピックのために大きすぎます移行プロセス中も、クラスタ全体のパフォーマンスだけでなく、クライアントのパーティションを再バランシングプロセスの影響を含め、すべての面で十分な研究を行っているため、これらの項目の移行は非常に長い時間のためのコールが、プロセスは、スムーズに進みましたインパクトなど、ここにこのプロセスを要約し、また二から一一のための腕のショットを打ちます。
トラブルシューティングと分析
ユーザーからのフィードバックを受け取った後、私は再びテストスクリプトを使用し、他の正常カフカのクラスタに比べて、実際に高いがかかることがわかった、次の
調査の後、我々は、接続中のクライアントが頻繁にクラスタノードから切断ことが判明し、ログが頻繁に以下を印刷しました。
Attempting to send response via channel for which there is no open connection, connection id xxx(kafka.network.Processor)复制代码ここでは、ソースコードを探します。
kafka.network.Processor＃sendResponse：
これはビッグデータスパークノードクラスタで、後の問い合わせ時に、クライアントの担当に特定の人物を見つけ、リモート接続が閉じているか、長すぎる手段アイドル、ソース・ノートを参照してください。
上から見たログは、コンシューマ・グループOrderDeliveryTypeCntスパーククラスタが実際に明らかに通常のイベントではありませんほぼ40,000倍の重量バランスをとる操作を、発生した、条件を相殺カフカ・コンシューマ・グループは次のとおり行われます。
- 消費者グループのメンバーシップの変更は、新しい消費者が参加したり休暇、または消費者がクラッシュします。
- テーマコンシューマ・グループのサブスクリプションの数が変更されました。
- パーティションコンシューマ・グループのサブスクリプションの数が変更されました。
第2および第3のポイントは、これが頻繁に切断さカフカ主導の消費者グループのメンバシップの変更は、グループが重い消費平準化につながっていた接続スパーククラスタ・ノードであると仮定されるだろう、実現しなかったことは明らかです。
なぜスパーククラスタは頻繁にそれを切断し、再接続する必要がありますか？
ビューカフカのバージョンやスパーククラスタとバージョン0.10.1.1、およびクラスタは、それがその後、ジュニアパートナーのデータ・インテリジェンス・ユニットは、クラスタスパークバージョン0.11.1.1に接続されるバージョンの互換性の問題、だと思った、2.2.1バージョンカフカですカフカのクラスタ、消費のために8つのスパークタスクの消費量を使用し、また、検出された問題は、切断されました。説明この問題は、消費者カフカをリードするため、スパーク内部機構であり、カフカのバージョンが行うことがほとんどありません。
ビッグデータのスタッフと議論を重ねた後、原因内部のメカニズムへのスパーク2.3バージョンのように頻繁にリバランスのルックスは、スパーク2.4バージョンでは、この問題はありません。
これによって頻繁に切断再接続するには、ない考慮に入れプロセスによる開発者、二から一一軽率変化にプロジェクトをアップグレードしないで、近づいて、今最善の解決策は、クラスタレベルを展開するクラスタの負荷容量を増加させることであり、そして、特別なトピックのパーティションの再分配。
パーティションの再分配制度の分析
6つのクラスタノード、ベンチマークとして50％の拡張、その後の操作で3つのノードを準備する必要があり、メンテナンスマシンの、クラスタに追加する準備の存在A合計で、次のステップは、対象パーティションの再配置を調製することですポリシーファイル。
パーティションの再割り当ての実装のプロセスでは、2つの主クラスタへの影響：
- パーティションの再分配は、主ブローカとの間のデータ移行の対象に、したがって帯域幅クラスタを消費します。
- パーティションの再配布は、このように、クライアントに影響を与え、リーダーブローカーが配置されているパーティションを変更します。
二点以上の場合は、最初のポイントは、夕方に行うことができる（苦い力、ほぼ5時間のテーマデータの移行があります覚えている）、第二の点のために、私は2つのオプションを考えます：
- 全体の割り当て方式は、2つの段階に分けられる：1）手動で生成された割り当て方式、元のパーティションリーダーの位置が変更されていない、唯一のコピーパーティション再分配、データマイグレーションの完了2）待機し、パーティションの手動変更、目的バランスの取れたリーダー。
- カフカAPIが直接提供、再配置スキームのパーティションを生成し、パーティションは、直接再割り当てを行います。
最初のオプションは、全体の割り当ては二つのステップ、すなわち、プロセスの別個の、より高い制御性のクラスタ内のクライアントと帯域幅リソースの影響が、問題に分割され、理論的には最小の顧客衝撃端部であります真のテストの難易度のバランスをとるために、マニュアルの残りのコピー、クラスタ内のテーマのいくつかは、64のパーティション、3のコピー率、192のコピーの合計がありますが、あなたは元のパーティションリーダー位置のケースを維持する必要があることは変わらず、来ますバイアスの少し、あまりにも多く、それが不均衡のコピーが発生します。
私は意図的にソース・パーティションの再割り当てを行って、さらにプロセスを解析したので、重量配分を割り当てるステップは、新たな割り当てを設定するパーティションの複製を形成するために割り当てられた新しいパーティションの元のコピーのコピーの集まりであることがわかっ最終的にISRに参加した変位のリーダーに追いつくための努力のコピーは、すべてのコピーは、ISRに追加された後、それはリーダー選挙に分割され、それは私が別の記事を書きます細部の元のコピー後に削除されます。
上記の手順の再配分によると、これは私に影響を与えるためのリーダーは、変更の際に、データ移行リーダー選挙の完了がされるとき、起こるが、ほとんど効果がありませんでしたように、データは、クライアントをブロックする過程で発生しないことを意味スクリプトを少しテストするために使用されることを意図：
これは、リーダーの変更が発生した場合、生産者は、速やかにメタデータに引っ張ってくる、とのメッセージを再送信し、送信プロセスで見つけることができます。
上記の分析とテストのために、私たちは、次の手順を実行し、2番目のオプションを取ることにしました。
- 実行時間（10：00-17：00）パーティション割り当てポリシーを割り当てられた各トピックに対して生成、及び割当戦略、実行及びtopic1セーブ検査パーティション reassignment.jsonファイルを、そしてtopic1元のスキーム保存パーティション reassignment_rollback.jsonファイルは、後続のロールバック操作を調製しました。
- 実行割り当てポリシー：性能期間（00：30-02：30）、準備topic1 パーティション reassignment.jsonファイル、再確認を実行し、割り当てのコピーを表示し、配布戦略の各実装状況ISR伸縮を表示する必要があり、メッセージフローの状況は、何の問題を特定せず、その後、次の割り当て方式を実行します。
- パラメータブローカクラスタの終わり以来
auto.leader.rebalance.enable=true、したがって、自動的に優先リーダー選挙を行い、かつ、デフォルトの間隔は300秒、選挙の際に優先リーダーの状況を見られるようになります。
パーティションの再配分
新しいブローカーのために、カフカは自動的に新しいパーティションのテーマBrokerに割り当てられません既存のテーマの負荷を分散されていないが、我々はAPIカフカ、特定により提供されるトピックのパーティション操作を再割り当てすることができます次のように：
- 生成のトピックは、JSONファイルのパーティションの再割り当てのリストを実行する必要があります。
echo '{"version":1,"topics":[{"topic":"sjzn_spark_binlog_order_topic"}]}' > sjzn_spark_binlog_order_topic.json复制代码- 割り当てトピックを生成します。
bin/kafka-reassign-partitions.sh --zookeeper --zookeeper xxx.xxx.xx.xxx:2181,xxx.xxx.xx.xxx:2181,xxx.xxx.xx.xxx:2181 --topics-to-move-json-file sjzn_spark_binlog_order_topic.json --broker-list "0,1,2,3,4,5,6,7,8" --generate复制代码64のパーティションのテーマは、割り当てデータを生成し、それぞれ3つのコピーが、まだ大きくなっているので、ここに掲載されていません
- JSONファイルを割り当てるためのプログラムを保存します。
echo '{"version":1,"partitions":[{"topic":"sjzn_spark_binlog_order_topic","partition":59,"replicas":[4,8,0],"log_dirs":["any","any","any"]} ......' > sjzn_spark_binlog_order_topic_reassignment.json复制代码- パーティションの再配布を実行します。
bin/kafka-reassign-partitions.sh --zookeeper xxx.xxx.xx.xxx:2181,xxx.xxx.xx.xxx:2181,xxx.xxx.xx.xxx:2181 --reassignment-json-file sjzn_spark_binlog_order_topic_reassignment.json --execute复制代码- パーティションの再割り当ての成功かどうかを確認します。
bin/kafka-reassign-partitions.sh --zookeeper xxx.xxx.xx.xxx:2181,xxx.xxx.xx.xxx:2181,xxx.xxx.xx.xxx:2181 --reassignment-json-file sjzn_spark_order_unique_topic_resign.json --verify复制代码
データの量は、特に大型の被写体に存在するため、全体の再配置プロセスは数時間維持される必要があります。
データ移行プロセスでは、それについて、私は地区のデータの変化を観察するためにカフカ-管理コンソールを取得する傾向があります：
コンソールからわかるように、各パーティションのコピーの基本的な数も追いつくためにはまだ部数を加えたオリジナルコレクションのコピー、新たに割り当てられたの新しく割り当てられたコピーのコピーのコレクションに等しい現在のパーティションを確認しており、増加しています変位のリーダーで、そのためには、ISRリストに参加しませんでした。
キャッチISRの新しい割り当てのフォローアップのコピーのための待ち時間は、優先リーダー選挙の新ラウンドを実施しますので、この時点で地区は、優先リーダーリーダーではない、ということに気づいていないことは、選挙の実装の詳細は、私は別のを書きます記事を分析するために、そのご期待。
しばらくすると、私は変位が変更されていることがわかりました。
この点からも限り何の変化が発生していないリーダーとして、クライアントは、パーティションのリーダーにメッセージを送信し続けることができ、パーティションの再割り当てプロセスを確認しました。
フィギュア、新たに割り当てられたコピーリーダーキャッチ変位からわかるように、リストは、ISRが追加されます。
今行くと帯域幅負荷のクラスタを参照してください。
上の図からわかるように、移行プロセスでは、新たに割り当てられたコピーは継続的リーダーからデータを引き出し、クラスタは、帯域幅を占有します。
終了後の状況のコピーを再配布テーマパーティション：
上の図からわかるように、地区の新たな割り当てのコピーがすべてのISRリストにされて、古い割り当てのコピーを削除している、優先リーダー選挙後、地区の優先リーダー、新たに割り当てられたコピーは、ほとんどとなりましたパーティションのリーダー。
いいえ公共よりエキサイティングな記事は、バックエンド技術関連公衆数の焦点である「バックエンドアドバンス」、の維持に注意を払うを喜びません。
いいえ世間の注目とは、バックエンドに関連した無料の電子書籍を受け取るために、「バックエンド」を返信しません。
シェアへようこそ、ソースを保管してください再現。
