Messagerie .NET Pub/Sub évolutive utilisant NCache
Webinaire enregistré
De Ron Hussain et Edward Bator
Dans ce webinaire, vous apprendrez comment utiliser la puissante messagerie Pub/Sub pour les applications .NET à fort trafic et surmonter les goulots d'étranglement des performances. NCache est un cache distribué évolutif pour .NET qui fournit un riche ensemble de fonctionnalités de messagerie Pub/Sub.
L'un de nos architectes de solution senior vous guidera à travers toutes les fonctionnalités Pub/Sub et leurs cas d'utilisation, et vous montrera comment les intégrer dans votre application .NET.
Ce webinaire couvre:
- Introduction à la messagerie Pub/Sub en général
- LUMIÈRE SUR NOS NCache Fonctionnalités Pub/Sub
- Configurer Pub/Sub dans NCache
- Utilisation pratique de Pub/Sub dans vos applications .NET
- Démonstration de la messagerie Pub/Sub via NCache
- NCache haute disponibilité et évolutivité pour Pub/Sub
Le sujet d'aujourd'hui concernera la messagerie dans les applications .NET et nous utiliserons NCache à titre d'exemple de produit. L'accent principal va être Messagerie Pub/Sub. Le modèle d'abonné de l'éditeur. Pourquoi est-ce important ? Où l'utilisez-vous exactement et pourquoi NCache est un meilleur ajustement par rapport aux autres options que vous voyez pour votre .NET et .NET core applications? Donc, nous avons beaucoup à couvrir. Commençons rapidement avec cela et les gars, s'il y a des questions comme Eddie l'a suggéré, utilisez l'onglet question-réponse et posez autant de questions que nécessaire. Alors, commençons rapidement.
Qu'est-ce que Pub/Sub ?
Les premières diapositives se concentrent sur la partie d'introduction. Qu'est-ce que Pub/Sub ? Je suis presque sûr que tout le monde le sait, mais juste pour être complet, je vais passer en revue le paradigme de messagerie Pub/Sub.
Il s'agit donc d'un modèle d'abonné éditeur. Il comporte principalement trois volets. Nous avons un éditeur, qui envoie des messages, diffuse ces messages sur le canal de communication. Ensuite, nous avons des abonnés, qui pourraient être une autre application, qui reçoit ces messages, puis nous avons une communication, bus un courtier, un service, un processus au sein d'un éditeur et un composant intermédiaire d'abonné qui aide à relayer ces messages des éditeurs aux abonnés. Dans certains cas, vous pouvez stocker des messages, vous pouvez traiter des messages. Cela pourrait être une base de temps, cela pourrait être basé sur vos destinataires.
Comment fonctionne Pub/Sub ?
Ainsi, il existe différentes options que vous pouvez régler lorsque vous prévoyez de l'utiliser. Mais, en général, il existe des directives, des règles communes à la plate-forme de messagerie Pub/Sub typique. Il est faiblement couplé. Éditeur et abonnés, ils peuvent travailler de manière autonome sans avoir aucune dépendance l'un par rapport à l'autre. Ils peuvent également ne pas se connaître et le système devrait fonctionner sans problème. L'idée est que l'éditeur envoie simplement des messages au canal de communication, puis le canal de communication relaie ces messages et les abonnés reçoivent ces messages. L'éditeur n'a pas besoin de connaître l'identité ou les informations sur les applications des abonnés et, de même, les abonnés n'ont pas besoin de savoir quelles sont les informations de l'éditeur. Ils peuvent simplement traiter les messages, c'est le principal point d'intérêt et l'idée générale est que chaque composant fonctionne indépendamment. Les éditeurs n'ont aucune dépendance vis-à-vis du canal de communication ou des abonnés et vice versa également.
La plupart des modèles d'abonnement d'éditeur, les modèles Pub/Sub vous permettent d'avoir une séparation des préoccupations, où vous pouvez avoir des sujets ou des canaux ou des flux. Ceux-ci sont utilisés pour séparer les messages. Ainsi, les messages de nature similaire qui servent un seul objectif simple, ils peuvent être placés dans un sujet spécifique et vous pouvez avoir plusieurs sujets, plusieurs flux, plusieurs canaux, dans un paradigme de messagerie Pub/Sub et vous pouvez recevoir ces messages. Les éditeurs se connectent aux sujets, puis cela transmet ces messages à un certain sujet, puis les abonnés peuvent également se connecter à un sujet dans le canal de communication, puis recevoir ces messages et cela fonctionne parfaitement, en utilisant cette approche basée sur les sujets.
Voici un schéma, qui met en évidence les détails architecturaux.
Nous avons un sujet, c'est un canal de communication, c'est l'application de l'éditeur que nous avons des applications d'abonné. Il peut y avoir plusieurs éditeurs. De même, il peut y avoir plusieurs abonnés, puis dans le canal de communication, vous pouvez également avoir plusieurs sujets. Par exemple, vous pouvez avoir une rubrique traitant des informations de traitement des commandes. Il pourrait y avoir un autre sujet qui traite des informations client et ainsi de suite. Ainsi, en fonction de l'objectif du message, en fonction du type de message, il s'agit des exigences de charge, vous pouvez répartir les messages dans des sujets, puis cet abonné est connecté au sujet A, où l'abonné 2 est connecté au sujet A en tant que ainsi qu'à B, puis l'abonné 3 est uniquement connecté au sujet B. Ainsi, l'éditeur envoie ces messages et les abonnés qui sont connectés aux sujets respectifs reçoivent ces messages sans problème.
Cas d'utilisation courants de Pub/Sub
Bon, alors, passons à la prochaine. Quels sont les cas d'utilisation courants de Pub/Sub ? Il est sur le marché depuis un certain temps, tout ce paradigme de messagerie Pub/Sub et il a également été utilisé dans de nombreuses applications à fort trafic. Il a beaucoup de traction.
Ainsi, nous avons principalement des systèmes backend qui peuvent bénéficier de la messagerie Pub/Sub qui traite le traitement des données asynchrones. Il peut s'agir de certains flux de travail, de certaines tâches en arrière-plan, de certaines procédures dont vous avez besoin, de certains calculs que vous effectuez. Ainsi, les systèmes back-end utilisent principalement cette plate-forme de messagerie.
Les applications de chat, cela pourrait être l'industrie du jeu, qui peut traiter avec des millions d'utilisateurs, des millions de messages, transmis pour les utilisateurs. Par exemple, l'un de nos clients utilisait Pub/Sub pour le partage d'informations lorsqu'il y avait différents tournois sur son site de jeu. Ainsi, ils partageaient beaucoup d'informations liées aux tournois entre les utilisateurs.
L'industrie financière, le commerce électronique, les réservations, tout ce qui est public et ils doivent effectuer un traitement de commande backend, un traitement de réservation ou, en général, fournir une interaction entre les différents composants de l'application.
Usines d'automatisation et de fabrication. Mais, généralement, il pourrait s'agir du cas d'utilisation le plus important, serait un cas d'utilisation technique, serait le microservices cas d'utilisation. Où nous avons différents microservices, qui représentent une grande application, mais ces composants servent un seul objectif indépendant. Il est très difficile d'implémenter la couche de communication pour ces microservices. Vous devriez avoir un canal de communication séparé agissant à nouveau comme un microservice, qui n'a également la capacité d'aucun autre microservice et c'est toute l'idée où vous aimeriez avoir une couche de microservices indépendante, les instances de microservice sont indépendantes les unes des autres. Une instance fait un but unique et elle ne dépend pas d'une autre et vice versa. Ainsi, pour ces applications de microservices, où nous avons des microservices dans l'application, la mise en œuvre d'un canal de communication est très difficile et cela complique et il y a beaucoup de dépendance, ralentit également les choses. Il est donc très logique d'utiliser une plate-forme de messagerie Pub/Sub, où le canal de communication est géré par la plate-forme elle-même, puis les microservices agissent en tant qu'éditeurs et abonnés, puis ils partagent des informations entre eux. Cela devrait donc aider à alléger la charge ainsi que les problèmes architecturaux que vous rencontrez généralement avec Pub/Sub, les applications des plates-formes de microservices utilisant leur propre canal de communication. Ils devraient utiliser Pub/Sub pour les aider à résoudre ce problème.
Le problème : problèmes d'évolutivité avec les plates-formes Pub/Sub
Il existe de nombreuses plates-formes Pub/Sub, mais il y a généralement des goulots d'étranglement et c'est ce que nous allons couvrir ensuite. Nous avons des plates-formes de messagerie traditionnelles typiques. Ils sont très bons en termes d'aspect architectural des choses. Vous envoyez un message, ce message va être transmis à tous les abonnés, tout fonctionne bien. Mais généralement, cela fonctionne très bien sous une faible charge. Lorsque vous avez moins d'utilisateurs, chargez ainsi que moins de demandes ou moins de messages transmis dans les deux sens à votre application. En ce qui concerne la charge, lorsque la charge de l'application augmente, par exemple, il y a beaucoup d'utilisateurs, beaucoup de traitement se produit, puis il y a beaucoup de charge de messagerie des éditeurs aux abonnés, généralement, nous avons vu que notre messagerie traditionnelle plate-forme, telle qu'une base de données, ils deviennent un goulot d'étranglement. Voici un schéma qui illustre cela.
Nous avons des applications d'éditeur, abonné. Il peut s'agir d'une application Web, de certains .NET ou .NET Core arrière-plan. Certains flux de travail. Il peut s'agir de n'importe quel type de .NET ou .NET Core application ou même application Java, connectée à une plate-forme de masse traditionnelle telle qu'une base de données ou une file d'attente de messagerie. Tout d'abord, ce n'est pas aussi rapide que le magasin en mémoire, n'est-ce pas. Donc, c'est quelque chose que vous devez résoudre. Mais le principal problème est que lorsque votre charge de messagerie augmente, lorsque vous avez beaucoup d'utilisateurs, les choses commencent à ralentir car votre charge de messagerie peut étouffer la plate-forme elle-même car il s'agit d'une source unique. Il n'a pas la capacité d'ajouter de plus en plus de serveurs pour aider à gérer la charge accrue que vos applications mettent.
C'est donc le principal problème et quel serait l'impact sur l'utilisateur final ? Par exemple, un message n'a pas été relayé en temps opportun, cela a pris beaucoup de temps et cela a contribué à la latence du côté de l'application. Par exemple, l'utilisateur final attendait qu'un traitement soit effectué et ce traitement dépendait d'une plate-forme de modèle Pub/Sub et la plate-forme était lente. Donc, cela aurait également un impact sur la demande de l'utilisateur final et vous perdrez des affaires s'il y a, disons, un facteur de milliseconde ou de quelques secondes de retard, cela peut avoir un impact sur l'utilisateur final et cela aura à son tour un impact sur votre entreprise en tant que bien et c'est très difficile à gérer, car il n'y a aucun moyen, vous pouvez changer quoi que ce soit à l'intérieur de l'architecture de l'application pour aider à résoudre ce problème. Il y a un problème, qui est en dehors de l'architecture de l'application avec la couche de base de données, à droite. Alors, comment aborder ce scénario particulier?
La solution : cache distribué en mémoire
La solution est très simple, que vous utilisiez une plate-forme de messagerie Pub/Sub en mémoire distribuée par nature, telle que NCache. C'est super rapide, c'est ce qui le distingue des plates-formes de messagerie traditionnelles. Il peut avoir moins de fonctionnalités, je l'admets. Depuis, NCacheL'objectif principal de est d'avoir la mise en cache d'objets, la mise en cache de données, la mise en cache de session, est là pour le traitement des données et le stockage et l'amélioration des performances. Pub/Sub est l'une des fonctionnalités. Il existe des produits tels que les files d'attente de messagerie, par exemple, le service de messagerie Java, la file d'attente MSM, ceux-ci sont plus élaborés. Mais qu'est-ce qui fait NCache mis à part ces produits, c'est que NCache est l'en-mémoire. Donc, c'est super rapide à démarrer.
Donc, si vous avez, disons, cinq utilisateurs et que vous avez moins de charge de messagerie, ces utilisateurs bénéficieront d'une expérience ultra rapide par rapport aux plates-formes de messagerie traditionnelles. Donc, c'est en mémoire. C'est donc un gros plus et nous avons plusieurs serveurs hébergeant cette plate-forme de messagerie. Vous pouvez voir un serveur d'équipe réuni dans une capacité logique qui formule la plate-forme de mess et il a un mécanisme Pub/Sub implémenté au-dessus, à droite. Ainsi, vos applications d'éditeur peuvent se connecter à ce cache et dans le cache, vous pouvez avoir des rubriques distinctes. Je vais vous montrer comment cela fonctionne, en bas de la ligne, puis les abonnés, qui peuvent aussi être des éditeurs d'ailleurs, ils sont également connectés au même canal de communication qui est proposé par NCache comme sous la forme d'un cache de distribution, puis ce canal de communication offre toutes les informations relatives à la communication à ces éditeurs et abonnés. Cela peut relayer des messages et cela pourrait avoir toutes ces différentes sortes d'explorations, une sorte de persistance différente et différentes fonctionnalités que je soulignerai plus tard.
L'avantage de cette plate-forme est que vous pouvez ajouter autant de serveurs que nécessaire et que vous n'avez pas à vous soucier du fait que votre plate-forme soit un goulot d'étranglement d'évolutivité, comme on le voit ici. Ainsi, ce n'est plus un goulot d'étranglement d'évolutivité. Vous pouvez ajouter plus de serveurs à la volée et de deux à trois serveurs, vous augmentez d'un facteur à droite et de trois à quatre serveurs, vous doublez presque la capacité du nombre de requêtes que vous pouvez gérer, du nombre de messages que vous pouvez gérer par seconde et sans en compromettant les performances, cela vous apporterait des améliorations d'évolutivité linéaire pour la livraison de vos messages et cela aiderait beaucoup du côté de l'application. Les utilisateurs finaux en bénéficieraient beaucoup, car ils verraient un temps de réponse plus rapide, une faible latence et un débit élevé pour votre application et vos utilisateurs.
Des questions jusqu'à présent ? Cela explique pourquoi vous devriez envisager d'utiliser NCache par rapport à la plate-forme de messagerie traditionnelle et quels sont les problèmes avec la plate-forme de messagerie Pub/Sub traditionnelle. Des questions jusqu'à présent ? Les prochaines diapositives se concentrent sur les détails architecturaux de NCache Messagerie Pub/Sub, puis nous parlerons des différentes fonctionnalités, qui sont proposées dans le cadre de cela. Salut Ron, nous avons une question. Quelles sont les options de surveillance disponibles ? OK, je pense que c'est à propos de NCache, oui, c'est un autre avantage que j'ai un segment vers la fin aligné juste pour cela. Mais je pense qu'il serait très bien que j'attende cette partie et que je vous donne la démonstration pratique du produit et, dans le cadre de cela, je vous montrerai également les capacités de surveillance. Donc, je vais revoir cette question, une fois que je suis à cette partie. J'espère que ça va.
NCache Messagerie Pub/Sub
Bien, NCache Messagerie Pub/Sub. C'est très similaire à ce que vous avez vu ici. Il s'agit d'une plate-forme de messagerie Pub/Sub traditionnelle. Voici la répartition de l'architecture. Nous avons un canal de messagerie offert par NCache et nous avons une équipe de serveurs ici et dans ce canal de messagerie, nous avons le sujet 1, le sujet 2, puis nous avons un éditeur qui pourrait être n'importe quel .NET, .NET Core application, puis nous avons des abonnés qui sont à nouveau n'importe quel .NET ou .NET Core, même l'application Java, qui lui est connectée.
Un cache dédié peut être formulé pour cela, puis le message est quelque chose qui est relayé depuis le canal de communication à l'aide du mécanisme Pub/Sub typique, où un message est envoyé de l'éditeur aux abonnés. Voici un extrait de code simple.
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
...
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic orderTopic = cache.MessagingService.CreateTopic("orderTopic");
Message orderMessage = new Message(payload);
// Publish message to all registered subscribers
// Register delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);Juste pour vous faire une idée que vous construisez votre charge utile, qui est l'objet d'intérêt, initialisez le cache, ce qui signifie vous y connecter, nommez-le, vous pouvez créer un cluster de cache avec différents serveurs, puis vous créez un sujet ou vous vous connectez à un sujet existant. Le sujet est un canal, un support séparé pour des messages similaires, puis vous construisez un message, puis le publiez et c'est tout. C'est aussi simple que cela pour le cas d'utilisation de base.
Du côté de l'abonné, encore une fois, vous devez vous connecter à un sujet ou créer un nouveau sujet, puis devenir abonné en utilisant la méthode de création d'abonnement, puis il y a un rappel qui est invoqué chaque fois qu'un message est reçu et c'est un appel asynchrone -arrière.
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic productTopic = cache.MessagingService.GetTopic(topicName);
ITopicSubscription prodSubscriber = prodTopic.CreateSubscription(MessageReceived);
private void MessageReceived(object sender, MessageEventArgs args)
{
// Perform operations
}Une démo pratique
Je devrais rapidement vous faire la démo du produit et puis je pense que ce serait beaucoup plus facile à comprendre une fois qu'on aura fait la démo. J'irais de l'avant et dans le cadre de cela, je répondrais également aux options de surveillance. D'accord, alors je vais rapidement vous montrer le NCache outil de gestion, qui est installé avec lui.
Créer un cache
Je vais créer un nouveau cache.
Appelons-le, PubSubCache et je vais ajouter Windows Win à la fin. Tous les caches doivent être nommés. Vous pouvez nommer votre cache Pub/Sub, quelque chose qui a du sens pour votre application. Vous pouvez créer un cache, NCache vous permet de créer un cache sur l'environnement Windows, les serveurs Windows, ainsi que sur les serveurs Linux et nous avons également la version mono de Windows, qui est également disponible. Donc, avec Linux, vous devez utiliser .NET Core et sous Windows, vous pouvez utiliser .NET ainsi que .NET Core sorties de NCache. Donc, je vais continuer avec les serveurs Windows. Choisissez le cache de réplique de partition car je souhaite que plusieurs serveurs contribuent à la capacité de traitement des demandes.
Ainsi, Partitioned et Partitioned Replica sont de très bonnes options. Le cache partitionné vous permet de partitionner les données sur plusieurs serveurs, tandis que la réplique partitionnée est similaire à la partition partitionnée, mais elle comporte également des sauvegardes. Donc, c'est entièrement à vous. Si vous voulez que les messages soient de nature importante, si un serveur tombe en panne, vous ne voulez pas perdre les messages qui sont encore dans le canal de communication, alors vous pouvez utiliser Partitioned Replica sinon, Partitioned Cache est plus excentrique .
Il existe deux autres topologies, mais celles-ci sont destinées à des configurations plus petites et notre NCache webinaire sur l'architecture couvre très efficacement tous les détails autour de ces topologies. Je vous recommande donc de les visiter, de revoir ce webinaire si vous avez besoin d'en savoir plus sur ces topologies. Je garderai tout simple. Choisissez Async comme option de réplication.
C'est-à-dire entre la partition active et la sauvegarde sur un autre serveur et ici je précise l'équipe de serveurs qui va héberger mon cluster de cache. Je peux en avoir deux pour commencer et je peux ajouter plus de serveurs à tout moment, comme indiqué précédemment. C'est d'ailleurs un port TCP. Chaque communication entre NCache est piloté par TCP/IP et la taille correspond à la taille par serveur. Ainsi, en fonction de la charge de messagerie, en fonction de la charge de données, nous vous recommandons de configurer une taille pertinente pour vos applications. Je vais garder tout simple. Démarrez ce cache en démarrage automatique, de sorte que chaque fois que le serveur est redémarré, le cache démarre automatiquement et c'est tout.
C'est aussi simple que cela de configurer ce cache et ensuite, je vais vous montrer comment exécuter l'application, mais j'aurais besoin d'une étape de plus avant de passer à cela. Ça commence aussi, donc ça prend un peu, d'accord, voilà.
Surveiller les statistiques
Donc, il y avait une question sur les options de surveillance, je pense que je devrais m'y attaquer maintenant. Je vais ajouter ma box en tant que client, d'où je vais exécuter l'application éditeur et abonné. Ceux-ci peuvent également être exécutés à partir de n'importe quel serveur ayant accès à ce cache. J'ai ajouté ma boîte en tant que client, c'est donc essentiellement la boîte client. Je peux ajouter une autre boîte et à partir de là, je peux également exécuter des applications. Vous remarquez qu'il existe des options de fenêtre de statistiques disponibles dans l'outil de gestion, mais pour Pub/Sub, ce que je ferais initialement, je lancerais NCache outil de surveillance, puis je vous montrerais également certains des compteurs disponibles spécifiquement pour Pub/Sub.
Par exemple, voici mon tableau de bord Pub/Sub. Je vais continuer et c'est NCache outil de surveillance fourni avec NCache. Je pense que j'en ai besoin, 1 par 3 c'est bien. Très bien, alors, tout d'abord, si vous remarquez que nous avons des statistiques sur les sujets. Ensuite, nous avons des messages publiés par seconde, disons, le nombre de messages, puis nous avons un message expirant par seconde. Je pense que c'est un bon. Vous pouvez également en ajouter d'autres au passage. Il y en a beaucoup ici et puis il y a des compteurs PerfMon qui sont également disponibles. Permettez-moi de les activer également, puis je lancerai une application pour vous montrer comment cela fonctionne. J'ai juste besoin de vous montrer les compteurs et notre outil de surveillance utilise également les compteurs PerfMon. Ainsi, ce que vous voyez ici est également disponible dans le moniteur et vice versa également. Très bien, donc, nous sommes tous installés. Donc, nous avons aussi des compteurs ici. Par exemple, le nombre de messages, la livraison par seconde a expiré. Ainsi, vous pouvez voir la vue numérique, la vue numérique, puis nous avons également une vue graphique sur le moniteur.
Exécuter un éditeur
Maintenant, je lancerais une application qui serait installée avec, mais je l'ai un peu modifiée, afin de pouvoir publier autant de messages que nécessaire. Donc, c'est la configuration d'application un pour l'éditeur, puis c'est une configuration d'application pour le consommateur, l'abonnement. D'accord, donc, je lancerais cette application. Tout d'abord, il lancera l'application de l'éditeur et vous montrera comment cela fonctionne. Permettez-moi de revoir cela, peut-être que je n'ai pas enregistré. D'accord, donnez-moi juste une minute, j'ai besoin de faire une boucle autour de ça. En fait, il y a une boucle. Très bien, laissez-moi le déboguer. Du coup, je n'ai pas d'informations pour me connecter à cette cache. Alors, découvrons cela. J'ai ajouté ma boîte donc, s'il vous plaît, soyez indulgent avec moi. Permettez-moi de résoudre ce problème très rapidement, cela prendra quelques minutes. Bien qu'il ait ajouté, il y avait peut-être une faute de frappe. Voilà. Je spécifiais notre mauvais nom de cache, mon mauvais. Permettez-moi de revoir le nom ici. C'est pubsubcachewin.
J'utilisais le nom de cache d'hier qui était un cache de démonstration. Ça arrive. D'accord, je suis content d'avoir pu le réparer rapidement, sinon cela aurait été un désastre total. Donc, je pense que nous sommes bons. Donc, cela va lancer le programme, qui va être l'éditeur.exe et il publiera dix messages. Je publie encore et encore les mêmes messages. À ce stade, l'éditeur est démarré, l'abonné n'est pas encore démarré. Alors, laissez-moi vous montrer les détails de la surveillance.
Il y a des demandes qui arrivent, bien sûr autour de ça. Mais si vous remarquez, il y avait mon sujet, c'est le nom 10.
Les éléments sont là et vous devriez voir ces messages expirés une fois le délai d'expiration écoulé et je pense que je mets cinq minutes d'expiration ou plus là-dessus. Je voudrais maintenant aller de l'avant et en publier quelques autres. Voilà et vous devriez avoir 10 articles ici, plus ajoutés. Donc, 20 éléments au total et vous pouvez voir le nombre de messages augmenter.
Donc, c'est le graphique et vous pouvez également voir les mêmes options dans le moniteur de performances Windows, où nous avons maintenant la taille et le nombre de messages de 20 à 12. Principalement parce que certains ont expiré. Je pense que j'utilise déjà moins d'expiration dans le cadre de cela. Laissez-moi voir, je pense, le nombre de messages ne s'affiche pas correctement, laissez-moi voir, je pense que c'est le cas, cela devrait être 20 selon mon moniteur.
Exécuter les abonnés
Passons en revue cela avec l'aide des abonnés. Voyons combien de messages il reçoit et au fait, je vais vous montrer le code une fois que j'aurai fini la démo.
Donc, il est censé recevoir les messages existants et je pense qu'il les a tous reçus de manière aléatoire. Il s'agit d'un appel asynchrone de messages. Il ne garantit pas que les messages seront livrés dans cet ordre. Ainsi, vous pouvez recevoir le premier message ultérieurement et ainsi de suite.
Et si je reviens ici, le nombre de messages tombera à zéro. Je pense que ce compteur, examinons cela une fois de plus. Je ne sais pas si cela représente les messages pour un sujet donné ou les messages généraux qui sont publiés. D'accord, donc, il n'affiche pas la valeur correcte alors que cela devrait apparaître. Je pense que ces messages ont été reçus. Donc, je dois fermer l'abonné pour y parvenir. Je vais lancer un autre abonné. Donc, que vous voyez des messages livrés à plusieurs et je pense que nous allons le conclure et vous montrer l'exemple de code correspondant. Je vais entrer encore quelques messages, continuez ainsi et ensuite du côté de l'abonné vous pouvez voir 10 messages sont reçus par celui-ci puis quelques autres reçus par celui-ci. S'il existe deux options de livraison, vous pouvez choisir de diffuser des messages à tous ces abonnés ou à n'importe lequel d'entre eux. Bon, donc, en fonction de celui qui le reçoit, un message expire également du cache. Donc, c'était une démo rapide. Maintenant, je vais vous montrer les détails de ce qui est impliqué pour publier un message ? Quelles sont les fonctionnalités côté sujet ? Quelles sont les fonctionnalités côté éditeur et quelles sont les fonctionnalités côté abonné ? S'il y a des questions à ce stade, s'il vous plaît faites le moi savoir. Je serais heureux de répondre à ces questions pour vous maintenant sinon, je vais passer à autre chose et vous montrer le côté architectural détaillé des choses.
Principales interfaces Pub/Sub dans NCache
Ce sont les principales interfaces au sein de NCache.
Sujet
Nous avons un sujet. Encore une fois, c'est un canal de communication. Il contient la liste des abonnés et il relaie les messages publiés à lui-même aux abonnés connectés.
Message
Ensuite, nous avons un message qui est la charge utile principale. Le point d'intérêt, l'objet d'intérêt pour les abonnés. C'est une charge utile sérialisable. Il peut s'agir de n'importe quel objet, de n'importe quel message que vous souhaitez transmettre, de n'importe quelle donnée pour être précis.
Publisher
L'éditeur est celui qui est une application qui publie des messages et il peut également recevoir une notification d'état de livraison facultative. L'état de livraison est quelque chose que vous pouvez choisir d'activer, mais comme cela a été décidé précédemment ou comme discuté précédemment, l'éditeur n'a pas besoin d'attendre que le message soit livré. Il peut avancer. Ainsi, le statut de livraison facultatif est quelque chose que vous pouvez activer au besoin ou vous pouvez le désactiver.
Abonné
Abonnés, ils s'inscrivent pour un sujet précis et reçoivent tous les messages.
Alors, passons en revue ceux-ci un par un et le diagramme illustre tout ce dont nous venons de parler.
L'éditeur crée des messages, enregistre des événements, envoie des messages, traite et stocke des messages, stocke des abonnés et envoie des messages. Les abonnés s'abonnent et reçoivent ensuite des notifications de message.
NCache Interface de sujet Pub/Sub
Alors, passons en revue l'interface du sujet. Ainsi, tout d'abord, vous pouvez créer un NCache Sujet Pub/Sub, puis vous pouvez également vous connecter à un sujet existant ou vous pouvez également supprimer un sujet. Alors, voyons ce qu'implique cette interface ici ? Donc, si je vais chez cet éditeur ici, je dois d'abord aller au programme et si vous remarquez dans ce programme, je reçois le nom du cache. Je reçois le nom du sujet, qui peut être n'importe quel sujet que vous pouvez choisir et je reçois un compteur de messages, qui est un message aléatoire, puis j'ai la méthode publisher.start, que j'ai implémentée et à l'intérieur de celle-ci Je suis en train d'initialiser le cache, ce qui signifie que je vais le connecter au cache, puis j'obtiens une interface de création de sujet et si je reviens ici, nous avons IMessagingService. Donc, si je vous montre rapidement ceci ici.
IMessagingService Interface for managing Topics in NCache
namespace Alachisoft.NCache.Web.Caching
{
public interface IMessagingService
{
ITopic CreateTopic(string topicName);
void DeleteTopic(string topicName);
ITopic GetTopic(string topicName);
}
}Nous avons l'interface IMessagingService, qui a une méthode CreateTopic, une méthode DeleteTopic pour supprimer un sujet, puis GetTopic. Passons en revue ces un par un. Donc, service de messagerie, nous avons créé un sujet ou nous pouvons simplement nous connecter à un sujet existant. Ce que vous faites vraiment, c'est que vous pouvez également activer la livraison des messages, la notification d'échec de livraison, si c'est quelque chose que vous souhaitez faire. Par exemple, vous pouvez configurer un rappel ici et ce rappel peut à son tour être invoqué, mais c'est facultatif. Vous n'en avez pas nécessairement besoin si vous ne voulez pas l'activer. Donc, comme je l'ai dit plus tôt, les notifications de livraison de messages sont facultatives, vous n'avez donc pas besoin de les activer comme un must. Cela dépend entièrement de votre cas d'utilisation, si vous voulez les activer, alors vous pouvez continuer et le faire.
Ensuite, nous avons une méthode de publication, qui est une méthode personnalisée pour cette application, un wrapper pour cela, puis à l'intérieur de cela, nous construisons un message, puis nous utilisons topic.publish message. Donc, cela renvoie un message, un sujet. Une sorte de poignée pour ce sujet, puis topic.publish est leur méthode actuelle, si je vous montre rapidement ici. Il s'agit d'une interface ITopic, qui a un nom, elle peut avoir un nombre de messages, elle peut avoir un délai d'expiration, que je vais vous montrer dans un instant, puis elle a également des rappels sur le sujet supprimé, l'échec de la livraison du message et ensuite, cela vous permet de vous abonner au sujet, puis de publier des messages dessus également et c'est la première méthode que je voulais présenter, c'est que vous pouvez utiliser topic.publish puis si vous remarquez qu'il existe une option de livraison comme Bien. Vous pouvez faire livrer à tous comme un must ou à n'importe qui. Donc, c'est au niveau du message, donc, c'est une option de livraison pour les messages livrés ou envoyés à ce sujet, puis il y a un dernier booléen facultatif ici, vérifions cela, qu'est-ce que cela suggère ? Pour celui-ci, si vous souhaitez avoir une notification d'échec ou non. Donc, dans ce cas, je le mets sur true mais vous pouvez le désactiver et si c'est le cas, il invoquera le rappel du côté de l'éditeur en conséquence.
Donc, nous avons vu deux méthodes ici. Vous pouvez créer un sujet et, de la même manière, vous pouvez également obtenir un sujet. Donc, c'est une autre méthode que vous pouvez utiliser, alternativement. Mais, puisque je l'exécute pour la première fois, j'utilise créer un sujet, publier des messages sur le sujet, puis je peux également supprimer le sujet, si nécessaire. Donc, ce sont quelques-uns des scénarios et comme vous pouvez le voir, ces diapositives montrent les mêmes exemples à côté de cela.
Create Topic: Code snippet to create a new topic in distributed cache
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.CreateTopic(topicName);Ainsi, si vous supprimez le sujet, le rappel de sujet supprimé sera invoqué et le rappel de sujet supprimé est celui à partir duquel vous pouvez notifier vos utilisateurs finaux ou toute autre information que vous devez publier.
Delete Topic: Deletes an existing Topic distributed
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.DeleteTopic(topicName);
OnTopicDeleted callback: If registered, it will be triggered upon the Delete Topic call.
using (Subscriber subscriber = new Subscriber())
{
// Subscribes on it, using the provided cache-Id and the topic-name.
subscriber.OnTopicDeleted = TopicDeletedCallback;
}
static void TopicDeletedCallback(object sender, TopicDeleteEventArgs args)
{
Console.WriteLine("Topic '{0}' deleted.", args.TopicName);
}NCache Interface de messagerie Pub/Sub
Examinons l'interface de messagerie et nous expliquons ici qu'il existe une option d'invalidation de message, des notifications de message reçu, un échec ou une réception, une notification d'échec, puis le cryptage et la compression sont pris en charge dans le cadre de cela. Alors, jetons un coup d'œil à l'interface IMessage pour cette question. Donc, nous avons un message ici.
namespace Alachisoft.NCache.Runtime.Caching
{
public class Message : IMessage
{
public Message(object payload, TimeSpan? timeSpan = null);
public static TimeSpan NoExpiration { get; }
public string MessageId { get; }
public TimeSpan? ExpirationTime { get; set; }
public object Payload { get; }
public DateTime CreationTime { get; }
}
}Voyons ce qui est disponible dans le cadre de cela. Donc, tout d'abord, nous avons un TimeSpan, vous pouvez choisir NoExpiration ou vous pouvez avoir un TimeSpan ExpirationTime ici à spécifier comme option de message et si je reviens ici, si vous remarquez que nous définissons une expiration basée sur le temps à ce sujet également, si vous remarquez que cela est transmis ici même et que nous avons un laps de temps. Donc, cela est appelé par le programme lui-même. Alors, on donne "TimeSpan.FromMinutes (5)". Donc, cela signifie essentiellement que tout sujet qui n'est pas livré, s'il n'y a pas d'abonné ou si les abonnés sont déconnectés, ce message va rester dans le canal de communication pendant la période de temps spécifiée. C'est une sorte de persistance, mais comme c'est contre la plate-forme Pub/Sub de conserver les messages indéfiniment, la base de temps est donc la bonne option, où vous conservez les messages pendant un certain temps et après cela, vous purgez le magasin lui-même. Ces messages ne seront pas non plus expirés individuellement du canal de communication et cette expiration peut se situer au niveau du sujet lui-même. Le sujet lui-même peut avoir son expiration ou les messages peuvent également avoir leur expiration individuelle. Donc, c'est quelque chose que vous faites et d'ailleurs si l'éditeur et les abonnés sont connectés, l'éditeur publie les messages et ceux-ci sont relayés immédiatement. Il n'attend pas que l'expiration se produise. Il ne le gardera pas, si le message a été délivré. Ainsi, une fois le message délivré, il sort immédiatement du cache. C'est ainsi que vous configurez l'expiration.
Ensuite, vous avez également reçu une notification sur les messages. C'est quelque chose que je vous ai montré plus tôt. Par exemple, vous pouvez voir la livraison, "Échec de livraison du message de l'éditeur" notification, puis vous pouvez également générer un message, l'état de réussite du message également. Donc, c'est une autre option que vous pouvez activer dans le cadre de cela, puis le cryptage et la compression des messages peuvent également être effectués et c'est quelque chose qui est une option sans changement de code. Tout ce que vous avez à faire est de venir au cache lui-même, d'aller dans les options car tout est piloté par NCache lui-même. Ainsi, vous pouvez activer la compression et vous pouvez cliquer avec le bouton droit de la souris et choisir des configurations d'application à chaud.
La compression concerne les objets de plus grande taille. La charge utile du message est plus grande, vous devez donc activer la compression automatiquement et le cryptage est une autre option ici. Cela nécessiterait que vous activiez le chiffrement et pour cela, vous devez d'abord arrêter le canal de communication, arrêter le cache, puis activer le chiffrement. Vous pouvez choisir parmi de nombreux fournisseurs et tous les messages seront cryptés et ensuite seulement renvoyés à l'éditeur et aux abonnés. J'espère que c'était simple. Donc, l'exemple de message est ici.
//Payload containing OrderId to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with payload and expiration time set to 150 seconds
Message message = new Message(payload);
message.ExpirationTime = new TimeSpan(0, 0, 150);Vous pouvez utiliser la commande, créer un message, définir un délai d'expiration, puis utiliser "sujet.publier" et fournissez ce message au bon sujet.
Notification de message reçu
Donc, message reçu notification. Du côté des abonnés, je veux vous montrer cela aussi.
Callback invoked when a message is published on the topic
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
//Get Order topic
ITopic orderTopic = cache.MessagingService.GetTopic(topicName);
//Register subscribers for Order topic
ITopicSubscription ordSubscriber = orderTopic.CreateSubscription(messageReceivedCallback);
private void messageReceivedCallback(object sender, MessageEventArgs args)
{
//perform operations
if (args.Message.Payload is Order ord)
{
//perform operations
}Du point de vue de l'abonné, tout ce que vous avez à faire est de vous connecter au cache pour commencer. Connectez-vous au sujet en utilisant "_cache.MessagingService.GetTopic". C'était la méthode que je vous montrais plus tôt ou vous pouvez créer un sujet, s'il existe, puis vous créez un abonnement qui vous permet de recevoir un message dans un rappel et voici le message de rappel. Je pense que cela devrait être ici dans le programme. Message reçu rappel. Donc, cela va être invoqué chaque fois qu'un message est reçu. Donc, cela complète l'exemple ici.
Pas à pas : Publier le message dans le sujet
Alors, étape par étape une fois de plus. Vous initialisez le cluster de cache Pub/Sub, créez un sujet dédié ou connectez-vous à un existant. Enregistrez les événements de livraison de message si nécessaire, c'est facultatif. Créez un message et publiez-le dans un sujet distinct. Activez l'expiration, activez les options de livraison au besoin et c'est un code qui aiderait à justifier cela.
public void PublishMessages()
{
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
ITopic orderTopic = cache.MessagingService.CreateTopic(topicName);
//Register message failure notification
orderTopic.MessageDeliveryFailure += FailureMessageReceived;
//Register topic deletion notification
orderTopic.OnTopicDeleted = TopicDeleted;
//Payload to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with Order and expiration time set to 150 seconds
Message orderMessage = new Message(orderPayload);
orderMessage.ExpirationTime = new TimeSpan(0, 0, 150);
//Publish message to all registered subscribers
//and register message delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);Et puis du côté de l'abonné, vous vous connectez au cache, obtenez un sujet existant ou créez-en un nouveau. Créez un abonnement au sujet pour la réception de messages. Enregistrez les événements pour la réception qui seront des événements asynchrones, puis désabonnez-vous du sujet et supprimez-le également, si vous en avez besoin, et l'événement de suppression peut en faire partie.
NCache Surveillance pour Pub/Sub
Les prochaines diapositives vont être axées sur le côté surveillance des choses. Passons en revue ceux-ci dans leur totalité. Nous avons déjà couvert les détails de base dans le support du compteur PerfMon pour NCache, nous avons différentes options dans le tableau de bord. Créons un autre tableau de bord.
Ajoutons tout cela. Nous avons donc également des statistiques sur les sujets. Par exemple, nous avons des statistiques sur les sujets, que je vous ai déjà montrées. Nombre de sujets, nombre de sujets que vous avez. Nombre de messages. La taille du magasin de messages, qui correspond à la taille totale et aux octets du sujet, ce qui est très important pour le renforcement des capacités. Si vous essayez de comprendre combien de messages sont livrés ou publiés, vous pouvez faire glisser et déposer le message publié par seconde et le message livré par seconde, puis vous pouvez avoir un statut d'expiration du message ainsi qu'une partie de cela. Donc, ce sont quelques-uns des compteurs. Si j'exécute l'exemple d'application une fois de plus, vous verrez une activité sur tous ces éléments. Très bien, je vais continuer à mettre de la charge en appuyant plusieurs fois sur Entrée et si je reviens ici, vous pouvez voir les activités sur chacun d'eux.
Il y a 220 messages. Le nombre de sujets est de 1 à ce stade. Le nombre de messages est d'environ 220. La taille des magasins de messages s'affiche également. Les messages sont publiés. Mais il n'y a pas de message qui a été livré et il n'y a pas de messages qui ont expiré et si je lance juste un abonné, ce sera très rapide, vous verrez que ces messages seront également reçus. Voilà et si je reviens ici, maintenant vous devriez voir de l'activité ici aussi. Les messages sont également reçus.
Donc, cela termine le processus, vous pouvez enregistrer ces compteurs pour voir la capacité, pour voir les sujets généraux qui s'y trouvent, les messages là-bas, la taille du magasin et l'expiration de ces messages également et je peux créer autant de sujets que nécessaire sur mes exigences. Les mêmes compteurs sont également disponibles sur Windows PerfMon. Donc, vous avez le même ensemble ici et en plus vous avez également des applets de commande PowerShell. Par exemple, si vous accédez à notre documentation ici, laissez-moi l'ouvrir très rapidement. Nous avons donc trois options différentes, PerfMon Counters, NCache Applets de commande Monitor et PowerShell. Dans certains cas, vous voulez simplement vous fier à des outils. Donc, à cette fin, vous pouvez utiliser notre documentation et dans notre guide PowerShell, voyons si je peux le rechercher très rapidement. Cela m'a donné un lien général, alors laissez-moi voir quelques options de surveillance ici. Ainsi, vous pouvez voir "Get-Topics", c'est une applet de commande PowerShell, qui vous permet d'obtenir des noms de rubrique en fonction du nom du cache. Par exemple, si j'ouvre PowerShell ici. Je peux utiliser cette commande, laissez-moi juste l'ouvrir de ce côté donc, c'est clair. D'accord, donc, par exemple, je peux l'exécuter à partir de n'importe quelle boîte ici, puis pubSubCachewin est le nom du cache. Cela ne me donnerait rien. J'ai besoin de l'exécuter sur le serveur lui-même car je pense que ce n'est pas, pubSubCachewin, voilà. Mon sujet, Abonnés, Éditeur et Nombre de messages.
La raison de commencer à travailler depuis ma box car elle a besoin d'une adresse IP pour savoir où se trouve le cache. Il existe donc des outils du côté PowerShell, qui vous permettent de voir certaines statistiques selon vos besoins. Donc, cela complète la partie de démonstration. S'il vous plaît, faites-moi savoir s'il y a des questions. Je vais passer un peu de temps vers la fin pour des détails autour de l'architecture ou de ce qui est proposé dans le cadre de ce canal de communication, NCache en tant que plate-forme de messagerie et pourquoi NCache est un meilleur ajustement?
Architecture de cache distribué
Tout d'abord, NCache est Open Source. Vous pouvez donc vous lancer et Pub/Sub est disponible même dans une version Open Source de NCache. Il est linéairement évolutif, c'est le point numéro un et avant cela, c'est en mémoire, c'est le principal point d'intérêt pour les applications qui ne recherchent que des performances et qui ne cherchent pas à avoir des exigences de charge élevées pour démarrer. Donc, s'il y a un problème de performances NCache est à nouveau mieux adapté par rapport aux plates-formes de messagerie Pub/Sub conventionnelles.
Il est évolutif de manière linéaire, ce qui signifie essentiellement que vous pouvez ajouter autant de serveurs que nécessaire. Deux serveurs suffisent. Mais s'ils atteignent leur capacité parce que la capacité peut être atteinte par NCache les serveurs aussi. Le problème initial que vous avez vu avec la base de données. On ne dit pas ça NCache ne verrait pas ce problème. Avec un serveur, vous pouvez atteindre une capacité et, d'ailleurs, vous pouvez avoir plus de serveurs, mais ces serveurs supplémentaires peuvent également ajouter de la capacité. Par exemple, ces deux serveurs sont au maximum et c'est le bon moment car vous savez à l'avance les exigences de charge ou la charge élevée de votre application. Ainsi, vous pouvez en quelque sorte anticiper cela en ajoutant plus de serveurs et en faisant une meilleure planification de la capacité. Ainsi, plus de serveurs peuvent être ajoutés à la volée et c'est la beauté de celui-ci où il est linéairement évolutif.
Ensuite, la troisième caractéristique importante est que, si vous en avez besoin, vous pouvez également bénéficier d'un support de réplication, ce qui garantirait la fiabilité. Il est déjà hautement disponible et la panne de son serveur n'aura pas d'impact sur les clients finaux ou la plateforme de l'éditeur ou de l'abonné fonctionnera sans problème. Tant que vous avez un nœud survivant dans le cluster de cache, la plate-forme Pub/Sub restera opérationnelle et pourquoi est-elle capable de le faire ? Il est hautement disponible car il est de nature dynamique.
Il s'agit d'un cluster de cache 100 % peer-to-peer. Cela vous permet d'ajouter autant de serveurs que nécessaire et ces serveurs sont de nature indépendante. Ils contribuent à la capacité de traitement des demandes en répartissant la charge mais ils fonctionnent en capacité 100% indépendante. Tout serveur en panne ou tout nouveau serveur ajouté n'aura aucun impact sur le cache. La plateforme n'a pas besoin d'être arrêtée pour cela. Il peut continuer à fonctionner et les clients n'ont pas besoin d'être arrêtés ou redémarrés. C'est le problème avec les sources conventionnelles, où si un serveur tombe en panne, vous devrez peut-être redémarrer les clients afin de commencer à utiliser les nœuds survivants. Il s'agit donc d'une nature dynamique dans laquelle les clients s'ajusteraient automatiquement et le cluster lui-même aurait une disponibilité de 100 % avec un mécanisme d'auto-guérison. Si un serveur est ajouté, le cluster s'y adapte en répartissant la charge sur le serveur nouvellement ajouté et en notifiant les clients en même temps.
De même, le cas de maintenance ou le cas de panne du serveur, où un serveur tombe en panne ou tombe en panne dans ce cas, le cluster de cache reste opérationnel. Vous avez besoin d'un nœud survivant pour que cela fonctionne et les clients sont avertis au moment de l'exécution. La prise en charge du basculement de connexion est intégrée au protocole côté client. Ainsi, les clients détectent les pannes, puis basculent et commencent à utiliser automatiquement les nœuds de survie, ce qui garantit une disponibilité de 100 % du côté du cache et également pour vos clients finaux qui y sont connectés. Donc, c'est de nature dynamique. C'est une architecture 100% peer-to-peer. La prise en charge du basculement de connexion y est intégrée et le cluster s'auto-guérit en lui-même. C'est un mécanisme intégré au protocole. Cela garantit une disponibilité à 100 %, un scénario de cache hautement disponible.
Topologies de mise en cache : cache partitionné
La topologie des canaux de communication.
La plate-forme Pub/Sub peut avoir un partitionnement des données. Vous pouvez avoir des données partitionnées sur le serveur 1 ainsi que sur le serveur 2. Ce sont des éléments de données qui représentent vos messages. Donc, nous avons des messages livrés par le serveur 1 et d'autres par le serveur 2. C'est complètement aléatoire, basé sur notre algorithme de distribution et votre éditeur et vos abonnés sont connectés à tous les serveurs. Donc, certains sont connectés au serveur 1, certains sont connectés au serveur 2, mais si vous remarquez que chaque serveur en a, en fait, ils se connectent à tous mais certains messages sont délivrés par le serveur 1 et d'autres par le serveur 2, etc. de suite. Ainsi, la charge des messages va être distribuée et ceci est excentrique, où il utilise pleinement toute la capacité de mémoire de ces serveurs, pour servir les messages, pour stocker les messages, pour leur délai d'expiration et il joint également leur puissance de calcul dans une capacité logique aussi bien. Ainsi, tous ces services contribuent à la capacité de traitement des demandes et c'est la raison pour laquelle si vous ajoutez plus de serveurs, vous obtenez plus de capacité du système et c'est pourquoi nous vous recommandons d'utiliser la topologie de réplique d'opération de partition car vous pouvez évoluer linéairement, si vous besoin de.
Topologies de mise en cache : cache de partition-réplication
Il s'agit du cache de réplique de partition, qui prend également en charge la sauvegarde.
Nous avons la partition active du serveur 1, sauvegarde sur (serveur) 2. Ainsi, tous les serveurs forment une partition active et une partition de sauvegarde d'un autre serveur, qui est une réplique pour un autre serveur. Le serveur 1 est une sauvegarde active sur le serveur 2, le serveur 2 est une sauvegarde active sur 3 et le serveur 3 est une sauvegarde active sur 1 et le cluster est toujours capable de gérer cela si un serveur tombe en panne. Parce que, si le serveur 1 tombe en panne, la sauvegarde du serveur 1 était sur 2 donc, cette sauvegarde est activée et elle est fusionnée avec les serveurs 2 et 3 et le cluster se guérit et formule une sauvegarde active à 2 nœuds, mécanisme passif actif où la sauvegarde du serveur 1 est activée La sauvegarde du serveur 2 est sur le serveur 1. Et elle est totalement transparente pour vos utilisateurs finaux. Vous n'avez pas à vous soucier des utilisateurs finaux qui en sont affectés. Ainsi, avec une disponibilité de 100 % NCache assure tout cela.
Très bien, cela nous amène vers la fin de notre présentation. S'il vous plaît, faites le moi savoir, nous pouvons nous concentrer vers la fin sur certaines des questions que vous pourriez avoir. Donc, je le confierais à Eddie à ce stade. Eddie, vous pouvez le récupérer ici. Encore une fois, merci beaucoup pour votre temps. J'espère que cela a été bénéfique et nous avons hâte de vous revoir lors de notre prochain webinaire. En attendant, si vous avez besoin de revoir le webinaire existant, que vous venez de revoir en ligne sur alachisoft.com/ressources Encore un rappel, NCache est la seule application native sur le marché aujourd'hui pour des performances maximales. Au plaisir de vous revoir bientôt. Merci.