Einführung
Ein Topic ist mehr als ein Name, den Sie einem Producer übergeben. Seine Partitionen strukturieren das Ereignisprotokoll, seine Replikate beschreiben gespeicherte Kopien und seine Aufbewahrungseinstellungen regeln, wie lange gespeicherte Datensätze aufbewahrt werden können. Der Lesefortschritt gehört zu den Consumern und ist davon unabhängig.
Sie erstellen zwei Topics, untersuchen ihre Metadaten, geben beiden eine explizite Aufbewahrungsrichtlinie und ändern anschließend nur eines davon. So können Sie die Bedeutung einer topicspezifischen Einstellung nachvollziehen, ohne auf eine tatsächliche Löschung zu warten oder die brokerweite Konfiguration zu ändern.
Der einzelne vorbereitete Broker ist einsatzbereit, und die beiden Topicnamen sind unabhängig von früheren Labs. Grundlegende Terminalkenntnisse reichen aus; Python- oder Java-Programmierung ist nicht erforderlich. Ein Replikat ist für diese Lernumgebung mit einem Broker geeignet. Verwenden Sie das Terminal.
Erstellen Sie zwei Topics und lesen Sie ihre Metadaten
In diesem Schritt vergleichen Sie zwei explizit festgelegte Partitionsanzahlen. Beginnen Sie in Ihrem Arbeitsverzeichnis:
cd /home/labex/project
--bootstrap-server gibt die Adresse des vorbereiteten Brokers an. Erstellen Sie orders-retained mit zwei Partitionen und orders-control mit einer Partition. Beide verwenden ein Replikat, da diese Umgebung einen Broker enthält:
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-retained --partitions 2 --replication-factor 1
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-control --partitions 1 --replication-factor 1
Listen Sie die Topics auf und speichern Sie jede Beschreibung. Das Zeichen > der Shell erstellt eine lokale Datei oder ersetzt ihren bisherigen Inhalt:
kafka-topics.sh --bootstrap-server localhost:9092 --list
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained > /home/labex/project/output/orders-retained-description.txt
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-control > /home/labex/project/output/orders-control-description.txt
cat /home/labex/project/output/orders-retained-description.txt
cat /home/labex/project/output/orders-control-description.txt
Suchen Sie PartitionCount: 2 beziehungsweise 1 sowie ReplicationFactor: 1 in beiden Beschreibungen. Jede Partition hat einen Leader-Eintrag. Die Kennung eines Leader-Brokers ist nicht die Partitionsanzahl, und zwei Partitionen bedeuten nicht zwei Brokerrechner.
Ein Topic kann mehrere Partitionen auf demselben Broker haben. Der Replikationsfaktor beschreibt Kopien jeder Partition auf verschiedenen Brokern, keine unabhängigen Kopien für jeden Consumer. Als Nächstes ändern Sie die Speicheraufbewahrung, ohne eine dieser beiden Eigenschaften zu verändern.
Legen Sie für jedes Topic eine explizite Aufbewahrung von einem Tag fest
In diesem Schritt unterscheiden Sie einen geerbten Standardwert von einer topicspezifischen Einstellung. kafka-configs.sh verwaltet Konfigurationsressourcen. --entity-type topics wählt Topicressourcen aus, während --entity-name das betroffene einzelne Topic festlegt. --describe zeigt normalerweise topicspezifische Einstellungen an; eine fehlende solche Einstellung bedeutet nicht, dass der Broker keinen Standardwert hat.
Untersuchen Sie das Topic orders-retained, bevor Sie es ändern:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe
retention.ms ist eine Dauer in Millisekunden. Ein Tag entspricht 24 × 60 × 60 × 1000 = 86400000 Millisekunden. --alter --add-config setzt die benannte Einstellung. Legen Sie dieselbe explizite Richtlinie unabhängig für beide Topics fest:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=86400000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --alter --add-config retention.ms=86400000
Lesen Sie die tatsächlich gesetzten topicspezifischen Einstellungen und speichern Sie die Beobachtungen:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-one-day-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-one-day-config.txt
cat /home/labex/project/output/retained-one-day-config.txt
cat /home/labex/project/output/control-one-day-config.txt
Suchen Sie retention.ms=86400000 für jedes benannte Topic. Ein Client kann auch Details zur Konfigurationsquelle oder zur Vertraulichkeit ausgeben; diese Angaben und die Formatierung können abweichen.
Die Aufbewahrung ist eine Speicherrichtlinie des Brokers, keine Anweisung, einen Datensatz sofort nach dem Lesen durch einen Consumer zu löschen. Das Alter der Datensätze und die Bereinigung von Protokollsegmenten bestimmen, wann eine Löschung möglich ist und stattfindet. Die Dauer ist keine Zusage, dass eine bestimmte Nachricht zu einem exakten Zeitpunkt verschwindet. Diese Übung prüft die konfigurierte Einstellung, statt auf die Bereinigung zu warten.
Ändern Sie nur ein Topic und prüfen Sie die Begrenzung
In diesem Schritt geben Sie orders-retained eine Aufbewahrung von zwei Tagen, während orders-control bei einem Tag bleibt. Überlegen Sie, welche Metadaten sich ändern sollten: die Aufbewahrungseinstellung des Topics orders-retained. Beide Partitionsanzahlen und Replikationsfaktoren bleiben unverändert.
Zwei Tage entsprechen 172800000 Millisekunden. Wenden Sie diesen Wert nur auf das benannte Topic orders-retained an:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=172800000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-final-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-final-config.txt
cat /home/labex/project/output/retained-final-config.txt
cat /home/labex/project/output/control-final-config.txt
Erwarten Sie retention.ms=172800000 für orders-retained und retention.ms=86400000 für orders-control. Die gemeinsame Brokeradresse macht eine topicspezifische Einstellung nicht global.
Rufen Sie die Beschreibung von orders-retained erneut ab:
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained
Das Topic sollte weiterhin zwei Partitionen und ein Replikat haben. Durch das Ändern der Aufbewahrung wurde kein neues Topic erstellt, keine Partition hinzugefügt, kein Consumer-Fortschritt kopiert und kein Ereignis konsumiert. Sie haben sowohl die beabsichtigte Änderung als auch das unveränderte benachbarte Topic geprüft. Als Nächstes verbinden Schlüssel die Identitäten von Bestellungen mit Partitionen.
Zusammenfassung
Sie haben Topics mit expliziten Partitionen und Replikaten erstellt, ihre Metadaten untersucht und Aufbewahrungseinstellungen in Millisekunden gesetzt. Die Änderung eines Topics ließ das andere unverändert. Damit haben Sie die Speicherrichtlinie eines Topics vom Consumer-Fortschritt abgegrenzt. Als Nächstes leiten Sie zusammengehörige Ereignisse mithilfe von Schlüsseln weiter und untersuchen ihre partitionslokalen Offsets.
