La documentation d'Event Grid indique qu'elle contient un mécanisme de remise et de nouvelle tentative intégré, et donne un exemple de ce qui pourrait être considéré comme une tentative réussie ou échouée. La documentation est très claire sur ce qui se passe avec un seul gestionnaire d'événements.
Ma question est la suivante: que se passe-t-il s'il existe plusieurs gestionnaires d'événements et qu'un seul gestionnaire ne parvient pas à recevoir l'événement? L'événement est-il retenté uniquement pour ce gestionnaire, ou tous les gestionnaires verront-ils la nouvelle tentative?
3 Réponses :
Fondamentalement, le modèle Pub / Sub à événements Azure Event Grid peut gérer deux modèles de messagerie / médiation tels que le modèle Fan-In et le modèle Fan-Out (diffusion). Les extraits d'écran suivants montrent leurs différences:
La connectivité logique entre la source d'événements et le récepteur d'événements est décrite par Subscription, qui est essentiellement un artefact de métadonnées du modèle Pub / Sub. Chaque connectivité logique (représentée par l'abonnement) est indépendante et se découplera librement avec les autres. En d'autres termes, chaque abonné ne peut gérer dans ce modèle Pub / Sub qu'une seule connectivité logique telle qu'une seule source d'événements.
Votre question est liée au modèle Fan-Out (diffusion), où l'intérêt de l'événement est diffusé aux multiples abonnés en utilisant un mode de diffusion PushWithAck. Chaque abonnement au sein de ce modèle de fan-out a sa propre «machine de livraison de l'état des messages» déclarée par l'abonné, comme l'option de réessai, le deadlettering, le filtrage, etc.
En d'autres termes, la livraison des événements aux abonnés est traitée de manière parallèle en fonction de leur abonnement de manière transparente sans aucune dépendance les uns avec les autres. Notez que l'abonné ne dispose d'aucune information sur qui, où, comment, etc. l'événement est livré une fois à un autre, de sorte que chaque abonné ne peut voir que son propre état de livraison, par exemple, la valeur de Aeg-Delivery -Count affiche un compteur de tentatives de la machine à états.
Ainsi, en cas d'échec de la remise de l'événement à l'un des multiples abonnés, le processus de relance activé ne s'exécute que pour cet abonné.
Merci Roman. Je ne savais pas que les lettres mortes étaient une option par abonné, je pensais que c'était par sujet, donc cela explique comment tout cela peut fonctionner comme prévu
Comme l'a expliqué Roman, chaque point de terminaison est géré indépendamment. Si un gestionnaire d'événements échoue, il sera réessayé sans affecter les autres gestionnaires d'événements, et bien sûr, si ce point de terminaison particulier continue à échouer, il finira par être deadletter (en supposant que deadlettering a été configuré sur l'abonnement à l'événement), ou abandonné. < / p>
Lors de la publication d'événements dans les grilles d'événements, les événements des sujets de grille d'événements personnalisés ou des sujets de grille d'événements système (par exemple les espaces de noms Service Bus) sont transmis aux abonnements de grille d'événements configurés avec eux. Les événements sont ensuite envoyés aux points de terminaison configurés avec l'abonnement à la grille d'événements.
Chaque fois que la remise d'événements à un point de terminaison échoue, elle est réessayée en fonction de la stratégie de nouvelle tentative configurée.Si le nombre de tentatives dépasse la stratégie de nouvelle tentative configurée, les événements sont stockés dans l'objet blob du compte de stockage s'il est configuré comme destination de lettre morte , sinon les événements seront perdus.
Par défaut, Event Grid expire tous les événements qui ne sont pas livrés dans les 24 heures. Vous pouvez personnaliser la stratégie de nouvelle tentative lors de la création d'un abonnement à un événement. Vous indiquez le nombre maximum de tentatives de livraison (la valeur par défaut est 30) et la durée de vie de l'événement (la valeur par défaut est de 1440 minutes).
Lorsqu'il y a plusieurs abonnés (abonnements à la grille d'événements) à un même sujet de grille d'événements, une nouvelle tentative se produit uniquement avec l'abonnement à la grille d'événements dont la livraison d'événements a échoué.
reportez-vous à remise des messages Event Grid et réessayer pour plus d'informations sur la politique relative aux nouvelles tentatives.
Je ne peux que supposer que si l'événement ne peut être livré à aucun des abonnés, il serait lettre morte. Cela dit, il vaut mieux soulever ce problème avec la documentation. Ce que j'ai fait ici .
Merci Sean. Ma question portait en fait sur la redistribution, et si un message est redistribué à tous les abonnés ou seulement à celui qui a échoué, mais les lettres mortes sont également une bonne question. J'ajouterai ceci au problème GitHub. En attendant, je ne sais pas si je dois fermer cette question ou la laisser ouverte
Laissez ouvert. Soit l'équipe EG répondra soit vous-même. Dans tous les cas, les gens trouveront cela avec une réponse.
Le modèle d'événement AEG utilisant un modèle de fan-out pour délivrer un message d'événement aux gestionnaires abonnés. Cette connectivité logique pour chaque sortie Fan est décrite par abonnement et ils sont totalement transparents les uns aux autres et se découplent de manière lâche. Le comportement de la livraison de chaque événement dans ce modèle de fan-out est basé sur leurs abonnements, tels que les nouvelles tentatives, le deadlettering, le filtrage, etc. au mode Pull (async), par exemple: la file d'attente de stockage et HybridConnection
pour les besoins du test (comme votre question), vous pouvez utiliser un outil de test codeproject.com/Articles/1254463/Azure-Event-Grid-Tester où peut être simulé votre cas, par exemple: un sujet personnalisé + un abonné à la file d'attente de stockage + un abonné HybridConnection avec une simulation de livraison d'erreur (503).