Streaming-Daten konsumieren

​

Entwickeln eines Clients zum Verbrauch von Streaming-Daten

Bei der Verwendung eines Streaming-endpoints gibt es einige allgemeine Best Practices, die Sie zur Optimierung der Nutzung berücksichtigen sollten.    

​

Client-Design

Beim Erstellen einer Lösung mit dem Filter-Stream-endpoint benötigen Sie einen Client, der Folgendes kann:

1. Eine HTTPS-Streaming-Verbindung zum Filter-Stream-endpoint herstellen.
2. Asynchron POST-Anfragen an den Filter-Stream-Rules-endpoint senden, um dem Stream Regeln hinzuzufügen und zu löschen.
3. Geringe Datenvolumina verarbeiten – die Streaming-Verbindung aufrechterhalten, Post-Objekte und Keep-Alive-Signale erkennen.
4. Hohe Datenvolumina verarbeiten – die Stream-Erfassung mithilfe asynchroner Prozesse von der weiteren Verarbeitung entkoppeln und sicherstellen, dass clientseitige Puffer regelmäßig geleert werden.
5. Die Nachverfolgung des Volumenverbrauchs clientseitig verwalten.
6. Stream-Trennungen erkennen, bewerten und automatisch die Verbindung zum Stream wiederherstellen.  

​

Verbindung mit einem Streaming-endpoint

Eine Verbindung zu X API v2 Streaming-endpoints herzustellen bedeutet, eine sehr langlebige HTTP-Anfrage zu stellen und die Antwort fortlaufend zu verarbeiten. Konzeptionell können Sie sich das wie das Herunterladen einer unendlich langen Datei über HTTP vorstellen. Sobald eine Verbindung hergestellt ist, liefert der X-Server Post-Ereignisse über die Verbindung, solange sie geöffnet bleibt.  

​

Daten konsumieren

Beachten Sie, dass die einzelnen fields von JSON-Objekten nicht geordnet sind und nicht in allen Fällen alle fields vorhanden sind. Ebenso werden separate Aktivitäten nicht in sortierter Reihenfolge geliefert, und doppelte Nachrichten können auftreten. Bedenken Sie, dass im Laufe der Zeit neue Nachrichtentypen hinzugefügt und über den Stream gesendet werden können.

Daher muss Ihr Client Folgendes tolerieren:

• fields in beliebiger Reihenfolge
• Unerwartete oder fehlende fields
• Nicht sortierte Posts
• Doppelte Nachrichten
• Neue, beliebige Nachrichtentypen, die jederzeit über den Stream eintreffen

Zusätzlich zu relevanten Post data und angeforderten field-Parametern können die folgenden Arten von Nachrichten über eine Stream-Verbindung geliefert werden. Beachten Sie, dass diese Liste möglicherweise nicht vollständig ist—zusätzliche Objekte können in Streams eingeführt werden. Stellen Sie sicher, dass Ihr Parser tolerant gegenüber unerwarteten Nachrichtenformaten ist.  

​

Buffering 

Die Streaming-endpoints senden data, sobald sie verfügbar sind, was häufig zu hohen Volumina führen kann. Wenn der X-Server nicht sofort neue data in den Stream schreiben kann (z. B. wenn Ihr Client nicht schnell genug liest; siehe handling disconnections für Details), puffert er die Inhalte serverseitig, damit Ihr Client aufholen kann. Ist dieser Puffer jedoch voll, wird eine erzwungene Trennung initiiert, die Verbindung wird beendet, und die gepufferten Posts werden verworfen und nicht erneut gesendet. Siehe unten für weitere Details.

Eine Möglichkeit, Zeiträume zu identifizieren, in denen Ihre App zurückliegt, besteht darin, den Zeitstempel der empfangenen Posts mit der aktuellen Uhrzeit zu vergleichen und dies über die Zeit zu verfolgen.

Obwohl Stream‑Backlogs aufgrund potenzieller Latenzen und Störungen im öffentlichen Internet nie vollständig vermieden werden können, lassen sie sich durch eine geeignete Konfiguration Ihrer App weitgehend reduzieren. Um das Auftreten von Backlogs zu minimieren:

• Stellen Sie sicher, dass Ihr Client den Stream schnell genug liest. In der Regel sollten Sie beim Lesen des Streams keine nennenswerte Verarbeitung durchführen. Lesen Sie den Stream und übergeben Sie die Arbeit an einen anderen Thread/Prozess/data store, um Ihre Verarbeitung asynchron auszuführen.
• Stellen Sie sicher, dass Ihr Rechenzentrum über ausreichende eingehende Bandbreite verfügt, um große, anhaltende Datenvolumina sowie deutlich größere Spitzen (z. B. das 5‑ bis 10‑Fache des normalen Volumens) zu bewältigen. Beim Filtered stream hängen das Volumen und die entsprechend auf Ihrer Seite benötigte Bandbreite vollständig davon ab, welche Posts Ihre Regeln matchen.  

​

Nutzungsüberwachung und Regelverwaltung

Da die Erwartungen von Entwicklerinnen und Entwicklern an das „normale“ Datenvolumen ihrer Streams variieren, geben wir keine allgemeine Empfehlung für einen bestimmten prozentualen Rückgang/Anstieg oder einen Zeitraum.

Überwachen Sie die Datenvolumina Ihres Streams auf unerwartete Abweichungen. Ein Rückgang des Datenvolumens kann auf ein anderes Problem hindeuten als eine Trennung vom Stream. In einem solchen Fall würde ein Stream weiterhin das Keep-Alive-Signal und vermutlich einige neue Aktivitätsdaten empfangen. Eine deutlich geringere Anzahl an Posts sollte Sie jedoch veranlassen zu prüfen, ob etwas den Rückgang des eingehenden Datenvolumens zu Ihrer Anwendung oder Ihrem Netzwerk verursacht, und die Statusseite auf entsprechende Hinweise zu kontrollieren.

Um eine solche Überwachung einzurichten, könnten Sie die Anzahl neuer Posts verfolgen, die Sie innerhalb eines festgelegten Zeitraums erwarten. Fällt das Datenvolumen eines Streams deutlich unter den angegebenen Schwellenwert und erholt sich nicht innerhalb eines festgelegten Zeitraums, sollten Alarme und Benachrichtigungen ausgelöst werden. Sie sollten zudem auf einen starken Anstieg des Datenvolumens achten, insbesondere wenn Sie gerade Regeln in einem Filtered stream ändern oder wenn ein Ereignis zu einem sprunghaften Anstieg der Post-Aktivität führt.

Wichtig: Über einen Filtered stream zugestellte Posts werden auf das gesamte monatliche Post-Volumen angerechnet; Sie sollten daher den Verbrauch überwachen und bei Bedarf anpassen, um zu optimieren. Ist das Volumen hoch, erwägen Sie, jeder Ihrer Regeln einen sample:-Operator hinzuzufügen, um die Trefferquote von 100 % auf sample:50 oder sample:25 zu reduzieren, wenn erforderlich.

Außerdem empfehlen wir, in Ihrer App Maßnahmen zu implementieren, die Ihr Team benachrichtigen, wenn das Volumen einen vordefinierten Schwellenwert überschreitet, sowie gegebenenfalls weitere Schritte einzuführen, etwa das automatische Löschen von Regeln, die zu viele Daten liefern, oder in extremen Fällen die vollständige Trennung vom Stream.  

​

Reagieren auf Systemmeldungen

Keep-alive-Signale Mindestens alle 20 Sekunden sendet der Stream ein Keep-alive-Signal (Heartbeat) in Form eines Wagenrücklaufs \r\n über die offene Verbindung, um zu verhindern, dass Ihr Client in einen Timeout läuft. Ihre Client-Anwendung sollte gegenüber den \r\n-Zeichen im Stream tolerant sein.

Wenn Ihr Client ordnungsgemäß einen Lese-Timeout in Ihrer HTTP-Bibliothek implementiert, kann sich Ihre App auf das HTTP-Protokoll und Ihre HTTP-Bibliothek verlassen, die ein Ereignis auslösen, wenn innerhalb dieses Zeitraums keine Daten gelesen werden. In diesem Fall müssen Sie nicht explizit auf das \r\n-Zeichen achten.

Dieses Ereignis ist in der Regel eine ausgelöste Ausnahme oder ein anderes Ereignis, abhängig von der verwendeten HTTP-Bibliothek. Es wird dringend empfohlen, Ihre HTTP-Methoden mit Fehler-/Ereignis-Handlern zu versehen, um diese Timeouts zu erkennen. Bei einem Timeout sollte Ihre Anwendung versuchen, die Verbindung wiederherzustellen.

Fehlermeldungen Die v2-Streaming-endpoints können auch Fehlermeldungen im Stream liefern. Unten ist das grundlegende Format dieser Meldungen zusammen mit einigen Beispielen aufgeführt. Bitte beachten Sie, dass sich die gelieferten Meldungen ändern können und neue Meldungen hinzukommen. Client-Anwendungen müssen gegenüber sich ändernden Systemmeldungs-Payloads tolerant sein.

Beachten Sie, dass Fehlermeldungen auf die Dokumentation verlinken, in der beschrieben ist, wie das Problem gelöst werden kann.

Nachrichtenformat:

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "Dieser Stream wurde aus betrieblichen Gründen vorgelagert getrennt.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

Beachten Sie, dass Fehlermeldungen, die eine erzwungene Trennung aufgrund eines vollen Puffers anzeigen, möglicherweise nie bei Ihrem Client ankommen, wenn die Stauung, die die erzwungene Trennung verursacht hat, deren Zustellung verhindert. Dementsprechend sollte Ihre App sich nicht auf diese Meldungen verlassen, um eine erneute Verbindung auszulösen.