コントローラアセンブリ（コントローラ）、アパッチカフカコア構成要素です。その主な役割は、（コミュニティが依存飼育係を取り除くことを計画している）のApache飼育係の助けを借りて、全体カフカクラスタを管理し、調整することです。Renyiyitaiブローカクラスタは、クラスタ内の通常動作時にコントローラが1つしか持つことができ、コントローラになることができます。
ブローカーの起動時に実際には、それは/コントローラノードの飼育係が行く作成しようとします。最初に成功した作成/コントローラノードブローカは、コントローラとして指定されます。
コントローラの役割：
- テーママネージャ：作成、削除、パーティションを増加させるためのテーマ。私たちは、スクリプトRenyiyitaiカフカ - 話題のブローカーを実行すると、自動的にコントローラ、およびコントローラの作業を行うことがあります。
- ゾーニングの再配分：再配布は、主に既存の分布関数きめの細かい話題が提供するパーティション、カフカ-再割り当てパーティションのスクリプトを指します。この機能は、達成するためのコントローラの一部です。
- 優先（優先順位）リーダー選挙：優先リーダー選挙は、主にブローカーが提供する一部の過負荷を避けるために計画カフカリーダーの変更です。
- クラスタメンバーの管理：新しいブローカー、ブローカー積極的に閉じ、ブローカーのダウンタイム
- データサービス：ブローカーはちょうど他のデータサービスを提供したいです。クラスタコントローラは、最も完全なメタデータ情報で保存し、他のすべてのブローカーは、定期的にキャッシュメモリ内のデータを更新するには、メタデータコントローラによって送信された要求を更新します。
ここでは、コントローラに格納される情報を説明するための図で：
この情報はまた、飼育係に保存されている上記の値であることに注意してください。たび初期化コントローラは、それが飼育係から対応するメタデータを読み込み、独自のキャッシュに充填します。これらのデータでは、外部コントローラは、データベース・サービスを提供することができます。
フェイルオーバー：
私たちは、前者は⾯あまりにも、プロセスを実行する際にカフカのクラスタ内で、唯一の⼀駅Brokerが変色⻆のコントローラとして機能し、その後、保険⻛の故障（単一障害点）のこのシングルポイント、カフカが単一に対処する方法です強調する障害点、それ？答えは、コントローラは、いわゆるフェイルオーバーを言うことであるフェイルオーバー機能を、提供するものです。
フェイルオーバーではなく、コントローラの故障使用前の準備使用開始直前のコントローラをコントローラがまだ終了を突然、または予期しないダウンタイムを実行しているときと、カフカはすぐに感じることができることを意味し、そして注意。このプロセスは関係なく、あなたの時計、乾燥前に移動する必要がある場合、プロセスが自動的に行われ、フェイルオーバーとして知られていません。次に、我々は⼀の写真を見て⼀アップは、それは単にプロセスコントローラのフェイルオーバーを示しています。
当初、ブローカー0はコントローラです。ブローカ0ダウンタイムのZooKeeperはに時計機構によって知覚及び/コントローラの一時的なノードを削除します。全ての生存ブローカーキャンペーン後に新しいコントローラのアイデンティティを開始します。ブローカー3は最終的選挙、ZooKeeperの上、正常に再構成/コントローラノードを獲得しました。後、ブローカー3のZooKeeperからクラスタ情報メタデータを読み込み、自分のキャッシュを初期化します。⾄これは、フェイルオーバ・コントローラは、完了した⾏の通常業務として確実に動作します。
内部統制の設計の原則：
在 Kafka 0.11 版本之前，控制器的设计是相当繁琐的，代码更是有些混乱，这就导致社区中很多 控制器⽅⾯的 Bug 都⽆法修复。控制器是多线程的设计，会在内部创建很多个线程。⽐如，控制 器需要为每个 Broker 都创建⼀个对应的 Socket 连接，然后再创建⼀个专属的线程，⽤于向这 些 Broker 发送特定请求。如果集群中的 Broker 数量很多，那么控制器端需要创建的线程就会很 多。另外，控制器连接 ZooKeeper 的会话，也会创建单独的线程来处理 Watch 机制的通知回 调。除了以上这些线程，控制器还会为主题删除创建额外的 I/O 线程。 ⽐起多线程的设计，更糟糕的是，这些线程还会访问共享的控制器缓存数据。我们都知道，多线 程访问共享可变数据是维持线程安全最⼤的难题。为了保护数据安全性，控制器不得不在代码中 ⼤量使⽤ReentrantLock 同步机制，这就进⼀步拖慢了整个控制器的处理速度。 鉴于这些原因，社区于 0.11 版本重构了控制器的底层设计，最⼤的改进就是，把多线程的⽅案改 成了单线程加事件队列的⽅案。我直接使⽤社区的⼀张图来说明。
从这张图中，我们可以看到，社区引⼊了⼀个事件处理线程，统⼀处理各种控制器事件，然后控 制器将原来执⾏的操作全部建模成⼀个个独⽴的事件，发送到专属的事件队列中，供此线程消 费。这就是所谓的单线程 + 队列的实现⽅式。 值得注意的是，这⾥的单线程不代表之前提到的所有线程都被“⼲掉”了，控制器只是把缓存状态 变更⽅⾯的⼯作委托给了这个线程⽽已。 这个⽅案的最⼤好处在于，控制器缓存中保存的状态只被⼀个线程处理，因此不再需要重量级的 线程同步机制来维护线程安全，Kafka 不⽤再担⼼多线程并发访问的问题，⾮常利于社区定位和 诊断控制器的各种问题。事实上，⾃ 0.11 版本重构控制器代码后，社区关于控制器⽅⾯的 Bug 明显少多了，这也说明了这种⽅案是有效的。
针对控制器的第⼆个改进就是，将之前同步操作 ZooKeeper 全部改为异步操作。ZooKeeper 本 身的 API 提供了同步写和异步写两种⽅式。之前控制器操作 ZooKeeper 使⽤的是同步的 API， 性能很差，集中表现为，当有⼤量主题分区发⽣变更时，ZooKeeper 容易成为系统的瓶颈。新 版本 Kafka 修改了这部分设计，完全摒弃了之前的同步 API 调⽤，转⽽采⽤异步 API 写⼊ ZooKeeper，性能有了很⼤的提升。根据社区的测试，改成异步之后，ZooKeeper 写⼊提升了 10 倍！ 除了以上这些，社区最近⼜发布了⼀个重⼤的改进！之前 Broker 对接收的所有请求都是⼀视同 仁的，不会区别对待。这种设计对于控制器发送的请求⾮常不公平，因为这类请求应该有更⾼的 优先级。
举个简单的例⼦，假设我们删除了某个主题，那么控制器就会给该主题所有副本所在的 Broker 发送⼀个名为StopReplica的请求。如果此时 Broker 上存有⼤量积压的 Produce 请求，那么这 个 StopReplica 请求只能排队等。如果这些 Produce 请求就是要向该主题发送消息的话，这就 显得很讽刺了：主题都要被删除了，处理这些 Produce 请求还有意义吗？此时最合理的处理顺 序应该是，赋予 StopReplica 请求更⾼的优先级，使它能够得到抢占式的处理。 这在 2.2 版本之前是做不到的。不过⾃ 2.2 开始，Kafka 正式⽀持这种不同优先级请求的处理。 简单来说，Kafka 将控制器发送的请求与普通数据类请求分开，实现了控制器请求单独处理的逻 辑。鉴于这个改进还是很新的功能，具体的效果我们就拭⽬以待吧。