Diese Übersicht ist ein bisschen in der Zusammenfassung. Jede von ihnen werden jede Sekunde des Tages ständig in jedem von ihnen generiert. Darüber hinaus müssen Sie auch eine Reihe von E -Mail -Servern überwachen, die Sie überwachen müssen.
Möglicherweise müssen Sie diese Daten für Aufzeichnungen und Abrechnungszwecke speichern. Dies ist ein Stapeljob, der keine sofortige Aufmerksamkeit erfordert. Möglicherweise möchten Sie Analysen für die Daten ausführen, um Entscheidungen in Echtzeit zu treffen, was eine genaue und sofortige Dateneingabe erfordert. Plötzlich sind Sie in der Notwendigkeit, die Daten für all die verschiedenen Bedürfnisse vernünftig zu optimieren. Kafka fungiert als diese Abstraktionsebene, in der mehrere Quellen verschiedene Datenströme veröffentlichen können, und eine gegebene Verbraucher kann die Streams abonnieren, die es für relevant findet. Kafka wird sicherstellen, dass die Daten gut geordnet sind. Es sind die Interna von Kafka, die wir verstehen müssen, bevor wir zum Thema Partitionierung und Schlüssel kommen.
Kafka Themen sind wie Tabellen einer Datenbank. Jedes Thema besteht aus Daten aus einer bestimmten Quelle eines bestimmten Typs. Zum Beispiel kann die Gesundheit Ihres Clusters ein Thema sein, das aus CPU- und Speicherauslastungsinformationen besteht. In ähnlicher Weise kann ein ankommender Verkehr im gesamten Cluster ein anderes Thema sein.
Kafka ist so konzipiert, dass er horizontal skalierbar ist. Das heißt, eine einzige Instanz von Kafka besteht aus mehreren Kafka Makler Wenn Sie über mehrere Knoten ausgeführt werden, kann jeder Datenströme parallel zum anderen verarbeiten. Auch wenn einige der Knoten nicht bestehen, kann Ihre Datenpipeline weiter funktionieren. Ein bestimmtes Thema kann dann in eine Reihe von unterteilt werden Partitionen. Diese Partitionierung ist einer der entscheidenden Faktoren für die horizontale Skalierbarkeit von Kafka.
Mehrere Produzenten, Datenquellen für ein bestimmtes Thema können gleichzeitig zu diesem Thema schreiben, da jeder zu einem bestimmten Zeitpunkt auf eine andere Partition schreibt. In der Regel werden nun eine Partition zufällig Daten zugeordnet, es sei denn, wir geben sie einen Schlüssel zur Verfügung.
Partitionierung und Bestellung
Nur um sich zusammenzufassen, schreiben die Produzenten Daten an ein bestimmtes Thema. Dieses Thema wird tatsächlich in mehrere Partitionen aufgeteilt. Und jede Partition lebt unabhängig von den anderen, auch für ein bestimmtes Thema. Dies kann zu großer Verwirrung führen, wenn die Bestellung an Daten wichtig ist. Vielleicht benötigen Sie Ihre Daten in einer chronologischen Reihenfolge, aber mehrere Partitionen für Ihren DataStream garantieren keine perfekte Bestellung.
Sie können nur eine einzelne Partition pro Thema verwenden, die jedoch den gesamten Zweck der verteilten Architektur von Kafka besiegt. Wir brauchen also eine andere Lösung.
Schlüssel für Partitionen
Daten eines Produzenten werden zufällig an Partitions gesendet, wie wir bereits erwähnt haben. Nachrichten sind die tatsächlichen Datenbrocken. Was Produzenten abgesehen vom Senden von Nachrichten tun können, besteht darin, einen Schlüssel hinzuzufügen, der damit einhergeht.
Alle Nachrichten, die mit dem spezifischen Schlüssel geliefert werden. So kann beispielsweise die Aktivität eines Benutzers chronologisch verfolgt werden, wenn die Daten dieses Benutzers mit einem Schlüssel markiert sind und so immer in einer Partition endet. Nennen wir diese Partition P0 und den Benutzer U0.
Partition P0 nimmt immer die u0 -bezogenen Nachrichten auf, da diese Schlüssel sie zusammenbindet. Das heißt aber nicht, dass P0 nur damit verbunden ist. Es kann auch Nachrichten von U1 und U2 aufnehmen, wenn es die Fähigkeit dazu hat. In ähnlicher Weise können andere Partitionen Daten von anderen Benutzern konsumieren.
Der Punkt, dass die Daten eines bestimmten Benutzers nicht auf unterschiedliche Partition verteilt sind, um die chronologische Reihenfolge für diesen Benutzer zu gewährleisten. Das Gesamtthema von jedoch Benutzerdaten, kann immer noch die verteilte Architektur von Apache Kafka nutzen.
Während verteilte Systeme wie Kafka einige ältere Probleme wie mangelnde Skalierbarkeit oder einen einzigen Fehler aufweisen. Sie haben eine Reihe von Problemen, die für ihr eigenes Design einzigartig sind. Diese Probleme zu antizipieren, ist eine wesentliche Aufgabe eines Systemarchitekten. Nicht nur das, manchmal muss man wirklich eine Kosten-Nutzen-Analyse durchführen, um festzustellen, ob die neuen Probleme ein würdiger Kompromiss sind, um die älteren zu beseitigen. Bestellung und Synchronisation sind nur die Spitze des Eisbergs.
Hoffentlich können solche Artikel und die offizielle Dokumentation Ihnen auf dem Weg helfen.