Einführung
Mehrere Ereignisse können dieselbe Bestellung beschreiben: erstellt, bezahlt und versandt. Wenn zusammengehörige Datensätze konsistent weitergeleitet werden, kann ein Consumer die Abfolge dieser Bestellung innerhalb einer Partition verfolgen. Ein Datensatzschlüssel liefert eine stabile Eingabe für die Weiterleitung. Er unterscheidet sich von einer event_id, die ein einzelnes Ereignisvorkommnis identifiziert.
Sie veröffentlichen verschachtelte Ereignisse für drei Bestellungen in einem Topic mit drei Partitionen, geben ihre tatsächlichen Schlüssel und Positionen aus und fügen ein weiteres Ereignis für eine vorhandene Bestellung hinzu. Ein Offset ist die Position eines Datensatzes innerhalb einer Partition. Offsets sind keine globalen Zeilennummern des Topics, und für Datensätze aus verschiedenen Partitionen gibt es keine einzige garantierte globale Reihenfolge.
Der Broker und die Eingabedatei sind unabhängig vorbereitet. Grundlegende Terminalkenntnisse reichen aus. Die Ereigniswerte verwenden lesbaren JSON-Text. Python, JSON-Programmierung, Clusterkonfiguration oder ein Topiczustand aus früheren Aktivitäten sind nicht erforderlich. Behalten Sie die Partitionsanzahl und die Weiterleitungsstrategie des Clients während des gesamten Experiments bei. Verwenden Sie das Terminal.
Veröffentlichen Sie verschachtelte Ereignisse mit einem Bestellschlüssel
In diesem Schritt senden Sie eine stabile Bestellkennung als Schlüssel und behalten das vollständige Ereignis als Wert bei. Untersuchen Sie den bereitgestellten Stapel mit fünf Datensätzen:
cd /home/labex/project
cat /home/labex/project/data/keyed-orders.txt
Jede Zeile hat die Form key|value. Der Schlüssel ist eine Bestellkennung. Der JSON-Wert verwendet benannte Felder in geschweiften Klammern: event_id ist eindeutig, order_id stimmt mit dem Schlüssel überein, sequence ist die fachliche Abfolgenummer dieser Bestellung und event_type beschreibt das Vorkommnis. JSON-Text ist das Format des Werts; Kafka interpretiert ihn nicht automatisch als Tabellenschema.
Erstellen Sie ein Topic mit drei Partitionen und einem Replikat:
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-keyed --partitions 3 --replication-factor 1
Die Optionen --reader-property des Producers konfigurieren, wie er Eingabezeilen interpretiert. parse.key=true und key.separator=| teilen jede Eingabezeile am Trennzeichen auf. Das Trennzeichen selbst wird weder Teil des Schlüssels noch des Werts. Das Zeichen < der Shell führt die Datei als Standardeingabe zu, und der Producer beendet sich nach dem Senden seiner begrenzten Eingabe:
kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-keyed --reader-property parse.key=true --reader-property 'key.separator=|' < /home/labex/project/data/keyed-orders.txt
Die Datei verschachtelt Bestellungen, sodass die Ereignisse für order-2001 in der Eingabe nicht direkt aufeinanderfolgen. Bei derselben schlüsselbasierten Weiterleitungsstrategie und unveränderter Partitionsanzahl gelangen gleiche Schlüssel in dieselbe Partition. Verschiedene Schlüssel können sich eine Partition teilen; drei Bestellungen garantieren keine drei verschiedenen Partitionsnummern.
Veröffentlichen Sie diesen bereitgestellten Stapel mit fünf Datensätzen nur einmal. Ein wiederholter Consumer-Lesevorgang dient der Untersuchung; ein erneutes Ausführen dieses Producer-Befehls hängt fünf weitere Datensätze an. Wenn Sie nach der Veröffentlichung fortfahren, setzen Sie mit der Consumer-Untersuchung fort, statt die Datei erneut zu senden.
Sie haben die Eingabe für die Weiterleitung geliefert, statt manuell eine Partitionsnummer auszuwählen. Als Nächstes lesen Sie die tatsächlichen Weiterleitungsentscheidungen ab, anstatt sie zu erraten.
Untersuchen Sie Schlüssel, Partitionen und Offsets gemeinsam
In diesem Schritt zeigen Sie zu jedem Wert die Datensatzmetadaten an. Die Optionen --formatter-property des Konsolenconsumers steuern die Darstellung und ergänzen die reguläre Ausgabe um Schlüssel, Partition und Offset. Sie verändern den gespeicherten Ereignisinhalt nicht. Die Option zum Lesen ab dem Anfang für diesen neuen Consumer, die Begrenzung auf fünf Nachrichten und die Wartefrist ohne neue Nachrichten machen diese begrenzte Untersuchung wiederholbar. Speichern Sie die Ausgabe lokal:
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-keyed --from-beginning --max-messages 5 --timeout-ms 30000 --formatter-property print.key=true --formatter-property print.partition=true --formatter-property print.offset=true > /home/labex/project/output/keyed-first.txt
cat /home/labex/project/output/keyed-first.txt
Jede Datenzeile sollte Felder in dieser allgemeinen Form mit tatsächlichen Zahlen und einem vollständigen JSON-Wert zeigen:
Partition:... Offset:... order-... {"event_id":"...",...}
Die Trennzeichen sind Tabulatoren. Suchen Sie k1 und k3: Beide haben den Schlüssel order-2001 und sollten dieselbe Partition haben, wobei k3 einen größeren Offset besitzt. Ebenso sollten k2 und k4 dieselbe Partition für order-2002 haben. Setzen Sie nicht voraus, dass diese beiden Bestellungen unterschiedliche Partitionen verwenden.
Offsets gehören zur Partition, nicht zum Schlüssel. Wenn andere Schlüssel dieselbe Partition nutzen, können zwischen aufeinanderfolgenden Offsets einer Bestellung Lücken liegen. Das Feld sequence im Nutzdateninhalt ist ein Anwendungswert; Kafka hat es nicht als Offset erzeugt.
Der Consumer kann Datensätze aus verschiedenen Partitionen verschachtelt ausgeben. Deshalb muss die globale Anzeigereihenfolge nicht mit der Producer-Datei übereinstimmen. Prüfen Sie zusammengehörige Ereignisse anhand ihres Schlüssels, ihrer Partition und ihrer steigenden Offsets, statt die Ausgabe als eine global geordnete Liste zu behandeln.
Fügen Sie ein weiteres Ereignis für eine vorhandene Bestellung hinzu
In diesem Schritt testen Sie dieselbe Weiterleitungsregel mit einem weiteren Producer-Aufruf. Überlegen Sie, was mit dem shipped-Ereignis von order-2001 geschehen sollte: Es sollte in die bereits verwendete Partition dieser Bestellung gelangen und dort auf deren frühere Datensätze folgen. Sein genauer Offset hängt von anderen Datensätzen ab, die dieselbe Partition nutzen.
Das printf-Muster aus dem ersten Kafka-Lab sendet eine vollständige Zeile mit Schlüssel an den Konsolenproducer mit denselben Einstellungen:
printf '%s\n' 'order-2001|{"event_id":"k6","order_id":"order-2001","sequence":3,"event_type":"shipped"}' | kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-keyed --reader-property parse.key=true --reader-property 'key.separator=|'
Lesen Sie alle sechs gespeicherten Datensätze und speichern Sie eine neue Beobachtung:
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-keyed --from-beginning --max-messages 6 --timeout-ms 30000 --formatter-property print.key=true --formatter-property print.partition=true --formatter-property print.offset=true > /home/labex/project/output/keyed-with-shipped.txt
cat /home/labex/project/output/keyed-with-shipped.txt
Suchen Sie k6 mit order-2001 und sequence 3. Vergleichen Sie seine Partition mit der von k1 und k3 und seinen Offset mit deren Offsets. Die Ereignisfolge der Bestellung sollte in der Reihenfolge der Partitionsoffsets weiterhin created, paid, shipped lauten. Eine feste Partitionsnummer ist nicht erforderlich.
Die ursprüngliche Beobachtung mit fünf Datensätzen bleibt in keyed-first.txt erhalten. Der neue Producer hat ein Ereignis angehängt, statt die früheren zu ersetzen. Die Partitionsanzahl des Topics und die Weiterleitungsstrategie können die Zuordnung beeinflussen. Deshalb ändert dieses Experiment bewusst keine der beiden Größen. Spätere Clients müssen eine kompatible Weiterleitungsstrategie wählen, wenn sie über verschiedene Implementierungen hinweg dieselbe Zuordnung benötigen.
Sie haben nun Belege für eine stabile Weiterleitung je Schlüssel und eine Reihenfolge innerhalb einer Partition, ohne eine globale Ereignisreihenfolge oder eine Partition pro Bestellung anzunehmen. Die nächste Challenge wendet dieselben Kenntnisse zu Topics, Aufbewahrung und Veröffentlichung mit Schlüsseln auf einen neuen Stapel an.
Zusammenfassung
Sie haben Bestellschlüssel angegeben, tatsächliche Partitionen und Offsets untersucht und geprüft, dass ein angehängtes Ereignis unter derselben Weiterleitungsregel auf die früheren Datensätze seiner Bestellung folgte. Sie haben Ereignis-IDs, Bestellschlüssel, die Abfolgenummer im Nutzdateninhalt und Partitionsoffsets unterschieden, ohne eine globale Reihenfolge anzunehmen. Als Nächstes verbindet eine Challenge mit einem neuen Stapel diese Kenntnisse mit der Konfiguration der Topicaufbewahrung.
