Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Umgang mit Startup, Herunterfahren und Drosselung
Nachfolgend einige Überlegungen, die Sie in das Design Ihrer Amazon Kinesis Data Streams einfließen lassen sollten.
Inhalt
Starten von Datenproduzenten und Datenkonsumenten
Standardmäßig beginnt die KCL am vorderen Ende des Streams mit dem Lesen von Datensätzen, also mit dem zuletzt hinzugefügten Datensatz. Wenn bei dieser Konfiguration eine datenproduzierende Anwendung Datensätze zum Stream hinzufügt, ehe empfangsbereite Datensatzprozessoren ausgeführt werden, werden diese Datensätze nach dem Start der Datensatzprozessoren nicht gelesen.
Damit Datenprozessoren immer am Anfang des Streams mit dem Lesen beginnen, legen Sie den folgenden Wert in der Eigenschaftendatei Ihrer Amazon Kinesis Data Streams fest:
initialPositionInStream = TRIM_HORIZON
Standardmäßig speichert Amazon Kinesis Data Streams alle Daten für 24 Stunden. Er unterstützt auch eine erweiterte Aufbewahrung von bis zu 7 Tagen und die langfristige Aufbewahrung von bis zu 365 Tagen. Dieser Zeitrahmen wird als Aufbewahrungszeitraum bezeichnet. Wenn Sie die Startposition auf TRIM_HORIZON festsetzen, beginnt der Datensatzprozessor entsprechend des definierten Aufbewahrungszeitraums mit den ältesten Daten. Wenn ein Datensatzprozessor nach Ablauf des Aufbewahrungszeitraums gestartet wird, sind trotz TRIM_HORIZON-Einstellung einige der Datensätze aus dem Stream nicht mehr verfügbar. Aus diesem Grund sollten Sie Konsumentenanwendungen immer Daten aus dem Stream lesen lassen und mit der CloudWatch-Metrik GetRecords.IteratorAgeMilliseconds überwachen, ob die Anwendungen dem eigehenden Datenvolumen gerecht werden.
In einigen Fällen mag es unerheblich sein, wenn Datensatzprozessoren die ersten Datensätze im Stream auslassen. Sie können beispielsweise einige erste Datensätze durch den Stream schicken, um zu testen, ob die Ende-zu-Ende-Verarbeitung wie erwartet funktioniert. Nach dieser anfänglichen Verifizierung starten Sie dann die Auftragnehmer und beginnen mit der Einleitung von Produktionsdaten in den Stream.
Weitere Informationen zur TRIM_HORIZON-Einstellung finden Sie unter Verwenden von Shard-Iteratoren.
Herunterfahren einer Amazon-Kinesis-Daten-Streams-Anwendung
Wenn Ihre Anwendung für Amazon Kinesis Data Streams die beabsichtigten Aufgaben abgeschlossen hat, sollten Sie sie herunterfahren, indem Sie die EC2-Instances beenden, auf denen sie ausgeführt wird. Sie können die Instances über die AWS Management Console
Nach dem Herunterfahren der Anwendung für Amazon Kinesis Data Streams sollten Sie die Amazon DynamoDB-Tabelle löschen, mit der die KCL den Anwendungsstatus verfolgt hat.
Drosselung bei Lesevorgängen
Der Durchsatz eines Streams wird auf Shard-Ebene bereitgestellt. Jeder Shard hat einen Lesedurchsatz von bis zu 5 Transaktionen pro Sekunde für Lesevorgänge, bis zu einer maximalen Gesamtdatenleserate von 2 MB pro Sekunde. Wenn eine Anwendung (oder eine Gruppe von Anwendungen im selben Stream) versucht, Daten schneller aus einem Shard abzurufen, drosselt Kinesis Data Streams die entsprechenden GET-Operationen.
Wenn in einer Amazon Kinesis Data Streams ein Datensatzprozessor Daten schneller als das Limit verarbeitet, beispielsweise bei einem Ausfall, kommt es zu einem Failover. Da die KCL die Interaktionen zwischen der Anwendung und Kinesis Data Streams verwaltet, treten Ablehnungsausnahmen im Code der KCL und nicht im Anwendungscode auf. Da die KCL diese Ausnahmen jedoch protokolliert, sind sie in den Protokollen zu sehen.
Wenn Sie feststellen, dass Ihre Anwendung permanent gedrosselt wird, sollten Sie eine Erhöhung der Shards für diesen Stream in Betracht ziehen.
