コントローラアセンブリ（コントローラ）、アパッチカフカコア構成要素です。その主な役割は、Apache ZooKeeperのの助けを借りて、全体カフカクラスタを管理し、調整することです。コントローラは、ZooKeeperのに大きく依存しています。
Renyiyitaiブローカクラスタは、唯一のブローカーは、コントローラ、その管理と調整役の行使になるために、操作中に、しかし、コントローラとして機能することができます。換言すれば、カフカの各クラスタの正常動作は、いつでも唯一つのコントローラがあります。JMXメトリックと呼ばれるactiveControllerの公式ウェブサイトがあり、リアルタイム監視は、私たちは状態コントローラを生き残ることができます。JMXメトリックは、この指標のリアルタイム値を表示するようにしてください、あなたは実際の運用および保守作業の過程にある、非常に重要です。
1.コントローラ選挙
起動時にBrokerは、それが/コントローラノードのZooKeeper行く作成しようとします。カフカ現在の選挙ルール・コントローラは、次のとおりです。最初に成功した創造ブローカー/コントローラー・ノードは、コントローラとして指定されます。
2.コントローラの役割
コントローラは、調整的な役割を果たしている職務の5種類に分けることができる成分です。
テーママネージャ2.1（作成、削除、増加パーティション）
ここでのテーマの管理は、私たちは、カフカのテーマの作成を完了、削除、および運用パーティションを増加を助けるために、コントローラを指します。私たちは、スクリプトカフカ-トピックを実行すると、他の言葉では、背景の仕事のほとんどは、コントローラに行われます。
2.2パーティションの再配分
パーティションの再分配は、主に、パーティションの被写体に設けられカフカ-交代・パーティションのスクリプト（このスクリプトには、私は後で紹介します）であったきめ細かい分布関数を意味します。コントローラ機能のこの部分が実現されます。
2.3優先リーダー選挙
優先リーダー選挙は、主にブローカーが提供する一部の過負荷を避けるために変更リーダーのアプローチカフカです。
2.4クラスタメンバの管理（新しいブローカー、ブローカー積極的に閉じられた、ブローカーのダウンタイム）
これは、新しいブローカ、ブローカ能動及び受動閉鎖ダウンの自動検出を含むコントローラ4、が提供する機能のクラスです。この自動検出機能を実現するノードと、一時のZooKeeperのウォッチ前述の組み合わせに依存しています。
例えば、コントローラは、部品点数がサブノード/ブローカー/ IDS ZooKeeperの時計機構ノードのチェックを使用する変更します。新しいブローカーの開始があった場合、現在、それは/ブローカーの下で排他的なのznodeノードを作成します。作成したら、コントローラは自動的に変更を認識し、次の新しいブローカーの仕事を活性化させることができるように。、ウォッチ機構によるのZooKeeperは、コントローラに通知メッセージをプッシュします
一時的なノード：ブローカーは、生存率が今述べた別のメカニズムに依存している検出します。各ブローカーが開始された後、/ブローカー/ IDSでの一時的なのznodeを作成します。イニシアチブは、ZooKeeperのとのセッションの終わりを閉鎖またはブローカー、ブローカーにすると、のznodeは自動的に削除されます。コントローラは、ブローカーまたは閉鎖、ひいてはがあることを知ることができますように、同様に、ウォッチメカニズムのZooKeeperは、コントローラにこの変更をプッシュします「リハビリ。」
2.5データサービス
最後に、コントローラ動作の大きなクラスは、他のブローカにデータサービスを提供することです。クラスタコントローラは、最も完全なメタデータ情報で保存して、他のすべてのブローカーは、更新要求メタデータコントローラがキャッシュメモリ内のデータを更新するために定期的に送信されます。
3.保存したデータコントローラ
図に示すように、制御装置に記憶されているデータの種類。
- すべての被写体情報。ISRのコレクションを持っているなど、誰リーダー、そのコピーのコピー、などの特定のパーティション情報、を含みます。
- すべてのブローカー情報。ようにブローカーに閉鎖している、現在持っているブローカーの動作を含みます。
- すべてのタスクは、パーティションの運用・保守に関わります。継続的な優先リーダー選挙と再割り当てのパーティションのリストを含みます
実際には、これらのデータはまた、ZooKeeperの中に保存されます。コントローラが初期化するたびに、それはのZooKeeperから対応するメタデータを読み込み、独自のキャッシュに充填します。これらのデータでは、外部コントローラは、データサービスを提供することができます。ここで主に外部の他のブローカー、他のブローカーにデータを同期させるためにブローカに要求を送信することによって、コントローラを指します。
4.コントローラのフェイルオーバー
クラスタ操作カフカの間に、あなただけのコントローラとして1つのブローカーの役割、そして障害リスク（単一障害点）のこの一点は、どのようにカフカがそれをある単一障害点に対処するために持つことができますか？答えは、コントローラは、いわゆるフェイルオーバーを言うことであるフェイルオーバー機能を、提供するものです。
認知カフカすぐに、コントローラの突然のまたは予期しない終了にすることができますダウン実行されている、と直前に故障したコントローラの代わりにスタンバイを有効にすることを意味フェイルオーバー。このプロセスは、フェイルオーバーと呼ばれています。下図のように：
当初、ブローカー0はコントローラです。ブローカは0ダウンタイム、ZooKeeperのは、削除/コントローラ一時ノードに時計機構によって知覚されるとき。全ての生存ブローカーキャンペーン後に新しいコントローラのアイデンティティを開始します。ブローカー3は、最終的にZooKeeperの上で正常に再構成/コントローラノード、選挙に勝ちました。後、ブローカー3は、中のZooKeeperクラスタからメタデータ情報を読み取り、独自のキャッシュに初期化。これまでのところ、フェイルオーバーコントローラは、業務の正常な運動完了です。
インテリアデザインの原則コントローラー
5.1 イベント処理スレッド
カフカイベント処理スレッド、種々のコントローライベントの統一処理は、コントローラは、このスレッドの消費のために排他的なイベント・キューに送信された別のイベントとしてモデル化オリジナルの全体の動作を実行します。これは、シングルスレッド+キューの実装と呼ばれています。
值得注意的是，这里的单线程不代表之前提到的所有线程都被“干掉”了，控制器只是把缓存状态变更方面的工作委托给了这个线程而已。这个方案的最大好处在于，控制器缓存中保存的状态只被一个线程处理，因此不再需要重量级的线程同步机制来维护线程安全，Kafka 不用再担心多线程并发访问的问题，非常利于社区定位和诊断控制器的各种问题。
5.2 异步操作Zookeeper
Kafka 采用异步 API 写入 ZooKeeper，性能有了很大的提升。
5.3 请求设定优先级
之前 Broker 对接收的所有请求都是一视同仁的，不会区别对待。这种设计对于控制器发送的请求非常不公平，因为这类请求应该有更高的优先级。自 2.2 开始，Kafka 正式支持这种不同优先级请求的处理。简单来说，Kafka 将控制器发送的请求与普通数据类请求分开，实现了控制器请求单独处理的逻辑。
