Reprise et redondance

​

Introduction

Lorsque vous consommez des données en streaming, maximiser votre temps de connexion et recevoir toutes les données correspondantes est un objectif fondamental. Cela signifie qu’il est important de tirer parti des connexions redondantes, de détecter automatiquement les déconnexions, de vous reconnecter rapidement et d’avoir un plan pour récupérer les données perdues.

Dans ce guide d’intégration, nous aborderons différentes fonctionnalités de redondance et de récupération : connexions redondantes, backfill et récupération.  

Connexions redondantes

Une connexion redondante vous permet simplement d’établir plus d’une connexion simultanée au flux filtré. Cela offre une redondance en vous permettant de vous connecter au même flux avec deux consommateurs distincts, qui reçoivent les mêmes données via les deux connexions. Ainsi, votre app dispose d’un basculement à chaud dans diverses situations, par exemple si un flux est déconnecté ou si le serveur principal de votre application tombe en panne.

Filtered stream n’autorise actuellement que les Projects disposant d’un accès Enterprise à établir jusqu’à deux connexions redondantes. Pour utiliser un flux redondant, connectez-vous simplement à la même URL que celle utilisée pour votre connexion principale. Les données de votre flux seront envoyées via les deux connexions.

​

Récupérer les données manquantes après une déconnexion : rattrapage (Backfill)

Après avoir détecté une déconnexion, votre système doit être suffisamment intelligent pour se reconnecter au flux. Si possible, votre système doit noter la durée de la déconnexion afin que vous puissiez utiliser la fonctionnalité de récupération appropriée pour effectuer un rattrapage des données. 

Si vous utilisez un Project avec accès Enterprise et que vous avez identifié que la déconnexion a duré cinq minutes ou moins, vous pouvez utiliser le paramètre de rattrapage, backfill_minutes. Si vous transmettez ce paramètre avec votre requête GET /tweets/search/stream, vous recevrez les Publications correspondant à vos règles survenues au cours des dernières une à cinq minutes. En général, nous transmettons d’abord ces Publications plus anciennes avant toute nouvelle Publication correspondante, et nous ne dédoublonnons pas non plus les Publications. Cela signifie que si vous avez été déconnecté pendant 90 secondes, mais que vous demandez deux minutes de données de rattrapage, vous recevrez 30 secondes de Publications en double, que votre système doit être capable de tolérer. Voici un exemple de ce à quoi pourrait ressembler une requête avec le paramètre de rattrapage :

curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN"

Si vous n’avez pas d’accès Enterprise, ou si vous avez identifié que la déconnexion a duré plus de cinq minutes, vous pouvez utiliser le recent search endpoint ou la fonctionnalité de récupération pour demander les données manquantes. Cependant, notez que les endpoints de recherche de Publications n’incluent pas les opérateurs sample:, bio:, bio_name: ou bio_location:, et présentent certaines différences de comportement de correspondance lors de l’utilisation d’accents et de signes diacritiques avec les opérateurs de mots-clés et #hashtag. Ces différences peuvent faire en sorte que vous ne récupériez pas entièrement toutes les Publications qui auraient pu être reçues via les endpoints de flux filtrés. 

Récupérer les données manquantes après une déconnexion : Recovery

Si vous utilisez un Project avec accès Enterprise, vous pouvez utiliser la fonctionnalité Recovery pour récupérer les données manquantes au cours des 24 dernières heures si vous ne parvenez pas à vous reconnecter dans la fenêtre de rattrapage de 5 minutes.

La fonctionnalité de récupération de streaming vous permet de disposer d’une fenêtre de rattrapage étendue de 24 heures. Recovery vous permet de « rejouer » la période correspondant aux données manquantes. Un flux de récupération est démarré lorsque vous effectuez une requête de connexion en utilisant les paramètres de requête start_time et end_time. Une fois connecté, Recovery va rediffuser la période indiquée, puis se déconnecter.  

Vous pourrez effectuer 2 requêtes simultanées vers Recovery en même temps, c’est‑à‑dire « deux tâches de récupération ». Recovery fonctionne techniquement de la même manière que le rattrapage, sauf qu’une heure de début et de fin est définie. Une période de récupération correspond à un seul intervalle de temps.

Name	Type	Description
start_time	date (ISO 8601)	YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Date en UTC indiquant l’heure de début à partir de laquelle récupérer.
end_time	date (ISO 8601)	YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Date en UTC indiquant l’heure de fin jusqu’à laquelle récupérer.

Exemple d’URL de requête : https://api.x.com/2/tweets/search/stream?start_time=2022-07-12T15:10:00Z&end_time=2022-07-12T15:20:00Z