Ce guide vous permet de comprendre les fonctionnalités de fiabilité de Pub/Sub et d'en obtenir une vue d'ensemble.
Pourquoi Pub/Sub ?
En tant que modèle de messagerie, la publication/souscription est conçue pour dissocier les producteurs de messages des consommateurs de ces messages. Au lieu d'envoyer des requêtes directes aux consommateurs avec les données, les producteurs publient ces données dans un service Pub/Sub tel que Pub/Sub. Le service envoie ces messages de manière asynchrone aux consommateurs intéressés qui se sont abonnés.
Le service absorbe ainsi toutes les subtilités liées à la recherche de consommateurs intéressés par les données. Le service gère également la fréquence à laquelle les consommateurs reçoivent les données, en fonction de leur capacité. Cette dissociation permet aux producteurs de données d'écrire des messages à grande échelle avec une faible latence, indépendamment du comportement des consommateurs.
Pub/Sub offre une diffusion de messages fiable et hautement évolutive. Bien que le service gère la plupart de ces aspects automatiquement, vous contrôlez différents aspects de vos éditeurs et abonnés qui peuvent avoir une incidence sur la disponibilité et les performances. Le reste de ce guide fournit des informations sur ces aspects.
Isolation
Par défaut, Pub/Sub est un service mondial : les thèmes et les abonnements ne sont pas intrinsèquement liés à des régions spécifiques, et les messages circulent au sein du service Pub/Sub entre les régions si nécessaire. Lorsque vous utilisez le point de terminaison mondial, pubsub.googleapis.com, les éditeurs et les abonnés se connectent à la région la plus proche du réseau où Pub/Sub s'exécute. Lorsque vous utilisez les points de terminaison régionaux, tels que us-central1-pubsub.googleapis.com, ou les points de terminaison localisés, tels que pubsub.us-central1.rep.googleapis.com, les éditeurs et les abonnés se connectent à Pub/Sub dans la région spécifiée. Lorsque vous exécutez des éditeurs ou des abonnés en dehors de Cloud de Confiance, il est préférable d'utiliser des points de terminaison régionaux ou géographiques pour vous assurer que les messages circulent de manière cohérente entre les régions attendues.
Isolation régionale
Pour minimiser l'infrastructure dont dépendent les opérations de publication et d'abonnement en dehors d'une seule région et pour vous assurer que toutes les données restent isolées dans cette région, procédez comme suit :
Créez un sujet par région.
Bien que l'espace de noms de Pub/Sub soit global et que vous ne puissiez pas associer de thèmes ni d'abonnements à une région spécifique, les métadonnées de toutes les ressources sont répliquées dans des data stores locaux de la région. Par conséquent, une fois que vous avez créé une ressource, sa configuration est disponible même en cas de problème dans une autre région. Notez que les modifications apportées aux configurations de thèmes ou d'abonnements peuvent ne pas se propager immédiatement en cas d'indisponibilité.
Évitez d'utiliser des points de terminaison globaux.
Utilisez plutôt des points de terminaison régionaux lorsqu'ils sont disponibles et des points de terminaison localisés lorsqu'ils ne le sont pas. Les points de terminaison régionaux offrent une meilleure isolation régionale, mais ne sont pas encore disponibles dans toutes les régions.
Utilisez une règle de stockage des messages et définissez
enforceInTransitsurTrue.Avec l'option Appliquer en transit, les données ne quittent jamais la région. Tous les clients qui se connectent au sujet dans une région spécifique définissent la règle de stockage des messages sur cette région.
Avec des thèmes configurés de cette manière, vous pouvez être sûr que toutes les opérations de publication et d'abonnement écrivent et lisent des données exclusivement dans la région. En cas de défaillance de l'éditeur, de l'abonné ou de Pub/Sub dans une seule région, la diffusion des messages s'arrête dans cette région. La diffusion de messages sur les thèmes et les abonnements pour les autres régions n'est pas affectée.
Si vous avez également besoin que les opérations administratives et l'espace de noms de vos sujets et abonnements soient isolés au niveau régional, envisagez d'utiliser Managed Service pour Apache Kafka.
Basculement
Si vous n'avez pas besoin d'isolation régionale, vous pouvez profiter de la capacité de Pub/Sub à distribuer efficacement des messages dans plusieurs régions afin d'obtenir des capacités de basculement multirégional. Le reste de cette section explique comment créer des thèmes et des abonnements, et comment placer des éditeurs et des abonnés afin de prendre en charge différents types de basculement et de redondance des données.
Sémantique de basculement par défaut
Prenons l'exemple d'un sujet et d'un abonnement uniques. Les éditeurs sont situés dans des régions des États-Unis et d'Australie, et les abonnés dans les régions Cloud de Confiance d'Europe et d'Australie. Si tous les abonnés ont une capacité suffisante pour recevoir des messages, le flux de messages se présente comme suit :
Les P représentent les éditeurs et les S les abonnés. L'hexagone bleu représente le service Pub/Sub. Les cylindres représentent les emplacements où les messages sont stockés (ils sont toujours conservés dans plusieurs zones de la région où ils sont publiés). Pub/Sub préfère envoyer les messages dans la même région où ils ont été publiés lorsque des abonnés sont disponibles. Sinon, il envoie les messages à la région la plus proche du réseau disposant d'abonnés ayant de la capacité. Par conséquent, comme le montre l'image précédente, les messages publiés aux États-Unis sont envoyés aux abonnés en Europe, et les messages publiés en Australie restent en Australie.
Les sections suivantes décrivent ce qui se passe dans différents scénarios d'échec.
Abonnés en Europe indisponibles
Imaginons que les abonnés en Europe soient refusés ou que l'application plante fréquemment, et qu'ils ne parviennent pas à maintenir une connexion à Pub/Sub. Si cela s'était produit, le service aurait commencé à distribuer des messages aux abonnés en Australie :
Abonnés en Europe et en Australie indisponibles
Si tous les abonnés sont indisponibles, Pub/Sub stocke les messages jusqu'à la durée de conservation des messages configurée.
Une fois que les abonnés se reconnectent, les messages sont distribués, sauf si l'indisponibilité dure plus longtemps que la durée de conservation des messages configurée. Par défaut, la durée de conservation des messages d'abonnement est de sept jours. Vous pouvez également configurer la conservation des messages dans un sujet pendant 31 jours maximum. Ne choisissez pas une durée de conservation des messages inférieure à la durée maximale d'indisponibilité que vous prévoyez ou êtes prêt à tolérer.
Pub/Sub n'est pas disponible en Europe
Bien que cela soit rare, vous pouvez également être amené à gérer les cas où Pub/Sub lui-même n'est pas disponible. L'indisponibilité de Pub/Sub se manifeste par des périodes prolongées d'erreurs inattendues sur les requêtes de publication ou d'abonnement, ou par l'incapacité à distribuer les messages publiés aux abonnés. Par exemple, si Pub/Sub est indisponible dans la région Europe, le scénario est très semblable à celui où les abonnés sont indisponibles :
Notez que dans ce cas, les abonnés en Europe ne basculent pas vers une autre région, même s'ils utilisent le point de terminaison mondial. Pub/Sub ne bascule pas intentionnellement automatiquement. Imaginez que ce soient les abonnés eux-mêmes qui provoquent un problème inattendu dans Pub/Sub, entraînant une indisponibilité. Ce type de problème est considéré comme une indisponibilité majeure. Toutefois, l'étendue de l'impact de la panne peut être limitée à la région à laquelle les abonnés sont connectés. Si le service leur permettait de basculer vers une autre région, les abonnés pourraient également provoquer une indisponibilité dans cette région, ce qui entraînerait une défaillance en cascade dans l'ensemble du service.
Éditeurs indisponibles en Australie
Si les éditeurs d'une région deviennent indisponibles, les messages déjà publiés sont toujours distribués aux abonnés les plus proches :
À terme, tous les messages sont consommés et confirmés par les abonnés. Lors de l'envoi de messages, Pub/Sub tente de minimiser la distance réseau. Par conséquent, les abonnés de la région australienne peuvent cesser de recevoir des messages si les abonnés européens ont suffisamment de capacité pour gérer tous les messages publiés aux États-Unis.
Pub/Sub n'est pas disponible aux États-Unis
Pub/Sub écrit de manière synchrone les messages dans plusieurs zones d'une région. Par conséquent, une panne zonale ne suffit pas à empêcher la distribution des messages. C'est l'indisponibilité de la région entière qui est nécessaire. Si Pub/Sub devient indisponible dans une région où les éditeurs envoient des messages, il est possible que les messages de cette région ne soient pas distribués tant que le service n'est pas entièrement restauré :
Le message est finalement remis (en supposant que la période de conservation des messages ne soit pas écoulée), avec un retard correspondant à la durée de l'indisponibilité. Notez que, comme les abonnés, les éditeurs aux États-Unis ne basculent pas vers une autre région en cas d'échec du service. Ce comportement permet d'éviter les défaillances en cascade dans les régions en raison d'un éditeur ou d'un abonné défectueux.
Basculement et redondance contrôlés par le client
La sémantique de basculement par défaut de Pub/Sub ne garantit pas toujours que les messages peuvent toujours transiter des éditeurs vers les abonnés en cas de panne n'importe où entre les deux. Des pannes peuvent se produire à différents endroits, y compris chez vos clients, dans le service sur lequel vos éditeurs ou abonnés s'exécutent, dans le réseau ou même, rarement, dans Pub/Sub lui-même. Si vous avez besoin que vos services soient résilients à de telles pannes, vous devez implémenter vos propres redondances. En règle générale, ces redondances incluent l'utilisation de plusieurs instances de clients éditeurs et abonnés, où chacun utilise un point de terminaison de localisation différent.
Vous pouvez souhaiter une résilience à deux types d'impact : zonal ou régional. Voici les options de configuration pour chacun d'eux.
Résilience zonale
Pub/Sub dispose d'une réplication interzone intégrée. Vous n'avez aucune action spéciale à effectuer pour gérer les pannes monozones qui affectent le service lui-même. Toutefois, pour assurer la résilience en cas de panne pour vos clients ou votre réseau, il est préférable d'exécuter les éditeurs et les abonnés avec une capacité suffisante dans plusieurs zones de la région. Si une seule zone est hors service, les clients de l'autre zone peuvent prendre le relais et traiter les messages. Il est recommandé de ne pas publier simultanément les modifications apportées à ces clients. Ainsi, si un bug est introduit, les autres zones non modifiées peuvent continuer à traiter les messages.
Résilience régionale
Pour être résilient face aux défaillances régionales, configurez des redondances supplémentaires dans vos éditeurs et abonnés. Vous pouvez exécuter des éditeurs et des abonnés dans plusieurs régions pour faire face à d'éventuelles pannes dans ces clients ou dans le réseau.
Si vous souhaitez être résilient face aux éventuelles défaillances Pub/Sub dans une région, vous devez disposer d'un mécanisme de basculement prêt à faire face à une telle panne. Les approches possibles sont un compromis entre la latence de transmission des messages de bout en bout et votre coût.
Pour minimiser la latence lorsque le coût n'est pas un problème, la meilleure stratégie consiste à toujours publier et s'abonner simultanément dans différentes régions. Commencez par choisir le nombre de régions dans lesquelles vous souhaitez bénéficier d'une redondance. Ensuite, bien que cela ne soit pas strictement nécessaire, vous pouvez configurer un sujet et un abonnement pour chacune de ces régions.
Chaque éditeur crée autant de clients éditeur que de régions (un pour chaque région) et utilise un point de terminaison géographique différent pour s'assurer que les messages sont dirigés vers des régions distinctes. Si vous utilisez des thèmes distincts, chaque client éditeur doit publier sur le thème correspondant à la région. Pour chaque message, l'éditeur appelle la publication sur chaque client. Avec les publications redondantes, il n'est pas nécessaire de réessayer de publier si l'une d'elles échoue.
De même, chaque abonné crée autant de clients abonnés (un pour chaque région) et utilise un point de terminaison géographique pour se connecter à une autre région. Si vous utilisez des abonnements différents pour chaque région, chaque client abonné doit utiliser l'abonnement correspondant. Notez que les régions utilisées pour les éditeurs et les abonnés ne doivent pas nécessairement être les mêmes. Les abonnés reçoivent les messages des trois abonnements et les traitent.
Cette configuration présente plusieurs fonctionnalités et exigences clés :
- Les pannes limitées à une seule région n'affectent pas le traitement des messages déjà publiés ni de ceux publiés pendant la panne. Étant donné que les messages ont été publiés dans plusieurs régions, ils restent disponibles dans d'autres régions en cas d'indisponibilité d'une région. Pendant l'indisponibilité, les appels de publication échouent dans la région concernée, mais aboutissent dans les autres.
- La latence de traitement des messages n'est pas affectée tant qu'au moins l'une des régions par lesquelles transitent les messages est disponible.
- Le traitement des messages doit être idempotent. Étant donné que chaque message sera distribué plusieurs fois, le traitement des messages doit être résistant aux doublons. En cas d'indisponibilité régionale, certains de ces doublons peuvent arriver beaucoup plus tard que la première fois que le message a été distribué. Ces doublons proviennent probablement d'une autre région qui n'était pas en panne.
L'exécution avec ce type de redondance offre la plus grande résilience à tout type de panne. Cette configuration est recommandée pour les services Google internes qui s'appuient sur Pub/Sub et nécessitent la plus haute disponibilité. Toutefois, cette configuration multiplie le coût de l'envoi des messages par le nombre de régions utilisées. Il existe également un coût supplémentaire lié à l'utilisation du réseau interrégional pour les messages qui doivent être transférés d'une région à une autre.
Une autre approche de la redondance consiste à ne basculer que lorsque les requêtes échouent ou que les messages ne sont pas transmis des éditeurs aux abonnés comme prévu. Dans ce scénario, vous disposez d'une région principale vers laquelle vous dirigez vos éditeurs et abonnés via des points de terminaison géographiques. Comme précédemment, ces régions ne doivent pas nécessairement être identiques. Vous disposez également d'une région de secours pour les éditeurs et les abonnés, qui est utilisée lorsque la région principale n'est pas disponible.
Les éditeurs ne publient que dans la région principale (via le point de terminaison localisé) lorsque leurs demandes sont envoyées avec succès. Chaque fois qu'une région est considérée comme indisponible, les éditeurs commencent à publier dans la région de secours. Deux méthodes permettent de déterminer que la région est hors service et de basculer vers une autre région. Cela peut être fait manuellement, et la configuration est mise à jour de manière dynamique chez les éditeurs. Les éditeurs peuvent également mettre à jour eux-mêmes la configuration si le taux d'erreur dans les demandes de publication est suffisamment élevé.
Les abonnés doivent toujours se connecter à la région principale via le point de terminaison de localisation. Vous pouvez décider que l'abonné peut utiliser la région de secours avec un ou plusieurs des déclencheurs suivants :
- Abonnez-vous toujours à la région de secours. Dans ce cas, l'abonné maintient une connexion à la région principale et à la région de secours à tout moment. Les mêmes régions peuvent être utilisées pour les instances principales et de secours, à la fois pour les éditeurs et les abonnés. Dans ce cas, l'abonné ne doit recevoir des messages que dans la région de secours si l'éditeur a basculé.
- Détectez manuellement les abonnés et basculez-les vers la région de secours à l'aide d'une configuration. Si vous détectez une panne, vous pouvez basculer vers la région de secours, puis revenir à la région principale une fois la panne résolue.
- Basculement en cas d'erreur d'abonné. Si les requêtes des abonnés renvoient des erreurs, vous pouvez les utiliser comme indication que vous devez basculer vers la région de secours. Notez que les bibliothèques clientes Pub/Sub réessaient les requêtes pull de streaming en interne en cas d'erreurs temporaires. Il est donc possible que vous ne puissiez pas détecter les longues périodes d'erreurs inattendues. De plus, le taux d'erreur de streaming pull devrait être de 100%, même en cas de fonctionnement normal.
- Basculer si l'abonné ne reçoit pas de messages pendant une durée anormalement longue. Si les messages sont publiés de manière régulière, les abonnés peuvent toujours les recevoir. Si les abonnés ne reçoivent aucun message pendant une longue période, il peut s'agir d'un problème lié à l'abonnement dans Pub/Sub dans la région principale. Ce problème est résolu en basculant vers la région de secours.
Parmi les quatre options, la première est idéale. Une connexion d'abonné ne coûte rien si aucun message ne transite par celle-ci. Le seul coût est celui de l'empreinte de l'instance supplémentaire de la bibliothèque cliente de l'abonné, qui peut être négligeable. Vous devez également tenir compte du quota de connexions StreamingPull ouvertes par région.
L'avantage de ce deuxième modèle est qu'il n'y a pas de multiplicateur dans le coût Pub/Sub, car les messages ne sont publiés qu'une seule fois. Toutefois, pour certains types de pannes, les messages publiés avant le début de la panne peuvent ne pas être disponibles tant que la panne n'est pas résolue. Il est possible que les messages stockés dans la région indisponible ne puissent pas être distribués aux abonnés, quel que soit leur emplacement de connexion. Les messages publiés dans la région de secours pendant l'indisponibilité peuvent être disponibles. De plus, il peut y avoir une période d'indisponibilité avec des taux d'erreur plus élevés pour les éditeurs ou les abonnés. Cela dépend de la méthode utilisée pour détecter une panne et du temps nécessaire pour basculer vers la région de secours.
Quelle que soit l'option choisie, soyez conscient de la façon dont elle peut interagir avec les fonctionnalités de Pub/Sub. La distribution ordonnée et la distribution de type "exactement une fois" offrent toutes deux leurs garanties dans une région. Par exemple, si vous utilisez la technique de redondance de basculement, l'ordre de remise des messages n'est garanti que pour les messages publiés dans la même région. L'abonné peut recevoir des messages publiés dans la région de secours avant ceux publiés dans la région principale, même si les messages ont été publiés en premier dans la région principale.
Affinage des éditeurs
Quelle que soit l'option de basculement que vous choisissez, vous devez effectuer des étapes de réglage supplémentaires au niveau des éditeurs eux-mêmes. Le réglage du comportement des éditeurs garantit des performances optimales en cas de charge élevée. Le traitement par lot des messages est un moyen de réduire les coûts au détriment de la latence. Il ne s'agit pas d'un problème de fiabilité et il n'est donc pas abordé ici. Concentrez-vous plutôt sur d'autres paramètres utiles pour améliorer la fiabilité, y compris les paramètres de réessai et de contrôle de flux.
La publication peut échouer pour différentes raisons, y compris des raisons temporaires comme l'indisponibilité du réseau ou des raisons qui nécessitent l'intervention de l'utilisateur, comme des modifications d'autorisation. La bibliothèque cliente Pub/Sub relance les erreurs temporaires à l'aide des paramètres spécifiés dans les paramètres de nouvelle tentative. Ces paramètres contrôlent le comportement de la backoff exponentielle lors des nouvelles tentatives de publication des RPC qui échouent pour des raisons temporaires. Bien que les paramètres par défaut fonctionnent généralement bien dans la plupart des scénarios, il peut arriver que vous souhaitiez ajuster ces valeurs.
Les deux propriétés que vous souhaiterez probablement ajuster sont le délai RPC avant expiration initial et le délai avant expiration total. Le délai RPC avant expiration initial correspond au temps accordé au premier RPC de publication pour se terminer. Si un RPC échoue ou expire, un autre est tenté avec un délai d'attente plus long jusqu'à ce que le nombre total de requêtes ou le délai d'attente total soient dépassés.
Le délai avant expiration initial peut être ajusté si votre éditeur est limité par le réseau ou s'il est éloigné du centre de données Cloud de Confiance by S3NS le plus proche qui exécute Pub/Sub. Les contraintes réseau peuvent être des limites de débit de la machine sur laquelle l'éditeur s'exécute ou le résultat d'autres services gourmands en bande passante s'exécutant sur la même machine. Si le délai avant expiration est trop court, les RPC initiaux peuvent échouer à plusieurs reprises, ce qui nécessite davantage de tentatives (avec des délais avant expiration plus longs) pour publier correctement. La nécessité de réessayer à plusieurs reprises augmente la latence de publication. Dans ce cas, l'augmentation du délai avant expiration initial pourrait accélérer les publications.
Si la connexion réseau n'est pas fiable, il peut être utile d'augmenter le délai d'attente total et le délai d'attente initial. L'augmentation du délai d'expiration total donne plus de temps à l'RPC de publication pour se terminer correctement. Lorsque les RPC de publication échouent systématiquement avec des erreurs de délai dépassé, envisagez d'ajuster ces valeurs.
Des erreurs de dépassement de délai continu lors de la publication peuvent également indiquer la nécessité d'ajuster le contrôle de flux de l'éditeur. Ces paramètres vous permettent de vous assurer que vos éditeurs sont résilients aux pics de trafic entrant qui génèrent davantage de messages à envoyer à Pub/Sub. Une forte augmentation des requêtes sortantes peut surcharger le processeur, la mémoire ou la capacité réseau de l'éditeur. Lorsque le serveur de publication est surchargé, il ne peut pas traiter les requêtes ni les réponses de publication avant l'expiration des délais. Cela entraîne encore plus de demandes de publication et, en fin de compte, atteint le délai d'expiration total. Le contrôle du flux de l'éditeur limite le nombre de messages ou d'octets qui peuvent être en attente sans réponse à la demande de publication. Limiter le nombre de requêtes de cette manière permet de maintenir l'utilisation des ressources à un niveau gérable, même en cas de pics. Selon le fonctionnement de votre éditeur, vous pouvez autoriser les RPC de publication ultérieurs à attendre la capacité en autorisant la publication à bloquer d'autres requêtes. Vous pouvez également renvoyer un message aux appelants de votre service en demandant au contrôle de flux de renvoyer une erreur lorsque la capacité est atteinte. Vous configurez la façon dont la bibliothèque cliente de l'éditeur répond au comportement de dépassement de la limite.
Abonnés à l'affinage
Un réglage de l'abonné peut également être nécessaire pour garantir leur bon fonctionnement. Comme pour les éditeurs, vous pouvez ajuster les paramètres de contrôle du flux des abonnés pour vous assurer qu'ils ne sont pas submergés. La bibliothèque cliente de l'abonné utilise l'extraction en flux continu, où le client ouvre un flux persistant vers le serveur et le serveur envoie des messages dès qu'ils sont disponibles. En cas de forte augmentation du nombre de messages publiés, l'abonné peut recevoir plus de messages qu'il ne peut en traiter. Avec le contrôle de flux en place, le nombre de messages non confirmés en attente pour le client à un moment donné est limité. Cela réduit le nombre de messages traités simultanément et répartit leur traitement sur une période plus longue. La répartition de la charge permet aux abonnés de respecter les limites de ressources qui ont un impact sur le traitement des messages, ce qui peut entraîner un effet domino et rendre impossible le traitement des messages.
Le contrôle de flux seul suffit si vous ne vous attendez qu'à des pics de volume de données à traiter qui finissent par diminuer. Si le trafic augmente généralement au fil du temps en raison d'une utilisation accrue, le contrôle de flux protège les abonnés. Toutefois, cela peut entraîner un backlog qui continue de s'accumuler et qui empêche la distribution des messages avant l'expiration de la durée de conservation des messages. Dans ce cas, vous pouvez également configurer l'autoscaling pour augmenter le nombre d'abonnés en réponse à un nombre croissant de messages non confirmés. La façon dont vous configurez cela dépend de la plate-forme de calcul que vous utilisez pour vos abonnés. Par exemple, l'autoscaler de Compute Engine vous permet de faire évoluer votre infrastructure en fonction de métriques telles que le nombre de messages non distribués. L'utilisation de l'autoscaling et du contrôle de flux vous permet de vous assurer que vos abonnés sont résilients aux autres pics à court terme du débit de messages et à la croissance à long terme qui nécessite plus de puissance de calcul. Veillez à suivre les bonnes pratiques pour utiliser les métriques Pub/Sub comme signal de scaling.
Utiliser la version régionale des métriques sur le backlog au lieu des versions mondiales
Lorsque vous surveillez votre backlog d'abonnements, configurez des règles d'alerte ou mettez à l'échelle automatiquement les abonnés, Pub/Sub propose deux versions de chaque métrique de backlog. Assurez-vous d'utiliser les versions avec le suffixe by_region :
N'utilisez pas les versions globales de ces métriques (subscription/num_undelivered_messages et subscription/oldest_unacked_message_age) si vous souhaitez que votre surveillance, vos alertes et votre autoscaling soient résilients aux pannes dans une seule région. Les versions mondiales de ces métriques nécessitent de calculer le backlog dans toutes les régions connues pour avoir des messages, ce qui signifie qu'une indisponibilité dans une seule région entraîne un manque de données. En revanche, les versions by_region des métriques calculent et indiquent l'encours par région. Si le backlog ne peut pas être calculé pour une seule région, la métrique indique toujours des valeurs pour les autres régions.
Utiliser les instantanés et la recherche pour des déploiements sécurisés
La perte de messages est généralement un événement catastrophique. Pub/Sub propose la distribution au moins une fois pour tous les messages publiés. Toutefois, le traitement correct de ces messages dépend du comportement des abonnés. Si les messages sont correctement confirmés, Pub/Sub ne les renvoie pas. Par conséquent, un bug introduit dans le nouveau code d'abonné que vous déployez et qui accuse réception des messages sans les avoir traités correctement peut entraîner une perte de messages induite par l'abonné. Pub/Sub propose la fonctionnalité Instantané et recherche, qui peut vous aider à vous assurer de traiter correctement chaque message, même en cas de bugs d'abonné.
Le modèle de déploiement de chaque abonné doit être le suivant :
Le temps d'attente avant de déterminer si le nouvel abonné fonctionne peut varier en fonction de votre cas d'utilisation. La seule façon de quitter le flux d'étapes est lorsqu'un abonné est considéré comme fonctionnel, auquel cas l'instantané peut être supprimé.
L'utilisation de l'instantané et de la recherche n'est pas destinée à remplacer les bonnes pratiques concernant l'exécution du logiciel pour la première fois dans un environnement hors production et le déploiement progressif en production. Ils offrent un niveau de protection supplémentaire pour garantir le traitement fiable des données. L'inconvénient est que la recherche de l'instantané peut entraîner la distribution de messages en double que votre abonné a traités avec succès. Toutefois, étant donné que Pub/Sub utilise par défaut la sémantique de type "au moins une fois", vos abonnés sont déjà résilients à la rediffusion des messages.