Pub/Sub: présentation de la fiabilité

Ce guide présente les fonctionnalités de fiabilité de Pub/Sub. Ce document traite des sujets suivants:

• Pourquoi Pub/Sub ?
• Basculement
• Affiner les éditeurs
• Affiner les abonnés
• Utiliser les instantanés et rechercher des déploiements sécurisés

Pourquoi Pub/Sub ?

En tant que paradigme de messagerie, la publication et l'abonnement sont conçus pour dissocier les producteurs de messages des consommateurs de ces messages. Au lieu d'envoyer des requêtes directes aux clients avec les données, les producteurs les publient dans un service Pub/Sub tel que Pub/Sub. Le service distribue ces messages de manière asynchrone aux clients intéressés qui se sont abonnés.

Résultat : le service absorbe toutes les subtilités liées à la recherche de clients intéressés par les données. Le service gère également le débit auquel les clients reçoivent les données, en fonction de leur capacité. Ce découplage 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 distribution de messages fiable et hautement évolutive. Bien que le service gère automatiquement une grande partie de ces tâches, vous contrôlez différents aspects de vos éditeurs et abonnés qui peuvent affecter la disponibilité et les performances. Le reste de ce guide fournit des détails sur ces aspects

Basculement

Pub/Sub est un service mondial: les sujets 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 en cas de besoin. Lorsque vous utilisez le point de terminaison global, pubsub.googleapis.com, les éditeurs et les abonnés se connectent à la région la plus proche du réseau dans laquelle Pub/Sub s'exécute. Lors de l'utilisation des points de terminaison locaux, tels que us-central1-pubsub.googleapis.com, les éditeurs et les abonnés se connectent à Pub/Sub dans la région spécifiée. Lorsque vous gérez des éditeurs ou des abonnés en dehors de Google Cloud, il est préférable d'utiliser des points de terminaison locaux afin de vous assurer que les messages circulent de manière cohérente entre les régions attendues. Le reste de cette section explique comment créer des sujets et des abonnements. Nous verrons également comment placer les éditeurs et les abonnés afin qu'ils puissent prendre en charge différents types de basculement et de redondance des données.

Sémantique de basculement par défaut

Prenons un cas où il n'y a qu'un seul sujet et un seul abonnement. Les éditeurs sont situés en Australie et aux États-Unis, et les abonnés sont situés dans les régions Google Cloud d'Europe et d'Australie. Dans le cas où tous les abonnés disposent d'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 de stockage des messages (les messages 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 que celle 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, avec des abonnés ayant une capacité suffisante. Par conséquent, comme le montre l'image précédente, les messages publiés aux États-Unis sont distribué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 de défaillance.

Les abonnés en Europe ne sont pas disponibles

Nous partons du principe que les abonnés en Europe ont été désactivés ou plantent fréquemment, et qu'ils sont dans l'incapacité de maintenir une connexion à Pub/Sub. Si cela se produisait, le service commencera à distribuer des messages aux abonnés en Australie:

Les abonnés en Europe et en Australie ne sont pas disponibles

Si tous les abonnés sont indisponibles, Pub/Sub stocke les messages jusqu'à la durée de conservation des messages configurée.

Une fois les abonnés reconnectés, les messages sont distribués, sauf si la panne dure plus longtemps que la durée de conservation des messages configurée. Par défaut, la durée de conservation des messages pour les abonnements est définie sur 7 jours. Vous pouvez également configurer la conservation des messages sur un sujet pendant 31 jours maximum. Ne choisissez pas une durée de conservation des messages inférieure à l'indisponibilité maximale prévue ou que vous êtes prêt à tolérer.

Pub/Sub n'est pas disponible en Europe

Bien que cela soit rare, vous pouvez également gérer les cas où Pub/Sub lui-même est indisponible. L'indisponibilité de Pub/Sub se manifeste par de longues périodes d'erreurs inattendues sur les requêtes de publication ou d'abonnement, ou par l'incapacité à distribuer des messages publiés aux abonnés. Par exemple, si Pub/Sub était indisponible dans la région Europe, le scénario ressemble beaucoup à celui du nombre d'abonnés:

Notez que dans ce cas, les abonnés situés en Europe ne basculent pas vers une autre région, même s'ils utilisent le point de terminaison mondial. Pub/Sub n'effectue pas de basculement automatique. Imaginez que les abonnés eux-mêmes provoquent un problème inattendu dans Pub/Sub qui entraîne une indisponibilité. Un tel problème est considéré comme une panne majeure. Toutefois, l'impact de la panne peut être limité à la région à laquelle les abonnés se sont connectés. Si le service leur permettait de basculer vers une autre région, les abonnés pourraient également y provoquer une indisponibilité, ce qui entraînerait une défaillance en cascade sur l'ensemble du service.

Les éditeurs en Australie ne sont pas disponibles

Si les éditeurs d'une région deviennent indisponibles, les messages déjà publiés sont tout de même 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 d'Australie peuvent cesser de recevoir des messages si les abonnés en Europe disposent d'une capacité suffisante 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 des messages dans plusieurs zones d'une région. Par conséquent, une panne de zone ne suffit pas pour empêcher la distribution des messages. Toute la région doit être indisponible. 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 toujours distribué (en supposant que la durée de conservation des messages n'est pas écoulé), retardé de la durée de la panne. Notez que comme pour les abonnés, les éditeurs situés 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 dues à un éditeur ou à un abonné défaillant.

Isolation

La sémantique de basculement par défaut détaillée affecte l'isolation des données et la manière dont l'indisponibilité des éditeurs, des abonnés ou de Pub/Sub peut affecter le flux de messages. Votre cas d'utilisation peut nécessiter différents niveaux d'isolation. Par exemple, vous pouvez exiger une distribution intrarégionale de tous les messages.

Si vous ne souhaitez pas d'isolation, la sémantique de basculement par défaut détaillée suffit. Vous devez créer un seul sujet, un seul abonnement et placer des éditeurs et des abonnés dans toutes les régions sélectionnées. Si les abonnés deviennent indisponibles ou si Pub/Sub est indisponible dans la région à laquelle ils se connectent, la distribution bascule vers les abonnés d'une autre région.

Pour l'isolation régionale, où les données ne quittent pas une région spécifique, créez un sujet et un abonnement pour gérer les messages dans chaque région. Recherchez des éditeurs et des abonnés dans chacune de ces régions, et demandez-leur de publier et de s'abonner, respectivement, au sujet régional et à l'abonnement correspondants. Vous devez également utiliser des points de terminaison régionaux pour vous assurer que les données ne sont déplacées que dans la région. En cas d'échec de l'éditeur, de l'abonné ou de Pub/Sub dans une seule région, la distribution des messages s'arrête dans cette région. La distribution des messages sur les sujets et les abonnements pour les autres régions n'est pas affectée.

Enfin, l'isolation zonale, qui garantit que les données restent dans une seule zone, n'est pas possible dans Pub/Sub. Si vous souhaitez que les zones individuelles soient indépendantes, utilisez Pub/Sub Lite.

Basculement et redondance contrôlés par le client

La sémantique de basculement par défaut de Pub/Sub peut ne pas garantir pleinement que les messages peuvent toujours circuler des éditeurs vers les abonnés en cas de panne quelconque. Des interruptions peuvent survenir à différents endroits, y compris au niveau de vos clients, du service utilisé par vos éditeurs ou abonnés, sur le réseau, voire 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 diffuseurs et abonnés, chacun utilisant un point de terminaison local différent.

Vous voudrez peut-être avoir une résilience à deux niveaux d'impact différents: zonal ou régional. Voici les options de configuration pour chaque option.

Résilience zonale

Pub/Sub intègre une réplication interzone. Vous n'avez pas besoin de prendre de mesures particulières pour gérer les pannes dans une seule zone qui affectent le service lui-même. Toutefois, pour assurer la résilience aux pannes de vos clients ou de votre réseau, il est préférable d'exécuter des éditeurs et des abonnés disposant d'une capacité suffisante dans plusieurs zones de la région. Si une seule zone est indisponible, les clients de l'autre zone peuvent récupérer le trafic et traiter les messages. Il est recommandé de ne pas publier simultanément les modifications apportées à ces clients afin qu'en cas d'introduction d'un bug, les autres zones non touchées puissent continuer à traiter les messages.

Résilience régionale

Afin de résister aux défaillances régionales, configurez des redondances supplémentaires au niveau de vos éditeurs et de vos abonnés. Vous pouvez gérer des éditeurs et des abonnés dans plusieurs régions pour faire face aux éventuelles pannes dans ces clients ou dans le réseau.

Si vous souhaitez être résilient aux défaillances potentielles de Pub/Sub dans une région, vous devez disposer d'un mécanisme de basculement prêt à gérer ce type de panne. Les approches possibles constituent un compromis entre la latence de distribution des messages de bout en bout et vos coûts.

Pour minimiser la latence si le coût n'est pas une préoccupation, la meilleure stratégie consiste à toujours publier et à s'abonner simultanément dans différentes régions. Tout d'abord, choisissez le nombre de régions dans lesquelles vous souhaitez obtenir une redondance. Ensuite, bien que ce 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 qu'il existe de régions (un pour chaque région) et utilise un point de terminaison local différent pour s'assurer que les messages sont acheminés vers des régions distinctes. Si vous utilisez des sujets distincts, chaque client éditeur doit publier dans le sujet correspondant par région. Pour chaque message, l'éditeur appelle la publication sur chaque client. Avec les publications redondantes, il n'est pas nécessaire de relancer la publication 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 localisé pour se connecter à une région différente. 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 comporte plusieurs fonctionnalités et exigences clés:

1. Toute panne régionale n'affecte 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, même si l'une d'elles est indisponible. Pendant la panne, les appels de publication échouent dans la région concernée, mais aboutissent dans les autres.
2. La latence de traitement des messages n'est pas affectée tant que l'une des régions par lesquelles les messages circulent est disponible.
3. Le traitement des messages doit être idempotent. Étant donné que chaque message va être distribué plusieurs fois, leur traitement doit être résilient aux doublons. En cas de panne régionale, certains de ces doublons peuvent survenir beaucoup plus tard que la première distribution du message. Ces doublons provenaient probablement d'une autre région qui ne faisait pas l'objet d'une panne.

L'exécution avec ce type de redondance offre une résilience maximale à tout type de panne. Pour les services Google internes qui s'appuient sur Pub/Sub et nécessitent la plus haute disponibilité, cette configuration est à privilégier. Cependant, cette configuration s'accompagne d'un compromis en multipliant le coût de distribution des messages par le nombre de régions utilisées. L'utilisation du réseau interrégional pour les messages devant circuler d'une région à l'autre s'ajoute également au coût.

Une autre approche de la redondance consiste à basculer uniquement en cas d'échec des requêtes ou lorsque les messages ne sont pas acheminés des éditeurs vers les abonnés comme prévu. Dans ce scénario, vous disposez d'une région principale vers laquelle vous redirigez vos éditeurs et abonnés via des points de terminaison locaux. Comme précédemment, il n'est pas nécessaire de définir la même région. Vous disposez également d'une région de remplacement 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 local) lorsque leurs requêtes sont bien envoyées. Chaque fois que la région est indisponible, les éditeurs commencent à publier dans la région de remplacement. Il existe deux manières de déterminer que la région est en panne et de basculer. Cela peut se faire par le biais d'un processus manuel, et la configuration est mise à jour de manière dynamique au niveau des éditeurs. Les éditeurs peuvent également mettre à jour la configuration eux-mêmes si le taux d'erreur des requêtes de publication est suffisamment élevé.

Les abonnés doivent toujours se connecter à la région principale via le point de terminaison local. Vous pouvez décider que l'abonné peut utiliser la région de remplacement avec un ou plusieurs des déclencheurs suivants:

1. Abonnez-vous toujours à la région de remplacement. Dans ce cas, l'abonné conserve en permanence une connexion à la région principale et à la région de remplacement. Les mêmes régions peuvent être utilisées pour l'instance principale et la création de remplacement pour les éditeurs et les abonnés. Dans ce cas, l'abonné ne doit recevoir des messages via la région de sauvegarde que si l'éditeur a basculé.
2. Détectez manuellement les abonnés et faites-les basculer vers la région de remplacement via une configuration. Si vous détectez une panne, vous pouvez basculer vers la région de secours, puis revenir à la région principale lorsque la panne a disparu.
3. Basculement en cas d'erreurs d'abonné. Si les requêtes d'abonné renvoient des erreurs, vous pouvez l'utiliser pour indiquer que vous devez basculer vers la région de remplacement. Notez que les bibliothèques clientes Pub/Sub relancent la diffusion des requêtes pull en interne en cas d'erreurs temporaires. Il est donc possible que vous ne puissiez pas détecter la présence d'erreurs inattendues pendant de longues périodes. De plus, le taux d'erreur lié à l'extraction en flux continu devrait être de 100%, même en fonctionnement normal.
4. Basculez si l'abonné traverse une période longue inattendue sans recevoir de messages. En supposant que les messages soient publiés de manière cohérente, les abonnés peuvent toujours recevoir les messages. S'ils traversent une période prolongée sans recevoir de message, il peut y avoir un problème côté abonnement dans Pub/Sub dans la région principale. Ce problème est résolu en basculant vers la région de remplacement.

Parmi les quatre options proposées, la première est idéale. Une connexion d'abonné ne coûte rien si aucun message n'y transite. Le seul coût concerne l'empreinte de l'instance supplémentaire de la bibliothèque cliente de l'abonné, ce qui peut être négligeable. Vous devez également tenir compte du nombre de connexions pull en flux continu ouvertes par quota de région.

L'avantage de ce second modèle est qu'il n'y a pas de multiplicateur dans le coût Pub/Sub, puisque les messages ne sont publiés qu'une seule fois. Toutefois, en contrepartie, pour certains types de pannes, les messages publiés avant le début de la panne peuvent ne pas être disponibles tant qu'elle n'est pas résolue. Il est possible que les messages stockés dans une région indisponible ne puissent pas être distribués aux abonnés, quel que soit l'endroit où ils sont connectés. Les messages publiés pendant la panne dans la région de secours peuvent être disponibles. En outre, il peut y avoir une période d'indisponibilité avec une augmentation des taux d'erreur pour les éditeurs ou les abonnés. Cela dépend de la méthode utilisée pour détecter une panne et du délai de basculement vers la région de secours.

Quelle que soit l'option que vous choisissez, sachez qu'elle peut interagir avec les fonctionnalités de Pub/Sub. La livraison de la commande et la livraison de type "exactement une fois" offrent toutes deux leurs garanties au sein d'une région. Par exemple, si vous utilisez la technique de redondance du basculement, la distribution des messages n'est garantie 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 remplacement avant les messages publiés dans la région principale, même s'ils ont d'abord été publiés dans la région principale.

Affiner les éditeurs

Quelle que soit l'option de basculement que vous choisissez, vous devez effectuer certaines étapes de réglage supplémentaires au niveau des éditeurs eux-mêmes. Ajuster le comportement de l'éditeur garantit des performances optimales en cas de charge élevée. Le traitement par lot des messages permet de trouver un compromis entre latence et coûts réduits. Toutefois, il ne s'agit pas d'un problème de fiabilité et n'est donc pas abordé ici. Concentrez-vous plutôt sur certains des autres paramètres utiles pour ajuster la fiabilité, y compris les paramètres de nouvelle tentative et de contrôle de flux.

Les publications peuvent échouer pour différentes raisons, y compris pour des raisons temporaires, comme une indisponibilité du réseau, ou si l'utilisateur doit intervenir pour modifier les autorisations. La bibliothèque cliente Pub/Sub relance les erreurs temporaires en utilisant les paramètres spécifiés dans les paramètres de nouvelle tentative. Ces paramètres contrôlent le comportement de l'intervalle exponentiel entre les tentatives lors des tentatives de RPC de publication 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, vous pouvez être amené à ajuster ces valeurs dans certains cas.

Les deux propriétés que vous souhaiterez probablement ajuster sont le délai avant expiration initial du RPC et le délai avant expiration total. Le délai avant expiration du RPC initial correspond au temps dont dispose le premier RPC de publication. Si un RPC échoue ou dépasse le délai, un autre est essayé avec un délai plus long jusqu'à ce que le nombre total de requêtes ou le délai d'expiration total soit dépassé.

Le délai avant expiration initial peut être ajusté si votre éditeur est limité par le réseau ou éloigné du centre de données Google Cloud 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 résulter d'une exécution intensive d'autres services sur la même machine. Si le délai avant expiration défini est trop court, les RPC initiaux pourraient échouer à plusieurs reprises, ce qui nécessiterait davantage de tentatives (avec des délais d'expiration plus longs) pour réussir la publication. La nécessité répétée de nouvelles tentatives augmente la latence de publication. Dans ce cas, l'augmentation du délai d'expiration initial peut accélérer les publications.

Si la connexion réseau n'est pas fiable, il peut être utile d'augmenter le délai d'expiration total ainsi que le délai d'expiration initial. Un délai d'expiration total plus élevé donne au RPC de publication plus de temps pour se terminer avec succès. Lorsque les RPC de publication échouent systématiquement avec des erreurs de dépassement de délai, envisagez de régler ces valeurs.

Des erreurs continues de dépassement du délai 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 résistent aux pics de trafic entrant qui génèrent davantage de messages à envoyer à Pub/Sub. Une augmentation importante des requêtes sortantes peut surcharger le processeur, la mémoire ou la capacité du réseau de l'éditeur. Lorsque la publication est surchargée, elle n'est pas en mesure de traiter les requêtes ou les réponses de publication avant l'expiration du délai. Cela se traduit par encore plus de requêtes de publication et, à terme, par le délai avant expiration total. Le contrôle de flux de diffuseur limite le nombre de messages ou d'octets en attente sans réponse de la requête de publication. Cette manière de limiter le nombre de requêtes permet de maintenir l'utilisation des ressources à un niveau gérable, même pendant les 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 une réponse aux appelants de votre service en faisant en sorte que le contrôle de flux renvoie une erreur lorsque la capacité est atteinte. Vous configurez la manière dont la bibliothèque cliente de l'éditeur répond avec le comportement de dépassement de limite.

Affiner les abonnés

Le réglage des abonnés peut également être nécessaire pour garantir leur bon fonctionnement. Comme pour les éditeurs, vous pouvez ajuster les paramètres de contrôle de flux des abonnés pour éviter qu'ils ne soient surchargés. La bibliothèque cliente de l'abonné utilise le flux pull, où le client ouvre un flux persistant sur le serveur, et le serveur envoie des messages dès qu'ils sont disponibles. En cas d'augmentation importante 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, le nombre de messages non confirmés en attente simultanément au client est limité. Cela permet de réduire le nombre de messages traités simultanément et d'étendre leur traitement sur une période plus longue. La répartition de la charge permet aux abonnés de rester sous les limites de ressources affectant le traitement des messages, ce qui peut entraîner un effet en cascade qui se traduit par l'incapacité à traiter des messages.

Le contrôle de flux à lui seul est suffisant si vous vous attendez uniquement à des pics de la quantité de données à traiter, qui finissent par disparaître. Si le trafic augmente généralement au fil du temps en raison d'une utilisation plus importante, le contrôle de flux protège les abonnés. Toutefois, cela peut entraîner une accumulation en attente et empêcher la distribution des messages avant la fin 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 à l'augmentation du nombre de messages non confirmés. La configuration dépend de la plate-forme de calcul que vous utilisez pour vos abonnés. Par exemple, l'autoscaler de Compute Engine vous permet d'effectuer un scaling en fonction de métriques telles que le nombre de messages non distribués. L'utilisation à la fois 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 de débit de messages et à une croissance à plus long terme qui nécessite plus de puissance de calcul. Veillez à suivre les bonnes pratiques concernant l'utilisation des métriques Pub/Sub en tant que signal de scaling.

Utiliser l'instantané et rechercher des déploiements sécurisés

La perte de messages est généralement un événement catastrophique. Pub/Sub propose une distribution de type "au moins une fois" pour tous les messages publiés. Cependant, le traitement correct de ces messages dépend du comportement de l'abonné. Si les messages sont confirmés, Pub/Sub ne les redistribue pas. Par conséquent, un bug introduit dans un nouveau code d'abonné que vous déployez qui accuse réception des messages sans les traiter correctement peut entraîner une perte de messages due à l'abonné. Pub/Sub propose la fonctionnalité d'instantané et de recherche, qui peut vous aider à traiter chaque message correctement, même en cas de bugs des abonnés.

Le modèle de déploiement de chaque déploiement d'abonné doit se présenter comme suit:

Le temps d'attente avant de déterminer si le nouvel abonné fonctionne peut varier en fonction de votre cas d'utilisation. Le seul moyen de quitter le flux d'étapes est lorsqu'un abonné est considéré comme fonctionnel. L'instantané peut alors être supprimé.

L'utilisation des instantanés et de la recherche n'est pas destinée à remplacer les bonnes pratiques concernant la première exécution du logiciel dans un environnement hors production et le déploiement progressif en production. Elles offrent un niveau de protection supplémentaire pour garantir un traitement fiable des données. En contrepartie, la recherche de l'instantané peut entraîner la distribution en double des messages que votre abonné a traités avec succès. Toutefois, étant donné que Pub/Sub applique par défaut la sémantique de distribution "au moins une fois", vos abonnés sont déjà résilients à la redistribution des messages.