Einführung
Beim Konsumieren von Streaming-Daten ist es ein grundlegendes Ziel, die Verbindungszeit zu maximieren und alle passenden Daten zu empfangen. Das bedeutet, dass es wichtig ist, redundante Verbindungen zu nutzen, Verbindungsabbrüche automatisch zu erkennen, schnell erneut zu verbinden und einen Plan zur Wiederherstellung verlorener Daten zu haben. In diesem Integrationsleitfaden besprechen wir verschiedene Funktionen für Wiederherstellung und Redundanz: redundante Verbindungen, Backfill und Recovery. Redundante Verbindungen Eine redundante Verbindung ermöglicht es Ihnen, mehrere gleichzeitige Verbindungen zum Filtered stream herzustellen. Dies schafft Redundanz, indem Sie mit zwei separaten Consumer-Instanzen mit demselben Stream verbunden sind und über beide Verbindungen dieselben Daten erhalten. So verfügt Ihre App über ein Hot-Failover für verschiedene Situationen, etwa wenn ein Stream getrennt wird oder wenn der primäre Server Ihrer Anwendung ausfällt. Der Filtered stream erlaubt derzeit nur Projects mit Enterprise-Zugang, bis zu zwei redundante Verbindungen herzustellen. Um einen redundanten Stream zu nutzen, stellen Sie einfach eine Verbindung zu derselben URL her, die für Ihre primäre Verbindung verwendet wird. Die data für Ihren Stream wird über beide Verbindungen gesendet.Wiederherstellung verpasster Daten nach einer Unterbrechung: Backfill
Nachdem Sie eine Unterbrechung erkannt haben, sollte Ihr System in der Lage sein, die Verbindung zum Stream wiederherzustellen. Wenn möglich, sollte Ihr System festhalten, wie lange die Unterbrechung gedauert hat, damit Sie die passende Wiederherstellungsfunktion zum Backfill der Daten verwenden können. Wenn Sie ein Project mit Enterprise-Zugang verwenden und festgestellt haben, dass die Unterbrechung fünf Minuten oder weniger dauerte, können Sie den Backfill-Parameter backfill_minutes nutzen. Wenn Sie diesen Parameter mit Ihrer GET /tweets/search/stream-Anfrage übergeben, erhalten Sie die Posts, die in den vergangenen ein bis fünf Minuten mit Ihren Regeln übereinstimmen. In der Regel liefern wir diese älteren Posts zuerst aus, noch bevor neu übereinstimmende Posts eintreffen, und wir deduplizieren Posts nicht. Das bedeutet: Wenn Sie 90 Sekunden getrennt waren, aber zwei Minuten Backfill-Daten anfordern, erhalten Sie 30 Sekunden lang doppelte Posts, gegen die Ihr System tolerant sein sollte. Hier ist ein Beispiel, wie eine Anfrage mit dem Backfill-Parameter aussehen könnte:curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN"
Wenn Sie keinen Enterprise-Zugang haben oder festgestellt haben, dass die Unterbrechung länger als fünf Minuten dauerte, können Sie den recent search endpoint oder die Recovery-Funktion nutzen, um verpasste Daten anzufordern. Beachten Sie jedoch, dass die Search-Posts-endpoints die Operatoren sample:, bio:, bio_name: oder bio_location: nicht unterstützen und bei der Verwendung von Akzenten und Diakritika mit den keyword- und #hashtag-Operatoren bestimmte Unterschiede im Matching-Verhalten aufweisen. Diese Unterschiede können bedeuten, dass Sie nicht alle Posts vollständig wiederherstellen, die möglicherweise über die Filtered stream-endpoints empfangen worden wären.
Wiederherstellung verpasster Daten nach einer Unterbrechung: Recovery
Wenn Sie ein Project mit Enterprise-Zugang verwenden, können Sie die Recovery-Funktion nutzen, um verpasste Daten innerhalb der letzten 24 Stunden wiederherzustellen, falls Sie innerhalb des 5‑Minuten-Backfill-Fensters nicht erneut verbinden können.
Die Streaming-Recovery-Funktion ermöglicht ein erweitertes Backfill-Fenster von 24 Stunden. Recovery ermöglicht es Ihnen, den Zeitraum der verpassten Daten „wiederzugeben“. Ein Recovery-Stream wird gestartet, wenn Sie eine Verbindungsanfrage mit den Request-Parametern ‘start_time’ und ‘end_time’ stellen. Sobald die Verbindung hergestellt ist, streamt Recovery den angegebenen Zeitraum erneut und trennt anschließend die Verbindung.
Sie können bis zu 2 gleichzeitige Anfragen an Recovery stellen, d. h. „zwei Recovery-Jobs“. Technisch funktioniert Recovery auf die gleiche Weise wie Backfill, außer dass eine Start- und Endzeit definiert ist. Ein Recovery-Zeitraum bezieht sich auf einen einzelnen Zeitbereich.
| Name | Type | Description |
| start_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Datum in UTC, das die Startzeit für die Wiederherstellung angibt. |
| end_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Datum in UTC, das die Endzeit angibt, bis zu der wiederhergestellt wird. |