Ce guide présente les fonctionnalités de fiabilité de Pub/Sub et offre une vue d'ensemble. Voici les sujets abordés dans ce document:
- Pourquoi Pub/Sub ?
- Basculement
- Affiner les éditeurs
- Affiner les abonnés
- Utiliser des instantanés et rechercher des déploiements sécurisés
Pourquoi Pub/Sub ?
En tant que paradigme de messagerie, le modèle publication/abonnement est conçu 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 les publient 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 ainsi toutes les subtilités de la recherche de consommateurs intéressés par les données. Le service gère également le débit auquel les consommateurs reçoivent les données, en fonction de leur capacité. Le 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 une grande partie de ces éléments automatiquement, vous pouvez contrôler 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.
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 entre les régions dans le service Pub/Sub si nécessaire. Lorsque vous utilisez le point de terminaison global, pubsub.googleapis.com, les éditeurs et les abonnés se connectent à la région réseau la plus proche où Pub/Sub s'exécute. Lorsque vous utilisez des points de terminaison géographiques, 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 exécutez des éditeurs ou des abonnés en dehors de Google Cloud, il est préférable d'utiliser des points de terminaison géographiques afin de garantir un flux de messages cohérent entre les régions attendues. Le reste de cette section explique comment créer des sujets et des abonnements. En outre, nous expliquons 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 seul sujet et d'un seul abonnement. Les éditeurs se trouvent dans des régions des États-Unis et de l'Australie, et les abonnés se trouvent dans les régions Google Cloud d'Europe et d'Australie. Si 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, 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 (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 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 disposant de capacité. 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 qu'ils plantaient fréquemment et qu'ils ne pouvaient pas maintenir une connexion à Pub/Sub. Dans ce cas, le service commencerait à envoyer 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 que les abonnés se sont reconnectés, 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 définie sur sept 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 que vous prévoyez ou que vous êtes prêt à tolérer.
Pub/Sub n'est pas disponible en Europe
Bien que rare, vous devrez peut-être également gérer les cas où Pub/Sub lui-même n'est pas disponible. 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'impossibilité de distribuer les 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 des abonnés en panne:
Notez que dans ce cas, les abonnés en Europe ne sont pas redirigés vers une autre région, même s'ils utilisent le point de terminaison global. Pub/Sub ne bascule pas automatiquement de manière intentionnelle. Imaginons que ce soient les abonnés eux-mêmes qui provoquent un problème inattendu dans Pub/Sub, ce qui entraîne une indisponibilité. Ce problème est traité comme une panne majeure. Toutefois, l'impact de la panne peut se limiter à 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 dans l'ensemble du service.
Les éditeurs situés en Australie ne sont pas disponibles
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 essaie 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 en Europe 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 des messages dans plusieurs zones d'une même région. Par conséquent, une panne zonale n'est pas suffisante pour empêcher la distribution des messages. L'ensemble de la région doit être indisponible. Si Cloud Pub/Sub devient indisponible dans une région où des é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 rétabli:
Le message est toujours distribué (en supposant que la période de conservation des messages n'est pas terminée), avec un retard correspondant à la durée de l'indisponibilité. Notez que, comme pour les abonnés, les éditeurs situés aux États-Unis ne sont pas redirigés vers une autre région en cas de défaillance 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.
Isolation
La sémantique de basculement par défaut décrite affecte l'isolation des données et la façon dont l'indisponibilité des éditeurs, des abonnés ou de Pub/Sub lui-même peut affecter le flux de 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 aucune isolation, la sémantique de basculement par défaut détaillée est suffisante. Vous devez créer un seul sujet, un seul abonnement, et placer les éditeurs et les abonnés dans toutes les régions sélectionnées. Si les abonnés ne sont plus disponibles ou si Pub/Sub est indisponible dans la région à laquelle ils se connectent, la distribution est transférée vers les abonnés d'une autre région.
Pour l'isolation régionale, où les données ne quittent jamais une région, 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 au sujet et à l'abonnement régionaux correspondants, 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 de défaillance d'un éditeur, d'un 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 d'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 ne garantit pas toujours que les messages peuvent toujours circuler des éditeurs vers les abonnés en cas d'indisponibilité à un moment donné. Les pannes peuvent se produire à plusieurs 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 face à 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 éditeur et abonné, chacun utilisant un point de terminaison géographique différent.
Vous pouvez choisir de vous assurer de la résilience à deux niveaux d'impact différents: zonal ou régional. Voici les options de configuration pour chacune d'elles.
Résilience zonale
Pub/Sub dispose d'une réplication interzone intégrée. Aucune mesure particulière n'est requise pour gérer les pannes affectant une seule zone et le service lui-même. Toutefois, pour assurer la résilience des pannes pour vos clients ou votre réseau, il est préférable d'exécuter des éditeurs et des 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 simultanément les modifications apportées à ces clients afin que, en cas d'introduction d'un bug, les autres zones non modifiées puissent 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 aux pannes potentielles dans ces clients ou dans la mise en réseau.
Si vous souhaitez être résilient face aux défaillances potentielles de Pub/Sub dans une région, vous devez disposer d'un mécanisme de basculement prêt à gérer une telle panne. Les approches possibles sont un compromis entre la latence de diffusion des messages de bout en bout et vos coûts.
Pour minimiser la latence si les coûts ne sont 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 la 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 y a 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 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 réessayer les publications si l'une d'elles échoue.
De même, chaque abonné crée autant de clients d'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 des messages sur les trois abonnements et les traitent.
Cette configuration présente plusieurs fonctionnalités et exigences clés:
- Toute panne limitée à une seule région n'affecte pas le traitement des messages déjà publiés ni ceux publiés pendant la panne. Étant donné que les messages ont été publiés dans plusieurs régions, ils sont toujours disponibles dans d'autres régions en cas de panne d'une région. Pendant la panne, les appels de publication échouent dans la région affectée, mais aboutissent dans les autres.
- La latence de traitement des messages n'est pas affectée tant qu'une des régions par lesquelles les messages circulent est disponible.
- Le traitement des messages doit être idempotent. Étant donné que chaque message sera diffusé plusieurs fois, le traitement des messages doit être résilient aux doublons. En cas d'indisponibilité régionale, certains de ces doublons peuvent arriver bien plus tard que la première fois que le message a été envoyé. Ces doublons proviennent probablement d'une autre région qui ne connaît pas de panne.
L'exécution avec ce type de redondance offre la résilience la plus élevée à tout type d'indisponibilité. Pour les services Google internes qui reposent sur Pub/Sub et qui nécessitent la disponibilité la plus élevée, cette configuration est préférable. Toutefois, cette configuration implique de multiplier le coût de distribution des messages par le nombre de régions utilisées. Il existe également des coûts supplémentaires liés à l'utilisation du réseau interrégional pour les messages qui doivent être transférés entre les régions.
Une autre approche de la redondance consiste à ne passer à un autre système que lorsque les requêtes échouent ou que les messages ne transitent pas des éditeurs vers les 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, il n'est pas nécessaire qu'il s'agisse 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 est indisponible.
Les éditeurs ne publient que dans la région principale (via le point de terminaison géographique) lorsque leurs requêtes sont envoyées avec succès. Chaque fois qu'une région est déterminée comme étant indisponible, les éditeurs commencent à publier dans la région de remplacement. Il existe deux façons de déterminer que la région est en panne et que la bascule a été effectuée. Cela peut être effectué par un processus manuel, et la configuration est mise à jour dynamiquement dans les éditeurs. Les éditeurs peuvent également mettre à jour la configuration eux-mêmes si le taux d'erreurs 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 géographique. 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é maintient une connexion à la fois à la région principale et à la région de remplacement en permanence. Les mêmes régions peuvent être utilisées pour les régions principales et de remplacement, à la fois 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 effectué un basculement.
- 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 terminée.
- Failover en cas d'erreurs d'abonné. Si les requêtes des abonnés renvoient des erreurs, vous pouvez considérer que vous devez basculer vers la région de remplacement. Notez que les bibliothèques clientes Pub/Sub réessayent les requêtes pull en streaming en interne en cas d'erreurs temporaires. Vous ne pourrez donc peut-être pas détecter de longues périodes d'erreurs inattendues. De plus, le taux d'erreur de la récupération en streaming devrait être de 100%, même en fonctionnement normal.
- Défaillance si l'abonné passe un temps inattendu sans recevoir de messages. En supposant qu'il y ait une publication cohérente des messages, les abonnés peuvent toujours recevoir des messages. S'ils passent une longue période sans recevoir de messages, il se peut qu'il y ait un problème côté abonné dans Pub/Sub dans la région principale. Pour résoudre ce problème, passez à la région de remplacement.
Parmi les quatre options, la première est idéale. Une connexion d'abonné ne coûte rien si aucun message ne circule dessus. Le seul coût est lié à 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 de Pub/Sub, car les messages ne sont publiés qu'une seule fois. Toutefois, pour certains types d'indisponibilités, les messages publiés avant le début de l'indisponibilité peuvent ne pas être disponibles avant la résolution du problème. 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 l'endroit où ils sont connectés. 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 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 temps de basculement vers la région de remplacement.
Quelle que soit l'option choisie, tenez compte de son interaction avec les fonctionnalités de Pub/Sub. La distribution ordonnée et la distribution de type "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 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 si les messages ont été publiés dans la région principale en premier.
Affiner les éditeurs
Quelle que soit l'option de basculement que vous choisissez, vous devez effectuer quelques étapes de réglage supplémentaires au niveau des éditeurs. L'ajustement du comportement des éditeurs garantit des performances optimales en cas de charge élevée. Le groupement des messages permet de réduire la latence en échange d'une réduction des coûts, mais n'est pas vraiment un problème de fiabilité. Il 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 du flux.
Les publications peuvent échouer pour diverses raisons, y compris des raisons temporaires telles que l'indisponibilité du réseau ou des raisons nécessitant l'intervention de l'utilisateur, comme les modifications d'autorisations. La bibliothèque cliente Pub/Sub réessaie 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 l'intervalle exponentiel entre les tentatives lors des nouvelles tentatives des 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, il peut être nécessaire d'ajuster ces valeurs dans certaines situations.
Les deux propriétés que vous souhaitez probablement ajuster sont le délai avant expiration RPC initial et le délai avant expiration total. Le délai RPC avant expiration initial correspond au délai d'exécution du premier RPC de publication. Si un RPC échoue ou expire, un autre est tenté avec un délai avant 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 affiné si votre éditeur est soumis à des contraintes réseau ou s'il se trouve loin du centre de données Google Cloud le plus proche qui exécute Pub/Sub. Les contraintes réseau peuvent être des limites sur le débit de la machine sur laquelle l'éditeur s'exécute ou le résultat d'autres services exécutés sur la même machine qui sont gourmands en réseau. Si le délai avant expiration est défini trop court, les RPC initiales peuvent échouer à plusieurs reprises, ce qui nécessite davantage de tentatives (avec des délais avant 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, augmenter le délai avant 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 avant expiration total et le délai avant expiration initial. Un délai avant expiration total plus long permet au RPC de publication de s'exécuter plus longtemps. Lorsque les RPC de publication échouent de manière cohérente avec des erreurs de délai dépassé, envisagez d'ajuster ces valeurs.
Les erreurs de délai dépassé continu lors de la publication peuvent également indiquer que vous devez ajuster le contrôle du 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 la publication est surchargée, elle ne peut pas traiter les requêtes ou les réponses de publication avant les délais avant expiration. Cela entraîne encore plus de requêtes de publication et, en fin de compte, le délai avant expiration total est atteint. 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, l'utilisation des ressources reste à un niveau gérable, même en cas de 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 renvoyer 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 avec le comportement de dépassement de la limite.
Affiner les abonnés
Un réglage des abonnés peut également être nécessaire pour garantir leur fonctionnement fiable. Comme les éditeurs, vous pouvez ajuster les paramètres de contrôle de flux des abonnés pour vous assurer qu'ils ne sont pas submergés. La bibliothèque cliente d'abonné utilise le pull de streaming, où le client ouvre un flux persistant vers le serveur et que le serveur envoie des messages à mesure qu'ils deviennent 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 en place, le nombre de messages non confirmés en attente auprès du client à un moment donné est limité. Cela réduit le nombre de messages gérés simultanément et répartit leur traitement sur une période plus longue. Répartir la charge permet aux abonnés de rester en dessous de toute limite de ressources qui affecte le traitement des messages, ce qui peut entraîner un effet en cascade qui se traduit par l'impossibilité de traiter des messages.
Le contrôle de flux seul est suffisant si vous ne prévoyez que des pics de la quantité de données à traiter qui finiront 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 arriéré qui continue de s'accumuler et empêcher 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 procédure à suivre dépend de la plate-forme de calcul que vous utilisez pour vos abonnés. Par exemple, l'outil d'autoscaling de Compute Engine vous permet de faire évoluer votre application 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 face à d'autres pics à court terme du débit des messages et à une croissance à plus long terme qui nécessite plus de puissance de calcul.
Utiliser des instantanés et rechercher des déploiements sécurisés
La perte de messages est généralement un événement catastrophique. Pub/Sub offre une 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 accusés de réception, Pub/Sub ne les redélivre pas. Par conséquent, un bug introduit dans le nouveau code d'abonné que vous déployez qui confirme la réception de messages sans les avoir correctement traités 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 actif, auquel cas l'instantané peut être supprimé.
L'utilisation d'instantanés et de recherche n'a pas pour but de remplacer les bonnes pratiques concernant l'exécution initiale du logiciel dans un environnement hors production et le déploiement progressif en production. Elles fournissent un niveau de protection supplémentaire pour garantir le traitement fiable des données. En revanche, la recherche dans 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 une sémantique de distribution "au moins une fois", vos abonnés sont déjà résilients à la nouvelle distribution des messages.