Introduction
Lors de la consommation de données en continu, maximiser votre temps de connexion et recevoir toutes les données correspondantes est un objectif fondamental. Il est donc important de tirer parti des connexions redondantes, de détecter automatiquement les déconnexions, de se reconnecter rapidement et de disposer d’un plan pour récupérer les données perdues. Dans ce guide d’intégration, nous aborderons différentes fonctionnalités de récupération et de redondance : connexions redondantes, backfill et reprise. Connexions redondantes Une connexion redondante vous permet simplement d’établir plusieurs connexions simultanées au flux filtré. Cela offre une redondance en vous permettant de vous connecter au même stream avec deux consommateurs distincts, et de recevoir les mêmes données via les deux connexions. Ainsi, votre App bénéficie d’un basculement à chaud dans diverses situations, par exemple si un stream est déconnecté ou si le serveur principal de votre application tombe en panne. Le flux filtré permet actuellement uniquement aux Projects disposant d’un accès Enterprise d’établir jusqu’à deux connexions redondantes. Pour utiliser un stream redondant, connectez‑vous simplement à la même URL que celle utilisée pour votre connexion principale. Les data de votre stream seront envoyées via les deux connexions.Récupération des données manquées après une déconnexion : Backfill
Après avoir détecté une déconnexion, votre système doit être capable de se reconnecter au stream. Si possible, il doit noter la durée de la déconnexion afin que vous puissiez utiliser la fonctionnalité de récupération appropriée pour reconstituer les données. Si vous utilisez un Project avec un accès Enterprise et avez constaté que la déconnexion a duré cinq minutes ou moins, vous pouvez utiliser le paramètre de backfill, backfill_minutes. Si vous transmettez ce paramètre avec votre requête GET /tweets/search/stream, vous recevrez les Posts correspondant à vos règles sur les une à cinq dernières minutes. Nous livrons généralement ces Posts plus anciens en premier, avant tout nouveau Post correspondant, et nous ne dédupliquons pas les Posts. Ainsi, si vous avez été déconnecté pendant 90 secondes mais demandez deux minutes de backfill, vous recevrez 30 secondes de Posts en double, ce que votre système doit savoir tolérer. Voici un exemple de requête avec le paramètre de backfill :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 constaté que la déconnexion a duré plus de cinq minutes, vous pouvez utiliser l’endpoint de recherche récente ou la fonctionnalité de récupération pour demander les données manquées. Notez toutefois que les endpoints de recherche de Posts 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 des accents et des diacritiques avec les opérateurs keyword et #hashtag. Ces différences peuvent faire que vous ne récupériez pas intégralement tous les Posts qui auraient pu être reçus via les endpoints du flux filtré.
Récupération des données manquées après une déconnexion : Recovery
Si vous utilisez un Project avec un accès Enterprise, vous pouvez utiliser la fonctionnalité Recovery pour récupérer les données manquées au cours des dernières 24 heures si vous ne parvenez pas à vous reconnecter dans la fenêtre de backfill de 5 minutes.
La fonctionnalité de récupération en streaming vous permet de disposer d’une fenêtre de backfill étendue à 24 heures. Recovery vous permet de « rejouer » la période de données manquées. Un flux de récupération démarre lorsque vous effectuez une demande de connexion en utilisant les paramètres de requête ‘start_time’ et ‘end_time’. Une fois connecté, Recovery re-diffuse la période indiquée, puis se déconnecte.
Vous pouvez effectuer 2 requêtes de récupération simultanées, c’est‑à‑dire « deux jobs de récupération ». Recovery fonctionne techniquement de la même manière que le backfill, à ceci près qu’une heure de début et une heure de fin sont définies. Une période de récupération correspond à une seule plage temporelle.
| 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. |