Einführung
Eine Bestellung wird erstellt, eine weitere Bestellung wird erstellt, und anschließend wird die erste Bestellung bezahlt. Eine Tabelle mit dem aktuellen Status zeigt möglicherweise nur den neuesten Zustand jeder Bestellung. Ein Ereignis beschreibt etwas, das geschehen ist. Daher können alle drei Fakten als Verlauf nützlich bleiben. Systeme, die auf neue Bestellungen reagieren, benötigen eine Möglichkeit, diese Fakten zwischen Anwendungen weiterzugeben.
Apache Kafka speichert und übermittelt Ereignisdatensätze. Ein Producer sendet Datensätze, ein Broker ist der Server, der sie empfängt und speichert, ein Topic benennt einen Datenstrom, und ein Consumer liest die Datensätze. Kafka kann Anwendungen verbinden, die zu unterschiedlichen Zeiten oder mit unterschiedlichen Geschwindigkeiten arbeiten. Andere Verarbeitungswerkzeuge können aus diesen Ereignissen Berichte berechnen. Dieser Kurs konzentriert sich zunächst auf die zuverlässige Übermittlung und den Lesefortschritt.
Sie erstellen ein Topic, beobachten einen Producer und einen Consumer in getrennten Terminals und lesen dieselben Ereignisse erneut, nachdem der erste Consumer beendet wurde. Die vorbereitete Umgebung mit einem Broker verwendet ein Replikat; die Bereitstellung eines Clusters ist ein eigenes Thema. Für die ersten sechs Aktivitäten benötigen Sie lediglich grundlegende Terminalkenntnisse. Die späteren Aktivitäten mit Python-Clients setzen Funktionen, Schleifen, Dictionaries, JSON und das Ausführen von Skripten voraus. Der Python-Lernpfad kann Sie darauf vorbereiten. Java, Hadoop, Hive, Spark und externe Konten sind keine Voraussetzungen. Verwenden Sie den Dienst Terminal.
Erstellen Sie einen Speicherort für die Bestellereignisse
In diesem Schritt prüfen Sie, ob der vorbereitete Kafka-Dienst antwortet, und erstellen ein Topic. Behalten Sie diese erste Shell als Terminal A bei. Beginnen Sie in Ihrem Arbeitsverzeichnis:
## Terminal A
cd /home/labex/project
Die Befehlszeilenclients sind bereits installiert. --bootstrap-server gibt eine anfängliche Brokeradresse an, über die der Cluster ermittelt wird. Hier bezeichnet localhost:9092 den vorbereiteten lokalen Dienst und kein externes Konto. Listen Sie seine Topics auf, um eine tatsächliche Antwort des Brokers zu prüfen:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --list
In einer frischen Lernumgebung sind möglicherweise noch keine Anwendungstopics vorhanden. Erstellen Sie orders-first. Ein Topic enthält eine oder mehrere Partitionen, also geordnete Protokolle, die seine Datensätze speichern. Beginnen Sie mit einer Partition, damit diese erste Abfolge leicht nachvollziehbar bleibt. --replication-factor 1 passt zum einzelnen vorbereiteten Broker:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-first --partitions 1 --replication-factor 1
Untersuchen Sie das neue Topic:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-first
Suchen Sie den Topicnamen, PartitionCount: 1 und ReplicationFactor: 1. IDs, Leaderkennungen und Formatierung können abweichen. Mit dem Erstellen des Topics haben Sie das Speicherziel eingerichtet. Dabei wurde noch keine Bestellung gesendet und kein weiterer Server installiert.
Der Broker läuft weiter, während kurzlebige Producer- und Consumer-Clients gestartet und beendet werden. Als Nächstes nutzen Sie diese Trennung, um das Eintreffen von Ereignissen zu beobachten.
Beobachten Sie, wie ein Client empfängt, was ein anderer sendet
In diesem Schritt lassen Sie einen Consumer in einem Terminal warten und senden drei Datensätze aus einem anderen Terminal. Der Dienst Terminal erhält seine Shell mithilfe von tmux, einem Werkzeug zur Verwaltung von Terminalsitzungen. Eine zweite Browserverbindung zeigt zunächst dieselbe dauerhafte Sitzung an. Erstellen Sie für Terminal B eine eigene benannte Shellsitzung, damit die Clients unabhängige Eingabeaufforderungen haben.
Erstellen Sie in Terminal A die Sitzung im Hintergrund. -d lässt Ihr aktuelles Terminal ausgewählt, -s benennt die neue Sitzung und -c legt deren Startverzeichnis fest. Dadurch entsteht eine Shell und kein weiterer Kafka-Broker:
## Terminal A
tmux new-session -d -s kafka-b -c /home/labex/project
Öffnen Sie denselben Dienst Terminal in einem zweiten Browsertab und lassen Sie Terminal A geöffnet. Nennen Sie den neuen Tab Terminal B und wechseln Sie mit dieser Verbindung zur vorbereiteten Sitzung:
## Terminal B
tmux switch-client -t kafka-b
Drücken Sie nach dem Wechsel einmal Strg-C, um etwaige noch nicht abgeschickte Terminaleingaben zu löschen, während nur die Shell aktiv ist. Prüfen Sie den Sitzungsnamen:
## Terminal B
tmux display-message -p '#S'
Erwarten Sie kafka-b. Terminal A behält seine ursprüngliche Sitzung; beide Shells greifen auf dieselben VM-Dateien zu. Behalten Sie diese Rollen beim Wechseln zwischen den Browsertabs bei. Falls die benannte Sitzung während dieser Übung bereits erstellt wurde, verwenden Sie sie erneut, statt sie noch einmal zu erstellen.
Starten Sie in Terminal B den folgenden Consumer. Er wartet, bis er drei Datensätze gelesen hat, und beendet sich dann automatisch. --from-beginning fordert für diesen neuen Consumer den gespeicherten Anfang an. --max-messages 3 begrenzt die Anzahl der Nachrichten, und --timeout-ms 30000 begrenzt die Wartezeit ohne neue Nachrichten. Die Pipe leitet die reguläre Ausgabe an tee weiter, das sie anzeigt und eine lokale Kopie speichert:
## Terminal B
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-first --from-beginning --max-messages 3 --timeout-ms 30000 | tee /home/labex/project/output/received-events.txt
Lassen Sie Terminal B warten. Wechseln Sie zu Terminal A und senden Sie den Stapel innerhalb der Wartefrist von 30 Sekunden. Falls diese Frist abläuft, bevor Sie etwas senden, starten Sie denselben Consumer-Befehl in Terminal B erneut und wechseln Sie dann zum Senden zurück. Wenn Sie die Ereignisse bereits gesendet haben, führen Sie nur den Consumer erneut aus, um die drei gespeicherten Datensätze zu untersuchen. Ein erneutes Senden des Producer-Stapels würde Duplikate anhängen:
## Terminal A
printf '%s\n' 'order-1001 created' 'order-1002 created' 'order-1001 paid' | kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-first
printf gibt jeden in Anführungszeichen stehenden Textwert mit einem nachfolgenden Zeilenumbruch aus. Die Pipe führt diese Zeilen dem Producer zu; dieser Konsolenproducer behandelt jede Zeile als einen Ereignisdatensatz. Wenn printf fertig ist, schließt sich sein Eingabestrom. Daher schließt der Producer die ausstehenden Sendevorgänge ab und beendet sich. Sie müssen nichts in eine interaktive Producer-Eingabeaufforderung eingeben.
Kehren Sie zu Terminal B zurück. Seine drei Datenzeilen sollten wie folgt aussehen:
order-1001 created
order-1002 created
order-1001 paid
Im Terminal können zusätzlich eine Anzahl verarbeiteter Nachrichten oder Clientdiagnosen erscheinen. Die gespeicherte Datei sollte die drei Ereigniswerte enthalten. Die beiden Fakten zu order-1001 sind getrennte Datensätze; das paid-Ereignis hat das frühere created-Ereignis nicht überschrieben.
Der Consumer kehrt normalerweise nach drei Nachrichten zu seiner Eingabeaufforderung zurück. Falls Sie versehentlich einen unbegrenzten Client starten, beendet Strg-C diesen Client in seinem eigenen Terminal. Der Broker wird dadurch nicht beendet und das Topic nicht gelöscht. Hier sorgen die Begrenzungen dafür, dass der normale Ablauf ohne manuelle Unterbrechung endet.
Lesen Sie die gespeicherten Ereignisse mit einem neuen Consumer
In diesem Schritt prüfen Sie, ob das Lesen die Ereignisse entfernt hat. Der erste Consumer ist beendet. Überlegen Sie, was ein neuer unabhängiger Consumer sehen sollte, der am gespeicherten Anfang beginnt: dieselben drei Datensätze.
Führen Sie in Terminal B einen neuen begrenzten Consumer aus und speichern Sie diesen zweiten Lesevorgang separat:
## Terminal B
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-first --from-beginning --max-messages 3 --timeout-ms 30000 | tee /home/labex/project/output/replayed-events.txt
Erwarten Sie innerhalb dieser einzelnen Partition dieselben drei Werte in derselben Reihenfolge. Sie haben keinen weiteren Stapel gesendet. Untersuchen Sie beide lokalen Beobachtungen von Terminal A aus:
## Terminal A
cat /home/labex/project/output/received-events.txt
## Terminal A
cat /home/labex/project/output/replayed-events.txt
Beide Dateien sollten alle drei ursprünglichen Ereignisse enthalten. Konsumieren und Speicheraufbewahrung sind getrennte Vorgänge: Das Lesen entfernt keinen Datensatz aus dem Topic. Dieses erste Experiment verwendet neue Konsolenconsumer. Später lernen Sie, wie eine benannte Consumer-Gruppe ihren Lesefortschritt speichert und warum eine Option zum Lesen ab dem Anfang keine bereits festgeschriebene gültige Position überschreibt.
Kafka hielt den Ereignisverlauf weiterhin verfügbar, nachdem beide kurzlebigen Clients beendet waren. Als Nächstes untersuchen Sie Topiceigenschaften und sehen, wie die Aufbewahrungskonfiguration die Speicherrichtlinie unabhängig vom Consumer-Fortschritt beeinflusst.
Zusammenfassung
Sie haben Kafkas Rolle bei der Ereignisübermittlung kennengelernt, ein Topic mit einer Partition erstellt und beobachtet, wie getrennte Producer- und Consumer-Clients drei Bestellereignisse austauschen. Ein neuer Consumer las denselben gespeicherten Verlauf, nachdem der erste beendet war. Damit haben Sie gesehen, dass Lesen und Löschen unterschiedliche Vorgänge sind. Als Nächstes untersuchen Sie die Partitions-, Replikat- und Aufbewahrungseigenschaften eines Topics.
