Platform For AI:Abonnement et push du service de file d'attente

L'abonnement et le push permettent d'envoyer immédiatement les données prêtes au client, réduisant ainsi la latence induite par l'interrogation via l'API Get et la charge sur le service de file d'attente générée par les requêtes. Toutefois, cette fonctionnalité présente une certaine complexité car elle implique de nombreux concepts supplémentaires. Cette rubrique décrit l'utilisation de la fonctionnalité d'abonnement et de push du service de file d'attente.

Consommateur

Un consommateur désigne un programme client qui s'abonne aux données du service de file d'attente. Lorsque le client appelle les données à l'aide de l'API Watch, un objet consommateur est créé dans le service de file d'attente. Les paramètres de l'API (tels que la taille de la fenêtre et les tags) servent d'attributs au consommateur. Vous pouvez consulter l'état du consommateur via l'API Attribute. Exemple :

[OK] Attributes: 
consumers.list.[0] : Id: default_group.u1, Index: 0, Pending: 0, Status: Complete, Idle: 2.091s, Window: 0, Slots: 0, AutoCommit: true
consumers.list.[1] : Id: default_group.u2, Index: 0, Pending: 0, Status: Complete, Idle: 1.124s, Window: 0, Slots: 0, AutoCommit: true
consumers.stats.total : 2

consumers.stats.total indique le nombre total de consommateurs. consumers.list correspond à la liste des consommateurs. Le tableau suivant décrit les colonnes :

Lors de l'utilisation de l'API Watch, si vous exécutez le tag de données, une colonne Tags supplémentaire apparaît. Exemple :

consumers.list.[0] : Id: ..., Pending: 0, ..., Window: ..., Tags: tags[foo=bar]

Cette colonne indique les tags de données auxquels le consommateur est abonné. Les données ne sont livrées au consommateur que si elles satisfont aux conditions spécifiées.

Groupe de consommateurs

Un groupe de consommateurs est un ensemble de consommateurs abonnés au service de file d'attente avec les mêmes conditions de filtrage. Les consommateurs d'un même groupe ne peuvent pas avoir le même nom, mais des consommateurs de groupes différents peuvent partager le même nom.

Au sein d'un même groupe de consommateurs, les données sont distribuées équitablement entre chaque consommateur. Entre différents groupes, les données sont poussées en parallèle aux consommateurs de chaque groupe. Par exemple :

• Les consommateurs d'un même groupe reçoivent des données différentes.

• Les consommateurs de groupes différents reçoivent les mêmes données.

Vous pouvez consulter l'état des consommateurs dans le service de file d'attente via l'API Attribute. Voici un exemple :

groups.list.[0] : Id: default_group, Index: 0, Pending: 0, Delivered: 0, Consumers: 1
groups.list.[1] : Id: group, Index: 0, Pending: 0, Delivered: 1, Consumers: 0

groups.list correspond à la liste des groupes de consommateurs. Le tableau suivant décrit les colonnes :

Le nombre de groupes de consommateurs n'est pas limité, mais ils ne sont pas nettoyés automatiquement. Après leur création, leur état est conservé.

Utilisation des consommateurs et des groupes de consommateurs

Vous pouvez déclarer le consommateur et le groupe de consommateurs via les en-têtes HTTP dans l'API Watch, ou lors de l'initialisation de votre client dans le SDK. Vous pouvez également obtenir la clé de l'en-tête HTTP à l'aide de l'API Attributes.

meta.header.group : X-EAS-QueueService-Gid
meta.header.user : X-EAS-QueueService-Uid

Déclarez respectivement l'ID du consommateur et l'ID du groupe de consommateurs auquel rejoindre via X-EAS-QueueService-Uid et X-EAS-QueueService-Gid.

Validation et rejet

Le service de file d'attente prend en charge deux méthodes de consommation : Commit et Negative. Toutes deux opèrent sur l'index des données, mais possèdent des sémantiques différentes.

• Commit indique que le consommateur a reçu les données et terminé leur traitement, permettant ainsi le push du lot suivant.

• Negative indique que le consommateur a reçu les données mais ne peut pas les traiter ; le service de file d'attente décide alors s'il doit pousser le lot suivant en fonction du code d'erreur. Vous pouvez déclarer la cause et le code d'erreur sous forme de texte en mode Negative, afin que les données soient poussées vers d'autres consommateurs. Le tableau suivant répertorie les codes d'erreur spéciaux que le service de file d'attente peut gérer :

  Code	Description
  Shutdown	Indique que le consommateur est en cours d'arrêt et que le service de file d'attente ne continue pas à pousser les données.

Rééquilibrage des données

Il se peut que vous ne puissiez pas valider les données dans les scénarios suivants :

• Lors d'une mise à jour progressive du service de prédiction, certains consommateurs sont arrêtés, ce qui entraîne un traitement des données impossible à valider.

• Une erreur interne survient et le consommateur plante.

• Le consommateur ne peut pas traiter les données reçues et exécute une validation Negative.

Ces données impossibles à traiter sont redistribuées à d'autres consommateurs par le service de file d'attente. Ce mécanisme est appelé rééquilibrage des données. Le rééquilibrage des données intervient dans les cas suivants :

• Tout consommateur passe à l'état Exit.

• Le consommateur ne reçoit pas de nouvelles données poussées alors que la fenêtre dispose d'espace libre.

Le service de file d'attente maintient un compteur de livraison pour chaque donnée. À chaque rééquilibrage et redistribution, ce compteur est incrémenté. Si, lors du processus de rééquilibrage, il est constaté que le compteur de livraison d'une donnée a dépassé le nombre maximal de livraisons, cette donnée est traitée comme une lettre morte. Le service de file d'attente applique alors la politique de lettres mortes configurée. Par défaut, les données sont livrées à la file d'attente de fin (tail queue).

File d'attente de fin

La file d'attente de fin est une file d'attente auxiliaire utilisée pour stocker les données non poussées aux consommateurs (telles que les lettres mortes ou les données de contrôle personnalisées). Il s'agit d'une instance de file d'attente au sein du service de file d'attente et elle dispose de la même API. Chaque file d'attente d'entrée et de sortie possède une file d'attente de fin.

Lors de l'appel à l'API, vous pouvez déclarer l'accès à la file d'attente de fin en ajoutant l'en-tête HTTP suivant :

X-EAS-QueueService-Access-Rear: true