Messagerie Pub/Sub en cache : présentation
Ce paradigme de messagerie Publish/Subscribe (Pub/Sub) fournit un canal intermédiaire (appelé sujet) pour échanger des messages entre plusieurs applications sans aucune connaissance de l'expéditeur (éditeur) et du destinataire (abonné). Une application d'éditeur envoie des messages à une application d'abonné par le biais de rubriques.
Étant donné que tous les modèles Pub/Sub nécessitent un canal de communication, NCache agit comme un support pour les sujets afin que l'éditeur publie le message sur le sujet. Les abonnés reçoivent le message via le sujet sous forme de notification. Utilisant NCache en tant que support pour les sujets assure un couplage lâche au sein du modèle et permet une abstraction accrue, offrant des avantages supplémentaires aux sujets distribués.
Outre un cache distribué, NCache propose également un espace dédié Cache de messagerie Pub/Sub.
Important
Nous recommandons un cache Pub/Sub dédié pour les raisons suivantes :
Expulsion: Si le cache contient des messages et des éléments de cache, l'éviction fréquente des éléments de cache peut également supprimer les messages avant de les transférer à l'abonné.
Transfert d'État: Le transfert d'état ajoute un coût à chaque opération d'élément de cache. Étant donné que les messages sont fréquemment publiés, relayés et expirés, cette activité récurrente peut s'avérer coûteuse car elle déclenche un transfert d'état.
Pourquoi la messagerie Pub/Sub est importante
Les événements en temps réel nécessitent le partage des notifications entre différentes applications dans des architectures distribuées pilotées par les événements. Les modèles Pub/Sub permettent aux éditeurs de partager des événements avec les abonnés afin que tout traitement souhaité ait lieu lors de l'occurrence d'un événement d'intérêt.
Par exemple, un groupe d'abonnés peut être intéressé par des informations sur les détails de l'expédition d'une commande afin de pouvoir les traiter pour suivre la livraison de la commande. Ainsi, ils s'abonneront à un sujet qui relaie les messages pour les détails des commandes. Une fois que l'éditeur publie un message sur le sujet, les abonnés seront avertis et recevront le message contenant les détails de la commande pour un traitement ultérieur de leur côté.
Composants Pub/Sub
Les composants de base du NCache Le modèle d'abonné de l'éditeur est répertorié ci-dessous et discuté en détail ultérieurement :
Topic: Un endroit où les messages sont publiés.
Editeur: Une application (application Web, applications de bureau, microservices) qui publie des messages sur le ou les sujets
Abonné: Une application intéressée à recevoir des messages de sujets/sujets.
Abonnement: Entité d'intérêt créée pour qu'un abonné reçoive les messages prévus.
Message: L'objet de données réel que l'éditeur envoie et que les abonnés reçoivent via le sujet.
Sujet
L'éditeur publie des messages sur le sujet. Les abonnés s'abonnent au sujet pour recevoir le message. Cette rubrique existe sous une forme distribuée dans NCache. Par conséquent, sa création se produit sur tous les nœuds du cluster. Il contient le magasin de messages, qui stocke les objets de données réels que l'éditeur publie dans une file d'attente. Il maintient également en interne une liste de tous les abonnés qui y souscrivent et une liste des éditeurs.
La ITopic/Topic
l'interface facilite création de sujet, sujet obteniret suppression de sujet. Vous pouvez également supprimer un sujet de manière asynchrone pour éviter d'attendre qu'un sujet soit supprimé.
Notes
La nature distribuée des sujets et des messages sous-jacents améliore l'évolutivité.
Une fois qu'un message est publié dans le sujet, il déclenche un événement, que le sujet relaie aux abonnés en fonction de la préférence de possibilité de remise des messages afin qu'ils puissent recevoir le message au besoin. La figure suivante illustre le rôle d'un sujet en tant que canal intermédiaire pour les éditeurs et les abonnés :
Notes
En cas de déconnexion temporaire de l'abonné puis de reconnexion automatique, toutes les informations liées à un sujet tel que les abonnements et les notifications d'événements de défaillance sont réenregistrées dans le sujet sans aucune interruption du côté de l'abonné.
Priorité du sujet
NCache introduit la priorité au niveau des sujets qui vous aide à hiérarchiser les sujets les moins prioritaires et les plus prioritaires en fonction de leur importance. Vous pouvez créer des sujets avec une priorité plus élevée s'ils doivent publier des messages critiques. Ainsi, ces messages sont livrés en premier. De même, vous pouvez créer des sujets avec une priorité inférieure s'ils publient des messages sans importance. Le cache supprimera d'abord ces messages.
Important
La priorité d'un sujet ne peut être spécifiée qu'au moment de la création du sujet et ne peut pas être modifiée par la suite.
Vous pouvez simplement régler le priorité au niveau du sujet au moment de la création du sujet afin de prioriser la livraison des messages critiques.
Notification de suppression de sujet
Tous les messages et méta-informations associées du cache sont supprimés lors de la suppression du sujet. Ainsi, l'abonné et l'éditeur reçoivent des notifications de cette suppression pour les raisons suivantes :
- Les abonnés attendent peut-être des messages entrants provenant du sujet enregistré. Une fois le sujet supprimé, les abonnés peuvent alors gérer leur exécution en conséquence via une notification d'événement et éviter un état d'attente infini.
- L'éditeur peut éviter d'envoyer des messages à un sujet inexistant et gérer les messages en attente et les exécutions futures en conséquence.
Pour recevoir une notification de suppression de sujet, votre application s'inscrit à l'événement OnTopicDeleted.
Publier des messages dans un sujet
Un éditeur peut publier des messages dans un sujet en spécifiant un nom de sujet. Les messages peuvent être publiés de manière asynchrone et en masse pour améliorer les performances de l'application. Un cache partitionné distribue les messages sur le cluster. Pour le routage des messages, chaque message possède un identifiant unique appelé MessageID
côté éditeur, et le code de hachage de MessageID
détermine le nœud de cluster pour stocker le message.
Notes
NCache permet de publier un grand nombre de messages en un seul appel pour améliorer les performances et l'utilisation de la mémoire.
NCache permet à un éditeur d'utiliser les propriétés suivantes lors de la publication de messages.
Option de livraison des messages : Un éditeur peut décider si un message sera livré à un seul abonné ou diffusé à tous les abonnés au moment de la publication en utilisant possibilité de remise des messages.
Expiration des messages : L'éditeur peut définir l'expiration d'un message pour contrôler la durée de vie d'un message dans le cache. Nous avons couvert l'expiration plus en détail dans le Mes Messages .
Notification d'échec de livraison de message : Un éditeur peut s'inscrire à MessageDeliveryFailure pour être averti si un message particulier n'a pas été livré. Ces scénarios d'échec de livraison sont développés plus en détail dans le Affectation et livraison des messages à l'abonnement .
Important
La notification d'échec de remise de message concerne uniquement les messages avec expiration.
- Notification de suppression de sujet : Un éditeur peut s'inscrire notification de suppression de sujet pour empêcher la publication indue des messages correspondants une fois le sujet supprimé.
S'abonner à un sujet
Une application d'abonné peut s'abonner aux messages du sujet en s'inscrivant à un sujet d'intérêt par le biais d'un abonnement. Dans Pub/Sub, un abonnement représente un intérêt d'un ou plusieurs abonnés affichés dans un sujet particulier.
Notes
Si un nouveau nœud est ajouté au cluster de cache et que le transfert d'état est déclenché, tous les abonnements ainsi que les messages et les données de cache sont répliqués sur le nouveau nœud.
NCache permet de s'abonner à un sujet en fournissant un nom de sujet ou un modèle. Pour plus de détails, reportez-vous à Modalités de souscription. De plus, vous pouvez également définir mode de livraison des messages comme synchrone ou asynchrone lors de la création d'un abonnement.
NCache fournit plusieurs types d'abonnements Pub/Sub qui sont décrits ci-dessous.
Abonnement et ses types
Abonnements en NCache peuvent être classés dans les types suivants :
Résistant
Notes
Un abonnement durable est un abonnement nommé.
Dans un abonnement durable, le cache garantit que l'abonné ne manque aucun message en cas de déconnexion due à un arrêt d'application/machine, un redémarrage d'application ou une panne de réseau. Par conséquent, les abonnements durables ne souffrent pas de la déconnexion et de la reconnexion des abonnés.
Notes
Les abonnements durables ne sont pas supprimés à moins que l'abonné ne se désabonne correctement.
Si un abonné est déconnecté, les messages destinés à cet abonné sont stockés sur un serveur jusqu'à ce que l'abonné se reconnecte ou que les messages soient expirés. Les abonnements durables ne sont pas automatiquement supprimés lors de la déconnexion de l'abonné, sauf si l'abonné s'est correctement désabonné.
Un abonnement durable est en outre classé comme :
Partagé: Un abonnement partagé et durable signifie que plusieurs abonnés partagent un abonnement nommé. Les messages affectés à un abonnement partagé sont ensuite répartis entre les abonnés de manière circulaire. Même si un abonné quitte le réseau, les messages continuent d'être délivrés aux abonnés actifs. Ainsi, si un abonné quitte gracieusement ou brusquement après une affectation, ses messages affectés sont réaffectés à d'autres abonnés actifs.
Important
Un abonnement partagé n'est pris en charge que par un abonnement durable.
Dans un abonnement partagé, l'abonnement restera sur le sujet et ne pourra pas être désabonné tant que tous les abonnés ne se seront pas désabonnés. Cela signifie que tant qu'il n'y a même qu'un seul abonné actif, l'abonnement restera actif.
- Exclusif: Un abonnement durable exclusif signifie qu'il n'y a qu'un seul abonné actif enregistré sur un abonnement à la fois. Si un abonné se désabonne gracieusement, l'abonnement exclusif peut être attribué à un nouvel abonné. En cas de départ brutal d'un abonné, la nouvelle demande d'abonnement est acceptée après une attente d'un temps mort. Les messages affectés y restent toujours même s'il n'y a pas d'abonné.
Non durable
Dans un abonnement non durable, les abonnés ne reçoivent les messages qui lui sont destinés que tant qu'il reste connecté. Si l'abonné quitte le réseau, il ne recevra aucun message publié pendant sa période de déconnexion. Un abonnement non durable est exclusif par défaut.
Important
Les abonnés perdront des messages si l'abonné redémarre.
De plus, les abonnements non durables sont automatiquement supprimés lorsque l'abonné quitte le réseau. Cela signifie que si cet abonné rejoint ou établit à nouveau la connexion, cela sera considéré comme un nouvel abonnement.
Expiration de l'Abonnement Durable
Vous pouvez définir l'expiration d'un abonnement durable. Par exemple, s'il n'y a pas d'abonné actif pendant un temps significatif. Ici, les abonnements expireront après une période d'inactivité spécifique. Lorsqu'un abonnement durable arrive à expiration, les messages affectés à cet abonnement sont réaffectés en fonction de la DeliveryOption
de ces messages.
Notes
Chaque fois que l'abonné interroge ou effectue toute autre activité, le délai d'expiration de l'abonnement est réinitialisé.
Gestion des abonnements inactifs
Notes
Seuls les abonnements non durables sont marqués comme inactifs et cela ne s'applique pas aux abonnements durables.
Dans le cas où il n'y a pas d'abonné actif contre un abonnement après avoir attendu une certaine période d'inactivité, l'abonnement est considéré comme expiré. Si un abonné se reconnecte après déconnexion pendant la période d'inactivité, il pourra recevoir les messages qui lui sont assignés.
Important
Les abonnements inactifs doivent être traités pour éviter une surcharge de mémoire côté serveur.
Après avoir attendu la période d'inactivité, l'abonnement est expiré et ses messages attribués seront réaffectés à d'autres abonnements. La réaffectation des messages dépend de l'option de remise des messages.
Si le message attribué à l'abonnement A avait l'option de remise définie sur ALL et qu'il est déjà attribué à un autre abonnement B avant l'expiration de l'abonnement A, la réaffectation ne sera pas requise.
Si le message attribué à un abonnement avait une option de livraison définie sur ANY et que l'abonnement expire, les messages attribués seront toujours réaffectés à tout autre abonnement.
Message
Un message contient l'objet de données réel qui est envoyé par l'éditeur et transmis aux abonnés via le sujet. Une fois que l'éditeur publie le message sur le sujet, les abonnés enregistrés sont informés qu'un message concernant leur intérêt a été publié. En cas de messages multiples, ils sont stockés dans une séquence dans la file d'attente d'un sujet particulier.
Notes
Le même message peut être affecté à plusieurs sujets. Ceci est identifié de manière unique par un identifiant généré automatiquement.
Ici, nous discutons plus en détail de l'affectation des messages à l'abonnement, de la livraison des messages et du mécanisme d'accusé de réception.
Affectation et livraison des messages à l'abonnement
Initialement, les messages ne sont pas affectés côté serveur. Tous les abonnements reçoivent des messages selon le DeliveryOption
. Une fois qu'une attribution d'abonnement se produit, l'abonné reçoit une notification. Ensuite, l'abonné implémente un mécanisme d'interrogation pour récupérer plusieurs messages en masse - afin de réduire la surcharge côté serveur. Après avoir reçu les messages, l'abonné envoie l'accusé de réception et les messages sont considérés comme livrés.
Notes
Les messages sont stockés dans le sujet, s'il n'y a aucun abonné pour recevoir les messages. Les messages sont attribués et remis au premier abonné dès qu'il s'abonne au sujet.
Option de livraison des messages
Un éditeur doit spécifier l'option de livraison du message pour décider si le message sera délivré à un seul abonné ou diffusé à tous les abonnés au moment de la publication. Il est important de noter que la définition d’une livraison réussie dépend de l’option de livraison spécifiée.
Les deux options de livraison et les critères de livraison réussie correspondants sont décrits ci-dessous :
Tout: Tous les abonnés enregistrés reçoivent des messages. Un message est supprimé lorsque tous les abonnés l'ont reconnu.
Année: Tout abonné enregistré reçoit les messages. Si l'abonné attribué n'envoie pas d'accusé de réception, les messages sont réaffectés à l'abonné suivant. S'ils envoient un accusé de réception, les messages sont considérés comme livrés avec succès.
Notes
Si un message est remis avec succès selon l'option de remise spécifiée, il est supprimé du cache.
Stockage et distribution des messages
Voici les aspects importants du stockage et de la distribution des messages dans le cache :
Les messages sont distribués entre les nœuds en fonction des topologies.
Pour les topologies Partition-Replica et Partitioned, une distribution basée sur le hachage est utilisée.
Pour la topologie répliquée, les messages sont répliqués sur tous les nœuds du cache en cluster. Cependant, le nœud coordinateur est responsable de la manipulation des messages.
Pour la topologie miroir, les messages sont publiés sur le nœud actif, puis répliqués sur le nœud passif en conséquence.
Si la banque de messages est proche de l'éviction, un événement est consigné indiquant une banque de messages pleine et le début de l'éviction.
Les messages ont une surcharge sur la mémoire cache. Par conséquent, la taille du message doit être prise en compte lors du calcul de la taille du cache.
Comportement des messages
Nous discutons ici du comportement attendu des messages dans les cas suivants :
Sur vider le cache : Les messages sont supprimés avec les éléments du cache une fois le cache vidé.
Au redémarrage du cache : Semblable à l'effacement du cache, le contenu du cache est effacé lorsque le cache est redémarré. Cela inclut également tous les sujets et les messages qu'ils contiennent.
Expulsion: If l'expulsion est activée sur un cache Pub/Sub, les données seront d'abord expulsées, puis les messages seront expulsés.
Cryptage et compression : If chiffrement ainsi que compression est configuré au niveau du cache, il s'applique également à la charge utile du message de sujet.
Transfert d'État : En cas de transfert d'état, lorsque les messages se déplacent vers un autre nœud du cluster, le nœud où le message est finalement stocké est responsable de la livraison.
Notification d'échec de remise de message
Important
Les abonnés reçoivent une notification d'échec de livraison lorsqu'un message ayant expiré expire avant sa livraison à l'un d'entre eux.
Si un message n’est attribué ou remis à aucun des abonnés, il est considéré comme un échec. Cela peut se produire lorsque l'abonné n'existe pas ou est inactif en raison d'un problème de réseau. Dans un tel scénario, un éditeur peut enregistrer la notification d'échec de livraison de message. Il est important de noter que la notification d'échec de remise concerne uniquement les messages avec expiration. La livraison d'un message est considérée comme ayant échoué lorsqu'un message expire avant sa livraison à l'un des abonnés
Notes
S'il existe plusieurs éditeurs pour un sujet, la notification d'échec sera envoyée à l'un des éditeurs actifs qui s'est enregistré pour la notification d'échec.
Expiration du message
Comme pour les éléments du cache, un éditeur peut définir l'expiration des messages. Les messages expireront du cache dès que l'intervalle d'expiration sera écoulé et utiliseront le même mécanisme d'intervalle de nettoyage.
L'expiration d'un message détermine la durée pendant laquelle il persiste dans le cache. Indépendamment de la remise, si un message n'est pas remis, il sera supprimé après le délai d'expiration. Si un message est livré avec succès avant l'expiration, il est supprimé du cache sans attendre l'heure d'expiration.
Messages ordonnés
NCache prend désormais en charge les messages ordonnés où la séquence des messages est conservée côté client. Un éditeur peut publier des messages ordonnés en spécifiant un nom de séquence pour un morceau de messages. Ensuite, les messages ordonnés sont remis aux abonnés dans le même ordre dans lequel ils sont publiés. La chaîne de séquence doit être la même pour une chaîne de messages ordonnés. En utilisant la chaîne de séquence, tous les messages résident sur le même nœud en utilisant le Affinité de localisation mécanisme.
Notes
Mode de livraison synchrone peut être utilisé pour les messages ordonnés.
Voici les caractéristiques importantes des messages ordonnés :
Les messages d'un éditeur avec la même séquence résident sur un seul nœud de cache.
Si la
DeliveryOption
est défini sur Any, tous les messages ordonnés de la même séquence sont délivrés au même abonné. Dans le cas où l'abonné spécifique perd la connexion ou devient indisponible, un nouvel abonné est réaffecté à cet effet. Cependant, si leDeliveryOption
est défini sur Tous, alors tous les messages ordonnés de la même séquence sont distribués à tous les abonnés.En cas de transfert d'état, les messages ordonnés peuvent perdre leur séquence et être publiés sans conserver l'ordre.
Les messages triés ne peuvent être publiés qu'en utilisant le mode Sync dans l'API de publication. Les appels d'API en masse et asynchrones ne sont pas pris en charge.
Le Monitoring
NCache vous offre la possibilité de surveiller les statistiques Pub/Sub Topic et d'observer divers compteurs de performance à cet égard. L'activité et l'état des sujets Pub/Sub peuvent être surveillés via le Compteurs de performances Windows ainsi que Outils de ligne de commande.
Fiabilité et haute disponibilité
NCache implémente le mécanisme d'accusé de réception pour la livraison des messages. Les messages sont conservés en mémoire jusqu'à ce qu'ils soient livrés avec succès en fonction du au moins une livraison Critères. Ainsi, NCache garantit la fiabilité de la distribution des messages pour la messagerie Pub/Sub dans les architectures distribuées.
De plus, la tolérance aux pannes jusqu'à un nœud dans Topologie de partition-réplication rend la boutique Pub/Sub Messaging hautement disponible. Si un nœud quitte le cluster pour une raison quelconque, la réplique a le message de sauvegarde.
Dans cette section
Sujets Pub/Sub
Explique comment créer, obtenir et supprimer des sujets pour le modèle Pub/Sub dans NCache.
Publier des messages dans un sujet
Fournit un exemple de code qui crée une rubrique et y publie des messages.
S'abonner à un sujet
Fournit un exemple de code pour s'abonner à un sujet et recevoir des messages d'intérêt.
Événements Pub/Sub
Explique les événements Pub/Sub pour informer l'éditeur et l'abonné de divers événements se produisant dans le cache et les applications.
Surveillance des sujets Pub/Sub
Décrit comment les statistiques Pub/Sub peuvent être surveillées via NCache Outils de surveillance, PerfMon et de ligne de commande.