Technologieaustausch

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

1. Controller-Broker

Im Kafka-Cluster gibt es einen Controller Broker, der für die Metadatenverwaltung und -koordination verantwortlich ist.

Kafka verwendet Zookeeper als Speicher- und Verwaltungstool für Cluster-Metadaten. Zookeeper speichert die Statusinformationen des Clusters, einschließlich aller Themen-, Partitions-, Leader- und Replikatinformationen usw.

Wenn sich der Clusterstatus ändert, schreibt Controller Broker die Änderungsinformationen an Zookeeper.

Wenn der aktuelle Controller-Broker ausfällt, erkennen andere Broker im Kafka-Cluster diese Situation und führen Wahlen über Zookeeper durch.

Nachdem ein Broker erfolgreich als neuer Controller-Broker ausgewählt wurde, liest er die neuesten Cluster-Metadaten von Zookeeper.

Garantiemechanismus

• Persistente Metadaten: Zookeeper speichert dauerhaft Metadaten des Clusters und stellt so sicher, dass jederzeit die neuesten Statusinformationen abgerufen werden können.
• Herzschlagmechanismus: Die Verbindung zwischen Broker und Zookeeper wird über den Heartbeat-Mechanismus aufrechterhalten, um Ausfälle des Controller-Brokers schnell zu erkennen.
• Wahlmechanismus: Durch den Wahlmechanismus von Zookeeper kann schnell ein neuer Controller-Broker ausgewählt und Metadaten von Zookeeper synchronisiert werden.

2. Komponentenarchitektur

1. Protokollmanager

LogManagerHauptverantwortlich für die Verwaltung der Speicherung und des Abrufs von Kafka-Protokollen (Protokoll).

Beispiel: Der Produzent sendet die Nachricht an Leader Broker1 von Partition0.LogManagerSchreiben Sie die Nachricht in die Protokolldatei von Partition0 auf Broker1.

2. Replikationsmanager

ReplicationManagerHauptverantwortlich für die Verwaltung der Replikation und Synchronisierung von Partitionsdaten.

Die Synchronisierung zwischen Leader und Follower jeder Partition wird unabhängig durchgeführt. Das heißt, jede Partition verfügt über einen eigenen Synchronisierungsprozess und ist nicht von anderen Partitionen abhängig.

Obwohl der Synchronisierungsprozess jeder Partition unabhängig ist, startet jeder Broker entsprechende Replikationsthreads für jede von ihm verwaltete Partition (ob Leader oder Follower), und diese Threads sind für die Abwicklung spezifischer Synchronisierungsaufgaben verantwortlich.

Zum Beispiel:ReplicationManagerSchieben Sie neu geschriebene Nachrichten auf Broker1 an Follower Broker2 und Broker3 von Partition0.ReplicationManagerVon Broker1 empfangene Replikationsanforderungen werden auf Broker2 und Broker3 verarbeitet und Nachrichten in ihre jeweiligen Protokolldateien geschrieben.

3. SocketServer

SocketServer Es ist eine Komponente im Kafka Broker und für die Abwicklung von Netzwerkverbindungen und E/A-Vorgängen verantwortlich. Es ist dafür verantwortlich, Verbindungsanfragen von Clients und anderen Brokern anzunehmen und jeder Verbindung einen Thread zur Verarbeitung zuzuweisen.

4. Netzwerkserver

NetworkServer Es ist ein zentraler Bestandteil des Netzwerkkommunikations-Frameworks von Kafka und für die Verwaltung und Planung von Netzwerkanforderungen verantwortlich. Es verwendet NIO (nicht blockierende E/A), um hochgradig gleichzeitige Netzwerkverbindungen zu verarbeiten.

5. ZKClient

Komponente, die mit Zookeeper kommuniziert.