Zum Hauptinhalt springen

​
Was ist eine Trennung?

Eine Verbindung zu den Streaming-APIs herzustellen bedeutet, eine sehr langfristige HTTPS-Anfrage zu senden und die Antwort fortlaufend zu verarbeiten. Beim Verbinden mit dem Filtered stream endpoint sollten Sie eine HTTPS-Anfrage senden und den resultierenden Stream so lange wie praktikabel verarbeiten. Unsere Server halten die Verbindung auf unbestimmte Zeit offen, außer bei serverseitigen Fehlern, übermäßiger clientseitiger Latenz, Netzwerkproblemen, routinemäßiger Serverwartung oder doppelten Anmeldungen. Bei Verbindungen zu Streaming-endpoints ist es wahrscheinlich und zu erwarten, dass Trennungen auftreten und eine Wiederverbindungslogik implementiert werden muss.  

​
Warum eine Streaming-Verbindung getrennt werden kann

Ihr Stream kann aus verschiedenen Gründen getrennt werden. Prüfen Sie die vom Stream zurückgegebene Fehlermeldung, um den Grund für den Ausfall zu verstehen. Mögliche Gründe für Trennungen sind:
  • Ein Authentifizierungsfehler (z. B. ein falsches Token oder eine falsche Authentifizierungsmethode).
  • Ein Streaming-Server wird auf der Seite von X neu gestartet. Dies hängt üblicherweise mit einem Code-Deployment zusammen und sollte grundsätzlich einkalkuliert werden.
  • Ihr Client hält mit dem Volumen der vom Stream gelieferten Posts nicht Schritt oder liest data zu langsam. Jede Streaming-Verbindung wird durch eine Nachrichtenwarteschlange gestützt, die an den Client gesendet wird. Wenn diese Warteschlange im Laufe der Zeit zu groß wird, wird die Verbindung geschlossen.
  • Ihr Konto hat Ihr tägliches/monatliches Kontingent an Posts überschritten.
  • Sie haben zu viele aktive, redundante Verbindungen.
  • Ein Client stellt das Lesen von data plötzlich ein. Wenn die Rate der aus dem Stream gelesenen Posts plötzlich stark abfällt, wird die Verbindung geschlossen.
  • Mögliche Netzwerkprobleme zwischen Server und Client
  • Ein vorübergehendes serverseitiges Problem, geplante Wartungsarbeiten oder Updates (siehe die Statusseite)  

​
Häufige Verbindungsunterbrechungsfehler umfassen:

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

{
	"title": "ConnectionException",
	"detail": "Dieser Stream hat derzeit die maximal zulässige Anzahl an Verbindungen erreicht.",
	"connection_issue": "TooManyConnections",
	"type": "https://api.x.com/2/problems/streaming-connection"
}

​
Verbindungsabbrüche antizipieren und erneut verbinden

Beim Streamen von Posts ist das Ziel, so lange wie möglich verbunden zu bleiben, wobei zu berücksichtigen ist, dass Verbindungsabbrüche auftreten können. Das endpoint sendet alle 20 Sekunden ein Keep-Alive-Heartbeat (erscheint als Zeilenumbruchzeichen). Nutzen Sie dieses Signal, um festzustellen, ob Sie getrennt werden.
  1. Ihr Code sollte erkennen, wenn keine neuen Inhalte und kein Heartbeat mehr eintreffen.
  2. In diesem Fall sollte Ihr Code eine Wiederverbindungslogik auslösen. Einige Clients und Sprachen erlauben das Festlegen eines Read-Timeouts, das Sie auf 20 Sekunden setzen können.
  3. Ihr Service sollte diese Abbrüche erkennen und so schnell wie möglich wieder verbinden.
Sobald eine bestehende Verbindung abbricht, versuchen Sie umgehend, sie wiederherzustellen. Schlagen Wiederverbindungsversuche fehl, drosseln Sie die weiteren Versuche entsprechend der Art des Fehlers:
  • Linear zurückfahren bei TCP/IP-Netzwerkfehlern. Diese Probleme sind in der Regel vorübergehend und beheben sich oft schnell. Erhöhen Sie die Verzögerung zwischen den Verbindungsversuchen bei jedem Versuch um 250 ms, bis maximal 16 Sekunden.
  • Exponentiell zurückfahren bei HTTP-Fehlern, bei denen ein Wiederverbinden sinnvoll ist. Beginnen Sie mit 5 Sekunden Wartezeit und verdoppeln Sie diese bei jedem Versuch, bis maximal 320 Sekunden.
  • Exponentiell zurückfahren bei HTTP 429-Fehlern Rate Limit überschritten. Beginnen Sie mit 1 Minute Wartezeit und verdoppeln Sie diese bei jedem Versuch. Beachten Sie, dass jede empfangene HTTP 429 die Wartezeit erhöht, bis die Rate Limit für Ihr Konto nicht mehr greift.  

​
Wiederherstellung verlorener Daten

Kommt es zu einer Unterbrechung, stehen Ihnen verschiedene Strategien zur Verfügung, um sicherzustellen, dass Sie alle möglicherweise verpassten Daten erhalten. In unserem Integrationsleitfaden zur Datenwiederherstellung haben wir zentrale Schritte dokumentiert, mit denen Sie verpasste Daten nachträglich abrufen können.   

​
Rate Limits und Nutzung

Zur Überprüfung von Verbindungsgrenzen werden in der Antwort drei Header zurückgegeben. Dies ist hilfreich, um zu verstehen, wie oft Sie das rule endpoint verwenden können und wie viele Wiederverbindungsversuche für das streaming endpoint zulässig sind.
  • x-rate-limit-limit gibt die Anzahl der zugewiesenen Anfragen an, die Ihr Client innerhalb des 15‑Minuten‑Fensters stellen darf.
  • x-rate-limit-remaining gibt die Anzahl der bisher im 15‑Minuten‑Fenster gestellten Anfragen an.
  • x-rate-limit-reset ist ein UNIX‑Zeitstempel, der angibt, wann das 15‑Minuten‑Fenster neu startet und x-rate-limit-remaining auf 0 zurückgesetzt wird.
Das filter stream endpoint meldet derzeit keine Nutzungsdaten. Um zu prüfen, wie viele Posts zugestellt wurden, kann Ihr Code eine Messlogik implementieren, sodass der Verbrauch gemessen und bei Bedarf pausiert werden kann. Ihr Code, der die Client-Seite des Streams hostet, fügt eingehende Posts einfach in eine First-in-First-out-(FIFO)-Warteschlange oder eine ähnliche Speicherstruktur ein; ein separater Prozess/Thread sollte Posts aus dieser Warteschlange entnehmen, um Inhalte zu parsen und für die Speicherung vorzubereiten. Mit diesem Design können Sie einen Dienst implementieren, der effizient skaliert, falls sich das Volumen eingehender Posts drastisch ändert. Konzeptionell können Sie es sich wie das Herunterladen einer unendlich langen Datei über HTTP vorstellen.

​
Bewährte Vorgehensweisen für die Wiederverbindung

Backoff-Strategien testen Eine gute Möglichkeit, eine Backoff-Implementierung zu testen, ist die Verwendung ungültiger Autorisierungsdaten und die Überprüfung der Wiederverbindungsversuche. Eine solide Implementierung erhält keine 429-Antworten. Warnmeldungen bei mehrfachen Wiederverbindungen Wenn ein Client seinen oberen Schwellenwert für die Zeit zwischen Wiederverbindungen erreicht, sollte er Ihnen Benachrichtigungen senden, damit Sie die Probleme, die Ihre Verbindung betreffen, priorisieren und beheben können. DNS-Änderungen berücksichtigen Testen Sie, ob Ihr Client-Prozess die DNS-Time-to-Live (TTL) beachtet. Einige Stacks cachen eine aufgelöste Adresse für die gesamte Laufzeit des Prozesses und übernehmen DNS-Änderungen nicht innerhalb der vorgegebenen TTL. Ein derart aggressives Caching führt zu Dienstunterbrechungen auf Client-Seite, wenn X die Last zwischen IP-Adressen verschiebt. User-Agent Stellen Sie sicher, dass Ihr User-Agent-HTTP-Header die Version des Clients enthält. Dies ist entscheidend für die Diagnose von Problemen auf Seiten von X. Falls Ihre Umgebung das Setzen des User-Agent-Felds nicht zulässt, setzen Sie stattdessen einen x-user-agent-Header.
⌘I