Ce guide présente les fonctionnalités de fiabilité de Pub/Sub et offre une vue d'ensemble de leur fonctionnement. Ce document traite des sujets suivants:
- Pourquoi Pub/Sub ?
- Basculement
- Optimiser les éditeurs
- Optimiser vos abonnés
- Utiliser l'instantané et la recherche pour des déploiements sécurisés
Pourquoi Pub/Sub ?
En tant que paradigme de messagerie, la fonction publication/abonnement est conçue pour dissocier les producteurs de messages des consommateurs de ces messages. Au lieu que les producteurs envoient des requêtes directes aux consommateurs avec les données, ils publient ces données dans un service Pub/Sub tel que Pub/Sub. Le service distribue ces messages de manière asynchrone aux consommateurs intéressés qui se sont abonnés.
Le service absorbe donc toutes les subtilités de la recherche des consommateurs intéressés par les données. Le service gère également le taux auquel les consommateurs reçoivent les données en fonction de leur capacité. La 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 distribution des messages hautement évolutive et fiable. Bien que le service gère une grande partie de ces opérations automatiquement, 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 décrit ces aspects.
Basculement
Pub/Sub est un service global: 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. Lorsqu'ils utilisent 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 dans laquelle Pub/Sub s'exécute. Lorsqu'ils utilisent les points de terminaison de localisation, 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 de localisation 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 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 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 ont une capacité suffisante pour recevoir des messages, le flux de messages se présente comme suit:
Les P représentent les éditeurs, les S représentent 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 des messages dans la région où ils ont été publiés, lorsque les abonnés sont disponibles. Sinon, elle envoie les messages à la région la plus proche du réseau avec des abonnés disposant d'une capacité suffisante. Par conséquent, comme illustré dans 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
Supposons que les abonnés en Europe aient été désactivés ou plantent fréquemment, et ne parviennent pas à maintenir une connexion à Pub/Sub. Dans ce cas, le service commencera à distribuer des messages aux abonnés situé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 que les abonnés se reconnectent, les messages sont distribués, sauf si l'indisponibilité dépasse la durée de conservation des messages configurée. Par défaut, la conservation des messages des abonnements est définie sur sept jours. Vous pouvez également configurer la conservation des messages pour un thème pendant 31 jours maximum. Ne choisissez pas une durée de conservation des messages inférieure à la panne maximale attendue 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 des 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 lors des requêtes de publication ou d'abonnement, ou l'impossibilité de distribuer des messages publiés aux abonnés. Par exemple, si Pub/Sub était en panne dans la région Europe, le scénario est semblable à celui d'une panne d'abonnés:
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 n'effectue pas de basculement automatique intentionnellement. Imaginez que ce soit les abonnés eux-mêmes qui causent un problème inattendu dans Pub/Sub, ce 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 sont connectés. Si le service leur permet de basculer vers une autre région, les abonnés peuvent également provoquer une indisponibilité dans celle-ci, entraînant des défaillances en cascade du service.
Les éditeurs en Australie ne sont pas disponibles
Si les éditeurs d'une région ne sont plus disponibles, 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 réduire la distance réseau. Par conséquent, les abonnés situés en Australie peuvent cesser de recevoir des messages s'ils disposent d'une capacité suffisante pour traiter tous les messages publiés aux États-Unis.
Pub/Sub n'est pas disponible aux États-Unis
Pub/Sub écrit les messages de manière synchrone dans plusieurs zones d'une région. Par conséquent, une panne de zone ne suffit pas pour empêcher la distribution des messages. La région entière doit être indisponible. Si Cloud Pub/Sub devient indisponible dans une région où les éditeurs envoient des messages, les messages de cette région risquent de ne pas être distribués tant que le service n'est pas entièrement restauré:
Le message est quand même distribué au final (en supposant que la période de conservation des messages ne soit pas écoulée), et retarde la durée de la panne. Notez que, comme pour 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 risques de défaillances en cascade dans toutes les régions en raison d'un éditeur ou d'un abonné défectueux.
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 lui-même peut affecter le flux des messages. Votre cas d'utilisation peut nécessiter différents niveaux d'isolation. Par exemple, vous pouvez exiger la 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 est suffisante. Vous devez créer un seul sujet et un seul abonnement, et placer les éditeurs et les 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 est basculée vers les abonnés d'une autre région.
Pour l'isolation régionale, où les données ne quittent pas une région, créez un sujet et un abonnement pour gérer les messages dans chaque région. Localisez les éditeurs et les abonnés dans chacune de ces régions, et demandez-leur de publier et de s'abonner au sujet régional correspondant et à l'abonnement, respectivement. 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 des 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 des 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 entièrement que les messages peuvent toujours circuler des éditeurs vers les abonnés en cas de panne entre les deux. Des pannes peuvent se produire à plusieurs endroits, y compris au niveau de vos clients, dans le service sur lequel vos éditeurs ou vos abonnés s'exécutent, sur le réseau, ou même rarement dans Pub/Sub. 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, chacune utilisant un point de terminaison de localisation différent.
Vous pouvez souhaiter que votre entreprise soit résiliente face à deux portées d'impact différentes: zonale ou régionale. Voici les options de configuration disponibles pour chacune d'entre elles.
Résilience zonale
Pub/Sub intègre une réplication interzones. Vous n'avez pas besoin de prendre de mesures spéciales pour gérer les pannes d'une seule zone qui affectent le service lui-même. Toutefois, pour bénéficier d'une résilience aux pannes de vos clients ou de votre réseau, il est préférable de faire fonctionner les éditeurs et les abonnés avec 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 les modifications simultanément sur ces clients, afin que si un bug soit introduit, 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 pour vos éditeurs et abonnés. Vous pouvez gérer les éditeurs et les abonnés dans plusieurs régions pour gérer les éventuelles pannes dans ces clients ou dans la mise en réseau.
Si vous souhaitez être résilient contre les défaillances Pub/Sub potentielles dans une région, vous devez disposer d'un mécanisme de basculement prêt à gérer une telle panne. Les approches possibles constituent un compromis entre la latence de distribution des messages de bout en bout et votre coût.
Pour minimiser la latence au cas où le coût ne serait pas un problème, la meilleure stratégie consiste à toujours publier et s'abonner simultanément dans des régions différentes. Tout d'abord, choisissez le nombre de régions dans lesquelles vous souhaitez créer 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 d'éditeur qu'il existe de régions (un pour chaque région) et utilise un point de terminaison de localisation différent pour s'assurer que les messages sont dirigé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, les appels de l'éditeur sont publiés sur chaque client. Avec les publications redondantes, il n'est pas nécessaire de relancer les publications en cas d'échec de l'une d'entre elles.
De même, chaque abonné crée ce nombre 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 des messages sur les trois abonnements et les traitent.
Cette configuration présente plusieurs fonctionnalités et exigences clés:
- L'indisponibilité d'une région unique n'affecte pas le traitement des messages déjà publiés, ni de ceux publiés au cours de l'interruption. Comme les messages ont été publiés dans plusieurs régions, ils restent disponibles dans d'autres régions en cas de panne d'une région. Pendant cette période, 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 que l'une des régions dans lesquelles les messages transitent est disponible.
- 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 fois que le message a été distribué. Ces doublons provenaient probablement d'une autre région qui n'a pas subi de panne.
L'exécution avec ce type de redondance offre la plus haute résilience à tous les types de pannes. 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 : le coût de distribution des messages est multiplié par le nombre de régions utilisées. En outre, cela entraîne des coûts supplémentaires liés à l'utilisation du réseau interrégional pour les messages devant être déplacés entre régions.
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 vos abonnés via des points de terminaison géographiques. Comme précédemment, il ne doit pas nécessairement s'agir de 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 les requêtes dans la région principale (via le point de terminaison de localisation) lorsque leurs requêtes ont bien été envoyées. Chaque fois que la région est indisponible, les éditeurs commencent à publier dans la région de remplacement. Il existe deux façons de déterminer si la région est indisponible et en basculement. Cela peut être effectué par un processus manuel et la configuration est mise à jour de manière dynamique chez les éditeurs. Les éditeurs peuvent également mettre à jour la configuration eux-mêmes si le taux d'erreur dans les requêtes 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 remplacement avec un ou plusieurs des déclencheurs suivants:
- Abonnez-vous toujours à la région de remplacement. Dans ce cas, l'abonné reste connecté à la région principale et à la région de remplacement en permanence. 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 qu'en cas de basculement de l'éditeur.
- Détectez manuellement les abonnés et basculez-les vers la région de remplacement via une configuration. Si vous détectez une panne, vous pouvez basculer vers la région de remplacement, puis revenir à la région principale une fois la panne résolue.
- Basculement en cas d'erreur d'abonné. Si les requêtes d'abonné renvoient des erreurs, cela peut vous indiquer que vous devez basculer vers la région de remplacement. Notez que les bibliothèques clientes Pub/Sub relancent la diffusion des demandes d'extraction en interne en cas d'erreurs temporaires. Vous risquez donc de ne pas pouvoir détecter de longues périodes d'erreurs inattendues. De plus, le taux d'erreur d'extraction en flux continu devrait être de 100%, même en fonctionnement normal.
- Basculement si l'abonné traverse une longue période inattendue sans recevoir de messages. En supposant que les messages sont publiés de manière cohérente, les abonnés peuvent toujours recevoir des messages. S'ils ne reçoivent aucun message pendant une longue période, il peut y avoir un problème côté abonnement dans Pub/Sub dans la région principale. Ce problème peut être résolu en basculant vers la région de remplacement.
Parmi les quatre options possibles, la première est idéale. La connexion d'un abonné n'entraîne aucuns frais si aucun message n'y est acheminé. Le seul coût facturé concerne 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 nombre de connexions pull ouvertes en flux continu par région.
L'avantage de ce second 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. En contrepartie, pour certains types de pannes, il est possible que les messages publiés avant le début de la panne ne soient disponibles qu'une fois la panne résolue. Les messages stockés dans la région indisponible risquent de ne pas être distribués aux abonnés, quel que soit leur emplacement de connexion. Les messages publiés pendant la panne dans la région de remplacement peuvent être disponibles. En outre, 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 délai de basculement vers la région de remplacement.
Quelle que soit l'option que vous choisissez, sachez comment elle peut interagir avec les fonctionnalités de Pub/Sub. La livraison sur commande et la livraison "exactement une fois" offrent leurs garanties dans une région. Par exemple, si vous utilisez la technique de redondance de basculement, la distribution des messages n'est garantie que si les messages sont publiés dans la même région. L'abonné peut recevoir les messages publiés dans la région de remplacement avant ceux publiés dans la région principale, même s'ils ont d'abord été publiés dans la région principale.
Optimiser les éditeurs
Quelle que soit l'option de basculement choisie, vous devez effectuer des étapes de réglage supplémentaires au sein des éditeurs eux-mêmes. Le réglage du comportement des éditeurs permet d'optimiser les performances en cas de charge importante. Le traitement par lot des messages permet de réduire la latence au détriment des coûts. Cependant, ce n'est pas vraiment un problème de fiabilité et n'est donc pas abordé ici. Concentrez-vous plutôt sur d'autres paramètres utiles à l'optimisation de la fiabilité, tels que les paramètres de nouvelle tentative et les paramètres de contrôle de flux.
Les publications peuvent échouer pour différentes raisons, y compris des événements temporaires tels que l'indisponibilité du réseau ou des problèmes nécessitant une intervention de l'utilisateur, comme des modifications d'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 en cas d'échec de la publication de RPC pour des raisons temporaires. Bien que les paramètres par défaut puissent généralement fonctionner dans la plupart des cas, il peut être utile d'ajuster ces valeurs dans certains cas.
Les deux propriétés que vous souhaiterez probablement régler sont le délai avant expiration RPC initial et le délai avant expiration total. Le délai avant expiration initial du RPC correspond au délai dont dispose le premier RPC de publication. Si un RPC échoue ou expire, un autre est essayé avec un délai d'expiration plus long, jusqu'à ce que le nombre total de requêtes ou le délai avant expiration total soit dépassé.
Le délai avant expiration initial peut être réglé si votre éditeur est limité par le réseau ou s'il est éloigné du centre de données Google Cloud le plus proche qui exécute Pub/Sub. Les contraintes réseau peuvent être des limites du débit de la machine sur laquelle l'éditeur s'exécute ou être le résultat d'autres services gourmands en réseau, qui s'exécutent sur cette même machine. Avec un délai d'inactivité défini trop court, les RPC initiaux peuvent échouer à plusieurs reprises, ce qui nécessiterait davantage de tentatives (avec des délais d'inactivité plus longs) pour réussir la publication. Le besoin répété de nouvelles tentatives augmente la latence de publication. Dans ce cas, l'augmentation du délai 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 avant expiration total plus long donne au RPC de publication plus de temps pour se terminer correctement. Lorsque les RPC de publication échouent systématiquement avec des erreurs de dépassement du délai, envisagez de régler ces valeurs.
Les 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 résistent aux pics de trafic entrant qui génèrent davantage de messages à envoyer à Pub/Sub. Une augmentation importante des requêtes sortantes pourrait surcharger la capacité du processeur, de la mémoire ou du réseau de l'éditeur. Lorsque la publication est surchargée, elle n'est pas en mesure de traiter les requêtes de publication ni les réponses avant l'expiration des délais. Cela se traduit par encore plus de requêtes de publication et, au final, par l'atteinte du délai avant expiration total. Le contrôle de flux de l'éditeur limite le nombre de messages ou d'octets pouvant être en attente sans réponse de la requête de publication. En limitant le nombre de requêtes de cette manière, vous pouvez utiliser les ressources à un niveau gérable, même pendant les pics. Selon le fonctionnement de votre éditeur, vous pouvez autoriser les RPC de publication suivants à attendre la capacité en autorisant la publication à bloquer d'autres requêtes. Vous pouvez également répondre 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 réponse de la bibliothèque cliente de l'éditeur avec le comportement de dépassement de limite.
Optimiser vos abonnés
Il peut également être nécessaire d'ajuster le réglage des abonnés pour s'assurer qu'ils fonctionnent de manière fiable. Comme pour les éditeurs, vous pouvez ajuster les paramètres de contrôle de flux des abonnés pour éviter qu'ils ne soient submergés. La bibliothèque cliente de l'abonné utilise le streaming en mode 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é risque de 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 du client à un moment donné est limité. Cela réduit le nombre de messages traités simultanément et avance leur traitement sur une période plus longue. Cette répartition permet aux abonnés de respecter les limites de ressources qui affectent le traitement des messages, ce qui peut entraîner un effet en cascade qui se développe jusqu'à l'incapacité de traiter des messages.
Le contrôle de flux à lui seul suffit si vous vous attendez uniquement à ce que des pics de la quantité de données à traiter diminuent. 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, il se peut qu'un volume de messages en attente continue de s'accumuler et que les messages ne puissent pas être distribués avant l'expiration de leur durée de conservation. Dans ce cas, vous pouvez également définir 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 face à d'autres pics à court terme de débit de messages et à une croissance à plus long terme qui nécessite davantage de puissance de calcul.
Utilisez 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 une distribution de type "au moins une fois" pour tous les messages publiés. Cependant, le traitement approprié de ces messages dépend du comportement de l'abonné. Si les messages sont bien confirmés, Pub/Sub ne les redistribue pas. Par conséquent, un bug introduit dans le nouveau code d'abonné que vous déployez et qui confirme la réception des messages sans les avoir traités correctement peut entraîner une perte de messages causée par l'abonné. Pub/Sub propose la fonctionnalité Instantané et recherche qui peut vous aider à traiter chaque message correctement, même en cas de bugs d'abonnés.
Le modèle de chaque déploiement d'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. Le seul moyen de quitter le flux d'étapes est lorsque l'abonné est considéré comme étant opérationnel, auquel cas l'instantané peut être supprimé.
L'utilisation de la fonctionnalité d'instantané et de recherche n'a pas pour vocation de remplacer les bonnes pratiques concernant l'exécution du premier 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 bien traités. Toutefois, étant donné que Pub/Sub utilise par défaut la sémantique de distribution "au moins une fois", vos abonnés sont déjà résilients à la redistribution des messages.