序文
みなさん、こんにちは。はい。
これはKafka源码分析の4番目の記事です。今日Kafka控制器、それについて話しましょうKafka Controller。
携帯電話の観点から見たソースタイプの記事は実際には非常に貧弱です。この記事Iは2つの部分に分かれています。最初の部分は、Kafkaプロセス全体を処理するコントローラーイベント全体をクリアするための直接のグラフィックであり、次にController选举流程ソースコード分析の実施の波を通してプロセス全体を一度に処理します。
携帯電話で見た生徒の中には、前半を直接見ることができる人もいます。コードの束がより快適で、プロセス全体を理解できるわけではありません。ソースコードの後半部分は個人によって異なります。
ただし、コンピューター側でより良い結果を確認することをお勧めします。
テキスト
ソースコードを掘り下げる前に、まずController何を完全に理解する必要がありますか？何のために？このようにして、ソースコードを見るときにターゲットを絞ることができます。
Controllerあるコア・コンポーネントの役割をすることで、管理し、座標全体をKafka集群。
具体的な管理と調整は何ですか？
- テーマの管理、テーマの作成と削除。
- パーティション管理、パーティションの追加または再割り当て。
- 地区
Leader選挙 Broker関連する変更を監視します。つまり、Broker追加、閉じるなどです。- メタデータ管理、他の人に
Brokerメタデータサービスを提供する;
なぜそれが必要なのControllerですか？
私は個人的に、何かを管理または調整するためにすべてが必要であることを理解していますLeader。彼は全体的な状況を制御し、内部を管理し、外部と接続しLeaderます。私たちはただ従うだけで完了します。これは実際には外の世界にとって良いことです。外部は私たち全体と通信する必要はありません。彼は意思決定者と通信するだけでよく、より効率的です。
朱大が言ったことを見てみましょう。以下の内容は「カフカの深い理解：コアデザインと実践原則」からのものです。
Kafkaの初期バージョンでは、Kafka Controllerの概念は、パーティションとレプリカの状態を管理するために使用されていませんでした。代わりに、ZooKeeperに依存していました。各ブローカーは、ZooKeeperにパーティションとレプリカの多数のウォッチャーを登録しました。 。
パーティションまたはレプリカのステータスが変更されると、多くの不要なモニターが起動されます。ZooKeeperに大きく依存するこの種の設計では、頭脳が分裂し、群れの効果が生じ、ZooKeeperに過負荷がかかるという隠れた危険性があります。新しいバージョンの現在の設計では、Kafkaコントローラーのみが対応するリスナーをZooKeeperに登録し、他のブローカーがZooKeeperでデータの変更を監視する必要がほとんどないため、多くの不要なトラブルを回避できます。
ZooKeeperについて話すだけです
の極端な依存性があるため、Controller簡単に理解するZooKeeperために必要な次のアクションを理解してください。（ただし、コミュニティはそれを削除する予定です。記事の最後で言及します）ControllerZooKeeperZooKeeper
ZooKeeperこれはオープンソースの分散調整サービスフレームワークであり、レジストリなどとして最も一般的に使用されます。ZooKeeperデータモデルはファイルシステムのようなもので、ルートディレクトリ "/"で始まり、構造上の各ノードが呼び出されznode、いくつかの情報を格納できます。ノードは永続ノードと一時ノードに分けられ、セッションが終了すると一時ノードは自動的に削除されます。
また、Watcher機能があり、ノード自体のデータ変更、ノードの追加、ノードの削除、および子ノード番号の変更はすべて、変更リスナーを介してクライアントに通知できます。
ControllerはZooKeeperにどのように依存していますか
各ノードBrokerは、起動時にZooKeeper登録された/controllerノードからコントローラーを実行しようとし、ノードを最初に作成した/controllerノードBrokerがコントローラーとして指定されます。これはコントローラーの選出です。
/controllerノードは一時的なノードであり、他の人Brokerがこのノードを監視します。/controllerノードがBrokerダウンすると、セッションが終了し、ノードが削除されます。他の人はBrokerコントローラーになる機会を待っているか、/controllerノードを最初に作成Brokerした人がコントローラーとして指定されます。これはコントローラーのフェイルオーバーFailoverです。
もちろん、Watcher関連する監視を実現し、対応する処理を実行するために、機能を介したトピックの増減などのさまざまなノードの監視も含まれます。
Controller初期化中に、ZooKeeperクラスターメタデータ情報がそこから取得され、独自のキャッシュに格納されます。その後、他のクラスターにBroker要求を送信することにより、データが相互に同期されます。
コントローラの低レベルのイベントモデル
リッスンWatcherしているかどうかZooKeeperWatcher线程、またはタスクスレッドや他のスレッドのタイミングもController、クラスターのプルからメタデータにアクセスまたは更新する必要があります。多线程 + 数据竞争 = 线程不安全。したがって、スレッドの安全性を確保するにはロックが必要です。
当初Kafkaは、スレッド間の同期を確保するために多数のロックが使用されていましたが、さまざまなロックによってパフォーマンスが低下し、マルチスレッドロックによってコードの複雑さが大幅に増加しました。注意しないと、さまざまな問題が発生し、バグの修正が困難になります。
したがって、バージョン0.11以降、マルチスレッド同時アクセスはシングルスレッドイベントキューモードに変更されました。共有データの競合に関連するアクセスはイベントに抽象化され、イベントはブロッキングキューに詰め込まれ、次にシングルスレッド処理されます。
つまり、他のスレッドはまだ存在しますが、共有データを含む操作はイベントにカプセル化され、専用スレッドによって処理されます。
要約させてください
この時点で、これはController主にクラスターの管理と調整、特にクラスター内の変更を監視するためのZooKeeper一時的なノードとWatcherメカニズム（もちろん、タイミングタスクまたは他のスレッドからのイベント駆動型）、クラスターのメタデータの更新、およびクラスターへの通知に使用されることをすでに理解しています。Broker（この部分については後で説明します）のその他の関連操作。
クラスターメタデータには同時変更の問題があるため、操作はイベントに抽象化され、以前のマルチスレッド処理はブロッキングキューとシングルスレッド処理に置き換えられます。これにより、コードの複雑さが軽減され、コードの保守性とパフォーマンスが向上します。
次に、Controller通知クラスター内の他のBroker関連操作について説明します。
コントローラリクエストの送信
ControllerZooKeeperそこから変更通知を受け取った後Broker、対応する処理を実行するようにクラスター（それ自体を含む）に通知する必要があります。
ControllerBroker3つの要求のみがクラスターに送信されます：それぞれLeaderAndIsrRequest、StopReplicaRequestおよびUpdateMetadataRequest
LeaderAndIsrRequest
情報に基づいたBrokerトピックパーティションLeaderとそのISRコピーがBrokerオンになっています。
StopReplicaRequest
Brokerサブジェクトシーンの削除またはコピー移行シナリオのパーティション分割に使用される、関連するコピー操作を停止するように通知します。
UpdateMetadataRequest
Brokerメタデータを更新します。
Controller事件处理线程イベントは対応するリクエストにカプセル化され、リクエストは対応するBrokerリクエストブロッキングキューに書き込まれ、RequestSendThread保留中のリクエストはブロッキングキューから継続的に取得されます。
最初controllerBrokerStateInfoに説明します。これはPOJOクラスであり、クラスターごとにbroker1つとして理解できますcontrollerBrokerStateInfo。
次にもう一度ControllerChannelManager見てください。名前から、ControllerクラスターとのBroker接続を管理し、それぞれにスレッドをBroker作成していることがわかりますRequestSendThread。
もう一度要約する
前の要約に続いて、イベント処理スレッドは、イベントキューでイベントを処理した後、対応する要求をカプセル化し、通知が必要なクラスターにBroker対応するブロッキングキューに詰め込み、各Broker排他的requestSendThread要求を対応するクラスターに送信しますBroker。
全体的な手順は次のとおりです。
それがControllerどのように機能するかは今では明らかであるはずであり、全体的な外観は依然として生産者-消費者モデルです。
次に、ソースコードのリンクを入力します。
コントローラー選出プロセスのソースコード分析
イベント処理のプロセスは同じですが、特定のイベントロジックが異なります。最初からController选举プロセスを見ていきましょう。
ControllerChangeHandler
選挙がこれをトリガーし、イベントキューにhandlerあるControllerEventManagerものを直接見ることができます。
このQueueEvent合計ControllerEventManager、最初に見てみましょう。しかし、その前に最初に理解しControllerEvent、ControllerEventProcessor。
ControllerEvent：イベント
ControllerEventProcessor：イベント処理インターフェイス
このインターフェイスの唯一の実装クラスはKafkaControllerです。
ControllerEventManager：イベントハンドラー
このクラスは、主にイベント処理スレッドとイベントキューを管理するために使用されます。
QueuedEvent：ControllerEventをカプセル化するクラス
主にチームに参加した時間を記録し、イベントで呼び出されるメソッドを提供します。
ControllerEventThread：イベント処理スレッド
全体として、非常に簡単です。キューからイベントを取得して処理します。
KafkaController＃process
イベントに応じて対応するprocessXXXXメソッドを呼び出すスイッチです。
controller再選イベントにご注目ください
次に、メソッドonControllerFailoverが内部で呼び出されますsendUpdateMetadataRequest
途中で呼び出しが省略され、内容が多すぎて要点ではなく、後で呼び出されますControllerBrokerRequestBatch#sendRequest
最後にそれは呼ばれましたcontrollerChannelManager#sendRequest。
次にRequestSendThread#doWork、リクエストキューからリクエストを取得し、リクエストを送信し続けます。
1つのリンクが完成しました！全体のフローチャートを見てみましょう
最後に、メタデータのKafkaControllerいくつかのフィールドを見てみましょう。
ControllerContext：メタデータ
主に、実行中Broker、すべてのトピック情報、トピックパーティションのコピー情報などが含まれます。
KafkaController
基本的にキーフィールドについて説明し、ステートマシンのセクションは限られていますが、後で説明します。
やっと
全体的なプロセスは、Controller関連する操作をイベントにカプセル化してから、イベントをキューに入れ、イベント処理スレッドによって処理されてデータのセキュリティを確保することです（これから、マルチスレッドが優れていること、および長所と短所があることもわかります。まだシーンを見てください）。
最後に、クラスターBrokerに通知するプロセスでは、それぞれにBroker送信スレッドが装備されています。送信は同期的であるBrokerため、各スレッドを分離すると、特定のBrokerブロックが防止され、ブロック全体が発生する可能性があります。
Kafka Controller強い依存については前に話しましたZooKeeper。しかし今、ZooKeeperそれはZooKeeper頻繁な書き込みには適さず、CPであるため、コミュニティはそれを削除することを計画しています。さらに、クラスターKafkaを維持する必要がありますZooKeeper。これにより、システムの操作と保守が複雑になり、困難になり、システムの安定性が低下します。
変位情報と同様に、内部テーマによって保存され、バイパスされていZooKeeperます。
コミュニティは、RaftのようなコンセンサスアルゴリズムControllerを介して投票し、ログにメタデータを保存する予定です。
はい、少しから少しまで、次の記事でお会いしましょう。
以前の推奨事項：
メッセージキューインタビューの連続質問：メッセージが失われないようにするにはどうすればよいですか？重複するメッセージを処理しますか？メッセージの順序は？メッセージ蓄積処理？
図+コード|一般的な電流制限アルゴリズムと単一マシン分散シナリオでの電流制限についての考え方