NCache Architecture

Émission enregistrée
Par Ron Hussain et Zack Khan

Le webinaire d'aujourd'hui sera basé sur NCache ArchitectureNous allons maintenant aborder la mise en cache distribuée et son fonctionnement pour résoudre les problèmes de performances dans .NET et .NET Core. Nous examinerons les cas d'utilisation courants, l'architecture de cache distribuée, les détails du clustering, et répondrons à toutes vos questions à ce sujet. NCache, mais aussi la mise en cache en général. À tout moment pendant ce webinaire, vous pouvez poser des questions dans l'onglet « Questions » de GoToWebinar. N'hésitez pas à consulter cet onglet à votre convenance. Si vous avez une question, je pourrai la soulever pendant la présentation pour que Ron ou moi-même y répondions. Nous disposons également d'un peu de temps à la fin de cette session pour répondre à d'autres questions, mais nous espérons passer un excellent moment.

Alors, sans plus attendre, je passe la parole à Ron, et commençons. Très bien, merci Zack. Alors, comme Zack vient de le dire, le sujet du jour est… NCache architecture. Dans ce webinaire, je vais aborder en détail comment NCache Le clustering fonctionne, quelles sont les topologies les plus courantes parmi lesquelles vous pouvez choisir et l'un des principaux avantages de NCache En termes de cas d'utilisation de votre application. Quels sont ces cas d'utilisation et comment en tirer pleinement parti ? NCache au sein de vos applications serveur ?

J'espère que tout le monde peut voir mon écran. Si je peux obtenir une confirmation rapide, je vais m'y mettre rapidement. Oui, je pense que tout va bien si vous le pouvez. Voilà, je crois. Oui, ça a l'air bien. Parfait. Bon, alors commençons vite.

Le problème de l'évolutivité

Très bien, alors définissons d'abord ce qu'est NCache Et pour cela, je vais devoir définir ce qu'est un problème d'évolutivité, puis comment NCache est capable de résoudre ce problème d'évolutivité. Ainsi, dans une architecture serveur classique où des applications sont déployées, il s'agit généralement de plusieurs instances ou serveurs, que ces applications soient déployées ou non. On peut donc affirmer sans risque que votre couche applicative est très évolutive.

Vous pouvez ajouter autant de serveurs que vous le souhaitez dans une couche applicative. Vous pouvez créer un formulaire web ou un formulaire d'application où plusieurs serveurs d'application ou serveurs web hébergent la même application, mais travaillent en équipe et se répartissent la charge de requêtes. De plus, si vous optez pour une architecture plus récente, même avec des microservices, vous pouvez faire évoluer individuellement vos services applicatifs, notamment ceux nécessitant davantage de calculs ou de capacité de traitement des requêtes.

La couche applicative est très évolutive, linéairement. À mesure que vous grandissez, vous pouvez gérer une charge de requêtes de plus en plus importante. Le problème se pose avec la base de données, par exemple une base de données relationnelle. En effet, toutes ces applications, quel que soit leur niveau d'évolutivité, doivent toujours communiquer avec une base de données back-end. Et lorsqu'elles communiquent avec une base de données back-end, il s'agit généralement d'une source unique. Ce n'est pas très évolutif. C'est très avantageux pour le stockage ; vous pouvez disposer de ressources disque importantes, ce qui permet d'en tirer des avantages en termes de stockage. Cependant, lorsque vos applications subissent une charge transactionnelle importante, qui se traduit par une charge transactionnelle au niveau de la base de données, celle-ci a tendance à s'épuiser. C'est le principal problème : l'application peine à gérer les requêtes. L'absence d'évolutivité compromet également l'expérience utilisateur.

Les bases de données NoSQL apportent une solution partielle à ce problème. Il est possible d'utiliser une base de données SQL, mais cela implique une refonte complète de l'architecture applicative, qui abandonne les bases de données relationnelles au profit des bases de données NoSQL. Or, il s'agit d'un projet d'envergure. Par conséquent, NoSQL n'est pas toujours la solution aux problèmes de scalabilité.

La solution: NCache Cache distribué

Alors, que faire maintenant ? La solution est très simple : il faut un cache distribué en mémoire, comme dans NCacheTout d'abord, il s'agit d'une solution en mémoire, ce qui améliore considérablement les performances de votre application. Elle est ultra-rapide par rapport à une base de données relationnelle. Son principal avantage réside dans son évolutivité linéaire, contrairement à un serveur de base de données, qui est généralement une source unique. NCache peut résider sur plusieurs serveurs. Il vous permet de créer un cluster de cache Il peut fonctionner sur plusieurs machines. Comme vous le savez, vos besoins augmentent et nécessitent une capacité de traitement des requêtes accrue depuis votre couche applicative. Vous pouvez donc ajouter des serveurs supplémentaires au cluster de cache lors de l'exécution.

Ce qui est bien avec NCache L'avantage de cette solution est qu'elle s'utilise en complément d'une base de données relationnelle ou d'une base de données back-end. Elle ne remplace pas vos sources de données traditionnelles. Elle complète les sources de données existantes et améliore les performances de vos applications. Elle accroît la capacité de traitement des requêtes. De plus, à mesure que votre application se développe, vous pouvez augmenter le nombre de serveurs du cluster de cache, car ces serveurs sont intégrés au cluster et fonctionnent donc en équipe. Ils peuvent répartir la charge de requêtes entre eux, offrant ainsi une évolutivité linéaire. NCache Il s'agit d'un modèle linéairement évolutif et très simple d'utilisation. Voyons maintenant comment fonctionne l'architecture de déploiement. Dans un environnement de production généralement de grande envergure, voici comment NCache ressemblerait à:

Vous auriez un ensemble de serveurs. Ceux-ci pourraient être des services Windows ou Linux, conçus de telle sorte que NCache se situe entre votre application et la base de données. Par exemple, vous pouvez commencer avec deux ou trois NCache serveurs, et ensuite vous pouvez grandir jusqu'à quatre ou cinq NCache Les serveurs et différents types d'applications — par exemple, vos applications web ASP.NET ou ASP.NET Core, vos services .NET ou .NET Core, ou encore vos applications serveur .NET/.NET Core. Il peut même s'agir d'applications Java ou Node.js. Ces applications peuvent donc également tirer parti de la mise en cache distribuée.

NCache L'application est écrite en .NET/.NET Core. Elle fonctionne aussi bien sous Windows que sous Linux. De même, vos applications peuvent être déployées sur n'importe quelle plateforme et fonctionneront sans problème. En général, nous recommandons d'utiliser… NCache sur des serveurs de configuration dédiés, qui hébergent uniquement NCache, afin que vous ayez des ressources dédiées à la nature NCacheVos serveurs d'applications sont ensuite répartis sur un niveau distinct. Vous disposez ainsi de ressources dédiées à vos applications. Il existe également une autre option de déploiement, permettant de gérer des configurations plus petites. NCache installés sur les mêmes machines, là où vos applications tournent également. C'est donc toujours possible avec NCache. Mais, comme indiqué précédemment, l'option recommandée est d'avoir un niveau de cache distinct, comme illustré dans le schéma. Ensuite, NCache Se situe entre votre application et la base de données. L'idée est de mettre en cache les données les plus fréquemment utilisées dans vos applications. Il peut s'agir de données de référence ou de données transactionnelles. Par « référence », j'entends les données nécessitant une lecture intensive, et par « transactionnelles », celles nécessitant une lecture et une écriture intensives. Une fois que vous savez quelles données mettre en cache, vous pouvez les appeler « ensemble de travail ». Pour la première fois, vous pouvez extraire ces données de la base de données et les y ajouter. NCache et les appels ultérieurs peuvent être traités via NCache En effet, vous évitez de coûteux déplacements vers la base de données. C'est ce que l'on appelle communément le modèle « cache-aside », où toutes les modifications apportées sont également propagées vers le cache, puis vers la base de données. De plus, si une base de données n'existe pas dans le cache, vous la récupérez systématiquement et la conservez à l'intérieur. NCache Mais il faut toujours vérifier le cache en premier. Ainsi, si vous trouvez des données dans le cache, vous n'avez pas besoin d'accéder à la base de données et de revenir à partir de là.

Lecture/écriture directe

L'approche alternative consiste à utiliser la « lecture directe » ou la « écriture directe », représentée ici par des lignes pointillées. NCache Il existe une fonctionnalité permettant d'automatiser cette opération, avec l'option « cache-through », appelée « read-through » pour les lectures et « write-through » pour les écritures. Ce système fonctionne de telle sorte que vous utilisez toujours le cache comme source principale et que vous implémentez un gestionnaire de lecture et d'écriture sur le cache, qui se charge de la mise à jour des sources de données backend. Ainsi, quelles que soient les opérations de lecture effectuées, si des données sont inexistantes, elles seront transférées de manière transparente vers votre base de données basée sur votre fournisseur, récupérées pour votre application, puis renvoyées vers l'application et stockées dans celle-ci. NCachePour les mises à jour, il mettra à jour le cache ainsi que la base de données dans une approche synchrone ou asynchrone, selon le modèle que vous avez appelé depuis l'application.

Je vais donc partager plus de détails sur les modèles de lecture, d'écriture et de mise en cache, mais juste pour vous donner une image de déploiement de haut niveau, voici comment vous verriez NCache déployé sous une forme de serveur, où plusieurs applications ou formulaires d'application peuvent se connecter NCache Ils peuvent ensuite tirer parti d'une mise en cache distribuée, où l'accès en mémoire améliore les performances des applications. De plus, la présence de plusieurs serveurs dans la couche cache permet une évolutivité linéaire. J'espère que c'était clair ; n'hésitez pas à me contacter si vous avez des questions. Heureusement, pour le moment, il semble que je n'en ai pas, alors n'hésitez pas à continuer. Très bien.

NCache Chiffres d'évolutivité

Alors ensuite, je vais parler de NCacheLes chiffres d'évolutivité de. Nous venons de le mentionner NCache est capable de résoudre le problème d'évolutivité de votre application. Donc, NCache Le système est lui-même linéairement évolutif. La couche applicative étant évolutive, et la résolution d'un goulot d'étranglement de base de données grâce à un modèle linéairement évolutif, voici quelques chiffres de référence. Il s'agissait de nos tests de performance réalisés dans notre environnement d'assurance qualité. Nous avons utilisé des serveurs gourmands en ressources CPU et RAM afin de les exploiter pleinement et de les utiliser en situation de forte charge. Nous avons démarré avec un seul serveur, puis nous avons augmenté la charge applicative avec deux serveurs. Dès qu'un ensemble de serveurs a atteint sa limite de capacité CPU et RAM, nous avons ajouté un autre serveur.

C'est la règle générale : lorsque vous pouvez continuer à utiliser les serveurs de cache existants, commencez par deux NCache Serveurs, et lorsque vous constatez que ces deux serveurs sont saturés en termes de capacité matérielle, que ce soit votre CPU ou votre RAM, il faut alors décider d'augmenter la capacité et d'ajouter un troisième serveur au cluster de cache. C'est exactement ce que nous avons fait avec une taille d'objet moyenne de 1 Ko : nous avons continué à augmenter la charge applicative et le nombre de serveurs, jusqu'à ce que l'ensemble de serveurs donné atteigne sa limite. Il ne s'agissait pas de données aléatoires ; il s'agissait de données applicatives réelles, simulées dans notre laboratoire d'assurance qualité. Ainsi, avec deux, trois, quatre, cinq, voire cinq serveurs, nous avons pu traiter 2 millions de requêtes par seconde avec une taille d'objet moyenne de 1 Ko.

Il s'agissait donc d'une combinaison de lectures et d'écritures appliquées de manière cohérente au cache. Au total, un débit de 2 millions de requêtes par seconde a été atteint, sans compromettre les performances. Le débit ne se limite donc pas à un grand nombre de requêtes par seconde ; la latence de chaque requête doit également être maintenue et ultra-rapide. Une démonstration vidéo et un livre blanc sont disponibles sur notre site web.Voir ici). Et c'est quelque chose que vous pouvez également revoir.

Utilisations courantes du cache distribué

Ok, parlons de certains des cas d'utilisation courants de NCache.

• Mise en cache des données d'application

  Le cas d'utilisation numéro un est la mise en cache des données d'application, nous l'appelons Mise en cache des données d'applicationVoici les données provenant d'une base de données principale. Nous avons déjà établi que les bases de données sont généralement lentes car elles sont basées sur disque, tandis que la RAM est une source plus rapide. L'autre problème est que les bases de données ont tendance à saturer sous un trafic élevé. Si votre charge transactionnelle est importante et que vous utilisez un seul serveur, il est probable qu'il ne vous offrira pas les performances nécessaires côté application. Il est donc judicieux de mettre en cache les données applicatives à l'intérieur de vos applications en utilisant NCacheC'est très simple, vous utilisez NCache Les API et l'appel au cache sont simples. La connexion au cache s'effectue via les API d'initialisation du cache. Une fois connecté au cache, vous pouvez appeler « cache.Ajouter, cache.Mettre à jour, cache.Supprimer' ou 'cache.Obtenir' pour récupérer des données du cache. Je vous montrerai quelques exemples vers la fin. L'idée ici est que, quelles que soient les données que vous pensez lire plusieurs fois, qu'il s'agisse de données de référence ou de données transactionnelles, NCache va ajouter beaucoup de valeur car il n'est pas nécessaire de revenir à la base de données pour récupérer les modifications.

  

  Ainsi, les données du cache seront utilisables plus longtemps. Et, pendant que vous utilisez les données de NCache, vous n'avez pas besoin d'accéder à la base de données principale. Cela améliore les performances de votre application et vous offre une évolutivité accrue, car NCache est évolutif en comparaison.

  Il est donc très intuitif de mettre en cache toutes vos données de référence, mais nous vous recommandons également de mettre en cache une partie, voire la plupart, de vos données transactionnelles. D'après notre expérience, nous recommandons de mettre en cache toutes les données lues plusieurs fois, même deux ou trois fois. En effet, même si elles sont modifiées dans la base de données, et après cette modification, si vous les lisez plusieurs fois (deux ou trois fois), il est judicieux de les mettre en cache, afin d'éviter d'avoir à accéder à la base de données principale. De plus, nous avons des fonctionnalités intégrées. NCache Ce qui peut également vous offrir une synchronisation à 100 % avec la base de données. C'est un point à considérer.

  Ron, j'ai une question rapide qui m'est parvenue, principalement :
  Dois-je toujours accéder à mon cache clusterisé via le réseau ? J'ai peur que des problèmes réseau empêchent mes applications de fonctionner. Existe-t-il un moyen de conserver certaines de mes données localement ?

  D'accord, donc généralement, le déploiement par défaut est celui que nous vous recommandons d'avoir NCache dans des cases séparées, puis votre application dans des cases séparées, n'est-ce pas ? Donc, quand NCache Basé sur le protocole TCP, il s'agit d'un appel réseau. Il existe une fonctionnalité appelée « Cache Client », un cache local hébergé sur les machines applicatives. Si vous avez réellement besoin de plus d'exécutants et souhaitez éviter toute latence réseau, il est également possible de le rendre « in-proc », c'est-à-dire intégré au processus de votre application. Dans ce cas, le sous-ensemble de données est automatiquement transféré dans le cache client. Cela permet d'éviter toute communication entre processus, ainsi que toute communication réseau et toute surcharge réseau. Nous disposons d'une fonctionnalité que j'aborderai lors de la présentation de nos topologies. Je vous donnerai plus de détails, mais pour vous donner un aperçu rapide, voici comment fonctionne le cache client. Il s'agit d'un cache hébergé sur la machine où se trouvent vos applications. L'objectif est d'éviter les allers-retours réseau fréquents si le cache client est activé. De plus, cela fonctionne sans modification de code. J'espère que cela répond à votre question. N'hésitez pas à me contacter si vous avez d'autres questions. Oui, ça me va. Ron, à vous. Très bien.

• Mise en cache ASP.NET et ASP.NET Core

  Le prochain cas d'utilisation de NCache Dans une application web, il est nécessaire de mettre en cache certaines données utilisateur. Il s'agit généralement de l'état de session ASP.NET ou ASP.NET Core. Ces données n'ont pas leur place dans une base de données, car elles sont éphémères. Elles sont créées par l'utilisateur et restent dans le contexte de l'application tant que celui-ci est actif. Dans certains cas, il est possible de les conserver dans la base de données à des fins d'archivage, mais le plus souvent, ces données appartiennent à l'utilisateur.

  Donc, pour les sessions Microsoft ASP.NET ou ASP.NET Core, plusieurs options s'offrent à vous : serveur d'état, traitement in-procédure ou serveur de base de données. Chacune de ces solutions présente des avantages et des inconvénients. Par exemple, le traitement in-procédure constitue un point de défaillance unique ; il est donc nécessaire d'utiliser l'équilibrage de charge avec sessions persistantes. Le serveur d'état ASP.NET représente également un point de défaillance unique et, comme vous le savez, il n'est pas évolutif. La base de données est une autre option ; elle ne constitue pas un point de défaillance unique grâce à la possibilité de sauvegarde, mais elle peut néanmoins le devenir dans certains cas. De plus, elle est lente et non évolutive. Alors, que faire ? Il est conseillé d'envisager l'utilisation de… NCache Pour la mise en cache de l'état de session ASP.NET et ASP.NET Core. Son fonctionnement est simple : il vous suffit d'intégrer notre fournisseur. Cette solution ne nécessite aucune modification de code, mais dès que vous l'intégrez… NCache à l'intérieur de vos applications, NCache devient votre stockage de session principal. L'idée est qu'il sera ultra-rapide grâce à sa RAM. Il est très évolutif grâce à la présence de plusieurs serveurs. NCache, une fois que nous aurons progressé dans la présentation et que j'aurai couvert les topologies, vous comprendrez que NCache Il y a des sauvegardes grâce aux réplications. Les données de session sont des données utilisateur, n'est-ce pas ? Il est donc important de ne jamais les perdre, car une telle perte a des conséquences pour l'utilisateur et l'entreprise. Grâce à la réplication, les données sont également sauvegardées.

  

  Si je devais énumérer les avantages, sachez que, tout d'abord, vous améliorerez les performances de votre application grâce à l'accès en mémoire. Plusieurs serveurs prennent en charge la mise en cache des sessions, ce qui rend le système très évolutif. De plus, il intègre des fonctionnalités de haute disponibilité et de fiabilité des données. Ainsi, il n'y a aucune perte de données de session ni interruption de l'application en cas de problème. NCache Le serveur tombe en panne. Et vous n'avez plus besoin d'utiliser l'équilibrage de charge par session persistante, car NCache est une entité partagée. La requête peut être adressée à n'importe quel serveur web ; elle pourra toujours trouver des données à partir de NCache Basé sur notre protocole. Tout cela sans aucune modification de code.

  Autre cas d'utilisation : vous pouvez également regrouper votre état d'affichage si vous utilisez des formulaires web ASP.NET. C'est là qu'il est également mis en cache. L'état d'affichage devient lourd ; il consomme beaucoup de bande passante. Il est intégré à vos paquets de requêtes et de réponses, et est systématiquement renvoyé au navigateur. Il n'y est jamais vraiment utilisé, mais stocké dans le navigateur, côté client. Et lorsque vous postez, c'est là que l'état d'affichage est récupéré côté serveur. Ainsi, avec NCacheNous vous permettons de mettre en cache l'état d'affichage côté serveur, afin que votre charge utile ne soit plus affectée par un état d'affichage lourd. Cela améliore les performances. Cependant, l'état d'affichage est toujours stocké côté navigateur. En le conservant côté serveur, là où il est nécessaire, le comportement global de l'application s'en trouvera amélioré. La bande passante ne sera plus sollicitée, car le paquet de requêtes et de réponses n'est plus affecté par un état d'affichage lourd. De plus, la sécurité sera renforcée, car l'état d'affichage est stocké côté serveur. Vous pouvez ensuite y ajouter du chiffrement et des fonctionnalités de sécurité. Cette option ne nécessite aucune modification de code. Elle ne s'applique qu'aux formulaires web existants. Je vous recommande donc, si vous utilisez une application de formulaires web ASP.NET, d'envisager également la mise en cache de l'état d'affichage.

  Ensuite, nous avons la mise en cache des réponses d'ASP.NET et d'ASP.NET Core. Ainsi, pour les pages statiques ou les portions de page statiques, il est conseillé de mettre en cache les résultats. ASP.NET Core propose une option de mise en cache des réponses, sans aucune modification de code. De plus, ASP.NET et ASP.NET Core prennent en charge le backplane SignalR. En effet, dans un formulaire web, l'utilisation de SignalR requiert impérativement un backplane. Les backplanes classiques, tels qu'un système de fichiers ou une base de données, peuvent présenter les problèmes de scalabilité et de performance évoqués précédemment. NCacheCe système sera extrêmement rapide, évolutif et fiable grâce à l'utilisation d'un système de messagerie très performant en arrière-plan. Voici donc quelques cas d'utilisation que vous pouvez exploiter dans vos applications ASP.NET ou ASP.NET Core.

Avant de continuer, Zack, je crois qu'une question a été posée. Oui. Donc, la question venait essentiellement du fait que vous disiez « DB par défaut ». Donc, au milieu de votre… je voulais attendre que vous ayez terminé, mais la question consiste essentiellement à… Et au cas où, pourriez-vous développer la question, monsieur ?

Salut Ron, c'est NCache Convient également à la publication de données, avec l'exigence de sauvegarder les données en mémoire cache, avec des options de synchronisation des données dans la base de données en arrière-plan. NCache prendre en charge ce mécanisme de synchronisation entre le cache mémoire et les bases de données par défaut ?

Oui, c'est une excellente question. Pour les cas avancés, cela pourrait toujours être une exigence. Cela fonctionne de deux manières. Premièrement, votre application utilise désormais des données provenant de NCache, mais des données existent dans la base de données. Il s'agit donc de deux sources distinctes qui doivent être synchronisées en lecture comme en écriture. Si l'application connectée NCache et la base de données est la seule application responsable de la modification des données à l'intérieur NCache et la base de données. Nous vous recommandons d'utiliser la lecture et l'écriture directes. Ceci peut être effectué de manière asynchrone ou synchrone, selon vos besoins. En pratique, chaque fois que vous essayez de récupérer des données depuis NCache Si les données n'existent pas dans le cache et que vous souhaitez les mettre en cache, vous appelez automatiquement la lecture directe, qui lit la base de données principale en fonction de votre code. De même, si les données proviennent d'une base de données et doivent être mises à jour dans celle-ci, dès que vous mettez à jour les données du cache, vous utilisez la lecture directe. L'écriture directe peut également être une écriture différée, ce qui signifie que les données doivent être mises à jour à l'intérieur. NCache et dans la base de données en utilisant votre gestionnaire d'écriture directe. Si vous souhaitez une invocation asynchrone, vous pouvez utiliser l'écriture différée, afin que l'exécution se fasse en arrière-plan. Mais encore une fois, NCache et votre application est responsable de cela, où NCache appelle votre code et votre application l'invoque.

Une autre situation pourrait être que d'autres applications modifient directement les données de la base de données sans que votre application n'en soit informée. Dans ce cas, vous devrez utiliser nos fonctionnalités de synchronisation de base de données. Vous devrez créer une dépendance personnalisée ; SQL Server propose des notifications en chaîne. Nous avons des dépendances de base de données. De nombreuses fonctionnalités de synchronisation permettent de capturer toute modification de la base de données. NCache automatiquement. Vous pouvez à nouveau utiliser la lecture directe et recharger les données à l'intérieur NCache ainsi. Donc, pour résumer, NCache peut, vous savez, gérer les deux situations : soit c'est votre application qui est la seule entité qui change quoi que ce soit à l'intérieur NCache et la base de données, ou dans une situation où la base de données peut être modifiée en dehors du champ d'application de l'application qui utilise la mise en cache.

Ainsi, les deux scénarios sont couverts, et NCache Vous aurez une option de synchronisation à 100 % pour ces cas-là. Si vous parlez de cache mémoire, ASP.NET en propose généralement aussi ! Mais si vous faites référence à NCache En tant que cache mémoire, j'ai déjà répondu à la question. N'hésitez pas à me contacter si vous avez d'autres questions, et nous pourrons ensuite.

• Messagerie Pub/Sub

  Ça a l'air bien. Je pense qu'on peut passer à autre chose. Bien. Bon, maintenant je vais parler de la messagerie Pub-Sub. Comme vous pouvez le voir, NCache Il est déjà partagé entre les applications. C'est donc une entité que vous pouvez utiliser pour vos besoins en données. Vous pouvez y ajouter des données et en extraire. Vous bénéficiez ainsi de performances et d'évolutivité. NCache. Vous pouvez étendre ce cas d'utilisation en utilisant NCache comme plateforme de messagerie également. Donc, NCache la messagerie est très puissante dans NCacheIl s'agit d'un mécanisme asynchrone et événementiel permettant à plusieurs applications de gérer entre elles leurs besoins de messagerie ou de coordination. Si plusieurs applications doivent communiquer entre elles, établir une communication devient un défi. Il faudrait donc s'appuyer sur une entité centralisée. NCache est cette entité. Grâce à sa prise en charge de la messagerie, il est possible d'ajouter des données ou des messages à une application. NCache, et ces messages peuvent être propagés à tous les abonnés à l'autre bout : les autres applications qui ont besoin, vous savez, de ces messages.

  

  De même, il peut s'agir de messages axés sur les données. Par exemple, si des données sont ajoutées, mises à jour ou supprimées, vous en êtes informé. Il peut s'agir de messages d'application personnalisés ou de messages axés sur les données, couvrant ainsi les deux zones où les données sont renseignées. NCache Si vous souhaitez que d'autres applications en soient informées, vous pouvez y intégrer les exigences de messagerie. Il peut également s'agir d'une messagerie personnalisée ou pilotée par application, où une application doit communiquer avec une autre. Ce modèle repose sur un modèle évolutif en mémoire. Il offre également des options de réplication fiables. Il repose sur une plateforme de messagerie Pub-Sub classique, basée sur un concept de sujet et un concept de courtier de messages, auquel plusieurs applications sont connectées. Ainsi, vous pouvez définir des applications éditeur et abonné. Les applications éditeur publient des messages. NCache qui sont ensuite transmis à tous ces abonnés. Ces derniers peuvent ensuite envoyer leurs propres messages. NCache agit comme une plateforme de communication entre ces différentes applications.

• Recherche en texte intégral (Lucene distribué)

  Enfin, nous avons un autre cas d'utilisation : la recherche plein texte. Si vous avez une application et que vous devez gérer des exigences de recherche plein texte depuis NCache, vous pouvez envisager d'utiliser nos fonctionnalités de recherche en texte intégral basées sur Lucine.NET.

  Vous savez, l'API Lucene est généralement autonome. Vous pouvez l'étendre à plusieurs serveurs. NCache vous permet également de charger des index en mémoire. Donc, NCache Utiliserait des index sur disque, mais cela permet d'étendre la capacité de stockage et de traitement des requêtes en utilisant plusieurs serveurs. Ainsi, même si le stockage est sur disque, il reste plus performant qu'une source unique sur la base de données. En effet, en cas de charge transactionnelle importante, chaque serveur sera responsable de son propre ensemble de requêtes d'index. L'architecture sera donc très évolutive et très fiable. Comme il s'agit d'un stockage assisté, la persistance des index de scène est une fonctionnalité essentielle. NCache. Toutes les données que vous stockez à l'intérieur NCache Il peut également être conservé sur le disque, ou, selon les fournisseurs de bases de données, sur certaines bases de données. Cependant, Lucene est la seule fonctionnalité permettant NCache utilise le disque par rapport à la RAM, car la nature du cas d'utilisation est telle qu'il nécessite que les données soient persistantes.

  

J'espère que c'était clair. Voici quelques cas d'utilisation. Ces cas d'utilisation présentent de nombreuses fonctionnalités ; tout type d'application, toute exigence spécifique au sein d'une application, peut être entièrement pris en charge grâce à nos fonctionnalités de mise en cache d'objets et de sessions.

Juste une question rapide, Ron.
Puis-je accéder à mes données en cache comme je le fais avec ma base de données MySQL ? Je souhaite pouvoir exécuter des requêtes SQL sur mes données en cache. Puis-je le faire ?

Sûr. NCache Tout d'abord, il prend en charge la recherche SQL et les requêtes LINQ. Donc, si vous savez écrire une application qui se connecte simplement à NCache, puis effectuez des recherches par critères. C'est l'option la plus simple à utiliser : vous pouvez effectuer une recherche par critères. Par exemple, vous pouvez sélectionner tous les produits pour lesquels produit.prix est supérieur à 10 et inférieur à 100. Vous pouvez également rechercher tous les produits par catégorie ; vous pouvez également trouver des clients par région. Vous pouvez ainsi effectuer des recherches SQL ou LINQ. NCache Cela vous fournirait les données du cache. C'est donc une option.

L'autre option est l'intégration de LINQ Pad. Si vous souhaitez simplement visualiser des données sans avoir à développer d'application, LINQ Pad est une solution simple : vous pouvez exécuter des requêtes LINQ, puis visualiser les données en exécutant ces requêtes.

Et puis, dans notre prochaine version, la troisième option consiste à proposer un outil d'analyse de données. Nous vous proposerons un outil de surveillance automatisé qui vous permettra de surveiller les données présentes dans le cache. Il vous proposera des options de recherche par critères depuis une interface utilisateur graphique. C'est un projet en cours de développement ; les prérequis sont terminés et le développement est terminé. Je pense qu'il sera intégré à notre prochaine version.

J'ai vraiment hâte de voir tout ça. Parfait. Ouais. Très bien. Je pense que ça va pour l'instant, Ron. Je garde quelques questions pour la fin, parce qu'on en a des intéressantes, mais bon, on continue. Bien sûr.

Cluster dynamique d'auto-guérison

Alors, ensuite, je vais aborder le cluster de cache dynamique, vous savez, tous les détails à ce sujet. NCache Ce système repose sur un protocole de clustering de cache basé sur TCP/IP. Il s'agit d'une solution de clustering de cache que nous avons implémentée en interne. Nous n'utilisons aucun système de clustering tiers ni Windows. C'est un protocole 100 % propriétaire. Il est écrit en .NET et .NET Core, ce qui le rend très pratique : les sockets TCP sont également basés sur .NET et .NET Core. Son architecture 100 % pair à pair élimine tout point de défaillance unique. Vous pouvez ajouter ou supprimer des serveurs à l'exécution, sans avoir à interrompre le cache ni les applications clientes qui y sont connectées. Ainsi, vous pouvez modifier dynamiquement un cluster de cache en cours d'exécution. NCache Cela ne vous posera aucun problème. Lorsque vous ajoutez un serveur, les clients sont avertis à l'exécution. Ils savent donc automatiquement que ce serveur n'est plus présent et fait désormais partie du cluster de cache. Ils commencent donc à utiliser le serveur supplémentaire, et le cluster s'adapte automatiquement. De même, lorsqu'un serveur est supprimé, les autres serveurs détectent sa disparition définitive. Ils avertissent les clients, qui cessent alors d'utiliser le serveur perdu. Le basculement de connexion est également intégré côté client. Ainsi, en cas de panne d'un serveur, le cluster informe les clients de la panne, bascule la connexion et utilise les serveurs restants.

Ainsi, dans tous les cas, toute modification du cluster est propagée aux clients. Ces derniers sont intelligents et connaissent en permanence l'état du cluster de cache. Cela garantit ainsi l'absence de temps d'arrêt et de perte de données, grâce à la prise en charge intégrée de la réplication. NCache Il est hautement disponible et, grâce à la réplication, très fiable. Il garantit une disponibilité applicative de 100 % sans interruption. Vous pouvez donc continuer à utiliser l'application. NCache.

Topologies de mise en cache

Ensuite, je parlerai des topologies de mise en cache. C'est la partie principale que je voulais aborder. Nous avons le choix entre quatre options. La première option concerne les configurations plus petites. Celles-ci déterminent la configuration d'un cache.

Cache en miroir

Nous avons donc la possibilité de configurer un cache en utilisant une topologie de cache en miroir. Son fonctionnement est le suivant : nous n'utilisons que deux serveurs au maximum. L'un d'eux agit comme serveur actif, auquel tous les clients sont connectés. L'autre serveur agit comme serveur passif, servant de sauvegarde. Cette sauvegarde est effectuée par NCacheUne fois configurée, cette topologie suit automatiquement l'architecture. En fait, vous n'avez pas besoin de définir si cela devient actif ou passif, cela se fait par NCache Automatiquement. Mais une fois cela fait, toutes les applications clientes se connecteront au serveur actif, d'où elles pourront lire et écrire des données. Les données du serveur actif seront sauvegardées sur le serveur passif via une option de mise en miroir asynchrone. Ainsi, le client met à jour le serveur actif, renvoie les données, évitant ainsi le coût de la réplication côté application cliente. L'application cliente sera ultra-rapide. En coulisses, NCache Il est nécessaire de mettre à jour la sauvegarde. Cette sauvegarde est essentielle : en cas de panne du serveur 1, celui-ci est automatiquement mis à jour et devient actif. Les clients basculent alors leurs connexions et utilisent le serveur de sauvegarde précédemment actif. Dès que le premier serveur revient, il rejoint à nouveau le cluster en tant que nœud de sauvegarde, et non plus actif, car un nœud actif est déjà présent dans le cluster de cache. Tout cela est transparent pour vos applications. Aucune intervention n'est requise en cas d'ajout ou de perte d'un serveur.

Cette topologie est très performante en lecture comme en écriture. Elle est donc idéale pour les données de référence et les données transactionnelles, mais elle présente un problème de capacité : vous n'avez que deux serveurs au maximum, et sur ces deux serveurs, un seul est actif à un instant T. Ainsi, pour les configurations plus petites, avec des données fiables, comme la mise en cache, cela pourrait être une option.

Cache répliqué

La deuxième option est un cache répliqué. Elle est également destinée aux configurations plus petites. Tous les serveurs sont actifs ; comme vous pouvez le voir, les serveurs 1 et 2 sont tous deux actifs. Les clients sont répartis sur différents serveurs. Ainsi, si vous avez six clients, comme illustré sur le schéma, certains se connecteront au serveur 2 et d'autres au serveur 2. Ces trois clients sont connectés au serveur XNUMX et ceux-ci au serveur XNUMX.

Cela se fait automatiquement ; l'équilibrage des connexions est quelque chose qui est intégré à l'intérieur NCacheTous les serveurs sont actifs, mais chacun possède une copie du cache. Ainsi, quelles que soient les données du serveur 1, une copie est conservée sur le serveur 2, et cette copie est maintenue grâce aux mises à jour de synchronisation. Ainsi, toutes les mises à jour effectuées sur un serveur doivent être appliquées aux autres serveurs lors d'un appel de synchronisation. Autrement dit, le client attend la fin de l'opération. Si l'opération échoue sur l'un des serveurs, elle est annulée. C'est ainsi que nous obtenons une copie synchronisée à 100 % sur tous les serveurs. C'est une excellente fiabilité, mais aussi pour les cas d'utilisation intensive en lecture, car vous disposez de plus de copies de données ou de copies provenant de différents serveurs. Plus vous avez de serveurs, plus votre capacité de lecture augmente, car vous avez plus de serveurs pour traiter les requêtes. Cependant, comme vous venez de le constater, avec une mise à jour de synchronisation, toute opération d'écriture doit être appliquée à tous les serveurs. C'est donc un bon choix pour les configurations plus petites en termes de capacité d'écriture. Si vous possédez trois ou quatre serveurs, vous devez répéter la même opération trois ou quatre fois, ce qui peut impacter négativement les performances. Cette topologie est donc davantage recommandée pour les scénarios de données de référence et les configurations plus petites. Elle est évolutive en lecture, peu en écriture, mais très fiable. Elle offre une haute disponibilité et une fiabilité des données élevée. En effet, en cas de perte d'un serveur, par exemple le serveur 1, il n'y a aucune perte de données ni interruption de service, car les applications basculent et choisissent le serveur survivant, qui dispose déjà d'une copie du cache.

Cache partitionné et cache de réplication de partition

L'option suivante consiste à configurer un cache partitionné. Les topologies partitionnées et réplica de partition sont les plus courantes. Le cache partitionné permet de répartir les données entre les nœuds de serveur disponibles. Par exemple, si vous avez deux serveurs et des données, la moitié des données seront placées sur le serveur 1 et l'autre sur le serveur 2. La répartition des données fait également partie de cette configuration. NCacheCe n'est pas une opération effectuée par vos applications, mais automatiquement par elles lors de leur exécution. Une carte de distribution intelligente et un algorithme de hachage déterminent quelles données sont envoyées à quel serveur.

Ainsi, vos applications répartissent les données uniformément entre tous les serveurs du cluster de cache. La charge de vos requêtes est ainsi répartie uniformément. Vous bénéficiez ainsi d'une capacité de lecture et d'écriture accrue en fonction du nombre de serveurs. Si vous avez deux serveurs, vous travaillez en équipe. De deux à trois, vous disposez de plus de serveurs pour gérer vos requêtes de lecture et d'écriture. Vous bénéficiez ainsi d'une plus grande évolutivité en lecture et en écriture. De manière linéaire, l'ajout de serveurs permet une plus grande évolutivité. En ajoutant des serveurs, vous mutualisez également les ressources mémoire, car les données sont distribuées, et donc le stockage de tous les serveurs est mutualisé. Ainsi, si vous avez deux serveurs, vous avez une capacité de deux serveurs. Si vous ajoutez un troisième ou un quatrième serveur, vous augmentez votre capacité de ce nombre. La capacité globale est mutualisée, ce qui permet une croissance linéaire à mesure que vous ajoutez des serveurs au cluster de cache.

Excellent pour les lectures et les écritures, et très évolutif pour les données de référence et transactionnelles. Le seul inconvénient de cette topologie est l'absence de sauvegarde. Si vous perdez un serveur, vous perdez sa partition. Dans ce cas, il est donc nécessaire de pouvoir reconstruire ces données à partir d'une base de données back-end. Ainsi, si votre objectif principal est d'atteindre des performances élevées, si vous avez une application axée sur les performances et que vous pouvez vous permettre de revenir à une base de données, ce qui est souvent le cas, vous ne dépendez pas d'une base de données. NCache pour une haute disponibilité et une fiabilité des données, cela vous offrira les meilleures performances par rapport à toutes les autres topologies.

Mais si vous avez besoin d'une haute disponibilité et que vous savez que les exigences de fiabilité des données doivent également être satisfaites NCacheJ'ai une meilleure topologie, appelée partitionnement du cache de réplicas. L'architecture globale est identique à celle d'un partitionnement avec réplicas améliorés : chaque serveur possède une partition de données, mais chaque serveur gère deux partitions : une partition de données active, où les clients sont connectés, et une partition de sauvegarde d'un autre serveur. Le serveur 1 est actif, sa sauvegarde est sur le serveur 2 ; le serveur 2 est actif, sa sauvegarde est sur le serveur 1. Vous pouvez choisir entre une sauvegarde synchronisée ou asynchrone. Si vous choisissez une partitionnement du réplica avec asynchrone, le client mettra à jour la partition active et affichera un message indiquant que les opérations sont terminées sur le client. NCache La partition de sauvegarde sera mise à jour en arrière-plan. Si vous choisissez la synchronisation, l'application cliente mettra à jour la partition active et la sauvegarde comme une opération transactionnelle. Quoi qu'il en soit, la synchronisation est évidemment plus fiable, tandis que l'asynchrone est plus rapide. Mais dans les deux cas, NCache Il est capable de gérer la fiabilité des données de telle sorte qu'en cas de panne d'un serveur, la topologie de secours est activée, évitant ainsi toute perte de données ou interruption d'application.

Je vais vous présenter rapidement cette topologie à trois serveurs. Nous bénéficions ainsi de performances élevées en lecture et en écriture, ainsi que d'une évolutivité linéaire en lecture comme en écriture. De plus, nous bénéficions d'une évolutivité, d'une haute disponibilité et d'une fiabilité des données optimale. En cas de panne d'un serveur, il n'y aura aucune perte de données ni interruption d'application.

Demo

J'espère que c'est clair. Je vais maintenant vous présenter notre environnement de démonstration et vous montrer rapidement comment construire ces topologies de mise en cache. Je vous montrerai également comment tester rapidement un cluster de cache. En attendant, n'hésitez pas à me contacter si vous avez des questions. Pour rappel, nous pouvons également vous accompagner dans toutes les étapes de ce que nous présentons lors de sessions d'accompagnement et de support technique dans vos environnements, pour vos cas d'utilisation spécifiques. Nous serions ravis de vous rencontrer pour discuter de tout ce que nous abordons ici, même après le webinaire, afin de vous montrer comment cela fonctionne pour vous.

Concernant les questions, j'en ai une qui est arrivée juste à la fin. L'une d'elles est l'une de vos préférées.
L'utilisation de Hazelcast pour la mise en cache des applications a fait l'objet de nombreuses discussions. Qu'est-ce que NCache à condition que Hazelcast ne le fasse pas ?

Ok. Tout d'abord, c'est plutôt un débat. NCache est en fait écrit en .NET et .NET Core, donc plateforme privilégiée pour NCache est Windows. L'avantage de NCache Il fonctionne sur .NET, ainsi que sur Windows et Linux. La plateforme et la compatibilité sont donc compatibles. NCache Aucun autre produit ne propose une telle offre. C'est donc le premier point, celui qui est le plus avantageux si vous envisagez d'utiliser une plateforme. L'autre différence, c'est que j'encourage tout le monde à consulter notre site. pages de comparaison, vous y trouverez également de très bons documents. Mais, pour résumer rapidement, NCache La prise en charge de la mise en cache d'objets offre de nombreuses fonctionnalités, totalement absentes des autres produits. Par exemple, la recherche SQL bénéficie d'un ensemble complet de fonctionnalités intégrées. NCacheNous disposons d'un chargeur et d'un rafraîchisseur de cache. Ces fonctionnalités sont entièrement exclusives à NCacheNotre gestionnaire de lecture et d'écriture directes, capable d'exécuter du code .NET et .NET Core côté serveur, est une fonctionnalité absolument unique. NCache, et la liste est longue. Voici quelques fonctionnalités personnalisables côté serveur. Elles ne sont disponibles que dans NCache Du point de vue des applications, de nombreuses fonctionnalités manquent à d'autres produits. J'encourage donc tout le monde à consulter notre page de comparaison. Des comparaisons, fonctionnalité par fonctionnalité, y sont publiées et vous donneront des informations plus détaillées.

C'est certainement notre ligne de questionnement préférée, qu'il s'agisse d'un webinaire ou même d'une solution technologique, cela pourrait être Hazlecast, cela pourrait être Scala, cela pourrait être Redis, mais merci beaucoup, Ron. Oui, je pense que c'est bon. Continue, s'il te plaît. Bien sûr.

Créer un nouveau cache en cluster

Alors, laissez-moi vous faire une démonstration rapide du produit en créant un nouveau cache clusterisé. Appelons-le cache de test. Bon, je vais déplacer ce passage ici, soyez patients. OK.

Nous venons d'expliquer quatre topologies de mise en cache. Je vais opter pour la partition de cache de réplication, car c'est la plus recommandée avec l'option de réplication asynchrone. Je conserverai toutes ces valeurs par défaut.

Je vais maintenant vous montrer à quel point il est facile de configurer un cache avec des outils d'interface graphique. Il s'agit de notre gestionnaire web, mais vous pouvez également tout gérer avec nos applets de commande PowerShell, et vous pouvez automatiser ce déploiement si nécessaire. J'ajouterai le serveur 1, où NCache est installé. J'ajouterai ensuite le serveur 2. Donc, mes deux machines avec NCache Un cluster de cache de 2 Go va être mis en place. Mon idée est de créer un cluster de cache à deux nœuds, chacun avec 2 Go de cache. Soit un total de quatre Go avec deux serveurs. NCache est déjà installé. Ensuite, j'utiliserai ma box pour me connecter à ce cluster de cache.

Paramètres TCP. Il s'agit du port à configurer une fois cette étape effectuée. Conservez-le par défaut ou spécifiez un port non affecté par le pare-feu.

Si vous devez configurer le chiffrement et la compression, voici l'écran. Je vais le conserver tel quel. Choisissez ensuite « Évictions ». Si votre cache est plein, vous pouvez choisir cette option. Une option consiste à ce que votre cache n'accepte aucune opération d'écriture. Une erreur « cache plein » s'affiche. Une autre option consiste à configurer l'éviction, qui, en fonction de ces algorithmes, supprimera certains éléments du cache lors de l'exécution. Ainsi, en fonction de la priorité, de l'utilisation, des éléments les moins récemment ou fréquemment utilisés, 5 % des éléments seront supprimés du cache. Je lancerai ce cache à la fin et le démarrerai automatiquement, de sorte qu'il soit activé à chaque redémarrage du serveur. NCache le serveur redémarre il est capable de redémarrer les caches qui sont arrêtés.

Je choisis « Terminer », et voilà. Configurer un cluster de cache est aussi simple que ça. Dans quelques instants, une autre vue s'affichera, où ce cache sera démarré, et je vous montrerai ensuite quelques détails de surveillance et de gestion. Nous avons des vidéos plus détaillées sur la configuration du cache. Si vous avez des questions, n'hésitez pas à me contacter. Nous pouvons également les consulter.

Je peux sélectionner « Surveiller le cluster », ce qui ouvrira un autre tableau de bord me permettant de surveiller entièrement mon cache. Il affiche un cluster de cache entièrement connecté, les compteurs de débit de requêtes, les compteurs de latence, ainsi que les compteurs d'ajouts, de récupérations et de mises à jour. De même, il affiche l'utilisation du processeur et de la mémoire, ainsi que les situations de cache saturé.

J'ai également des tableaux de bord pour les clients, ainsi qu'une vue de rapport affichant les tableaux de bord côté serveur et côté client. Aucune application n'y est actuellement connectée, mais je peux simuler une charge grâce à ce bouton « test-stress ». Je peux ainsi lancer une charge fictive ou une activité sur mon cluster de cache en appelant ce bouton. Dès que je le fais, vous constaterez qu'un client est connecté et que cette topologie nécessite la distribution de mes données. Ainsi, certaines données sont envoyées sur le serveur 1 et d'autres sur le serveur 2. Ce client utilise donc les deux serveurs de manière homogène. Comme vous pouvez le constater, les requêtes arrivent sur les deux serveurs et la taille du cache augmente sur les deux serveurs.

Des partitions actives et de sauvegarde sont également affichées sur les deux serveurs. Si je vous montre rapidement les compteurs de latence, je constate que la latence est inférieure à la milliseconde, voire à la microseconde, pour mes opérations. Le tableau de bord client affiche également les statistiques côté client, et un rapport similaire présente les statistiques côté serveur.

Ron, j'ai une question, en fait nous avons reçu plusieurs questions, donc l'une d'entre elles est :
Quelle est votre recommandation pour l'éviction ? Et, si c'est au moins l'éviction, attendez la prochaine étape : si l'éviction est désactivée, pouvons-nous augmenter ou réduire la taille du cache ?

Bien sûr. L'éviction doit être configurée en fonction de votre cas d'utilisation. Si vous pouvez vous permettre d'évincer des données, l'éviction elle-même supprimera des données si votre cache est saturé. Idéalement, vous n'aurez jamais à le faire et votre cache est largement dans les limites de sa capacité. Vous devez donc allouer suffisamment de taille ou de mémoire à votre cache pour qu'il ne soit jamais saturé. Mais si cela arrive, il peut arriver qu'il soit saturé. Dans ce cas, si vos données sont reconstituables à partir d'une base de données back-end, il est recommandé d'activer l'éviction. Par exemple, pour les sessions ASP.NET, nous déconseillons l'activation de l'éviction, car vous supprimeriez des utilisateurs pour faire de la place aux nouveaux utilisateurs, et chaque utilisateur dispose de ses données importantes. Il s'agit donc de données à ne pas perdre, quel que soit le scénario. Dans ce cas, nous recommandons d'augmenter la taille du cache. Planifiez la taille de votre cache de manière à ce qu'elle soit suffisamment grande et dans les cas où elle devient pleine NCache Vous permet de modifier la taille du cache à l'exécution. Vous pouvez modifier cette option et, en conséquence, augmenter et enregistrer ces paramètres dans un cache en cours d'exécution. Cette option n'est donc pas applicable et augmentera la taille du cache à l'exécution.

D'autres questions ? On dirait que j'y ai répondu, et j'en garde quelques-unes pour la fin, afin que vous puissiez terminer votre démonstration. Bien sûr. Pour revenir à mon environnement de démonstration, vous pouvez ajouter des clients. Par exemple, je peux ajouter ma machine comme client. Voici un aperçu rapide d'une application d'exemple que je peux exécuter depuis ma machine. Par exemple, elle est également disponible sur GitHub. Si vous cherchez… NCache Sur GitHub, vous trouverez des exemples, dont j'ai extrait un. Ce qu'il vous faut donc faire dans votre application, c'est inclure ce package NuGet. Alachisoft.NCache.SDK, et si vous êtes intéressé par mise en cache des données d'applicationVoici l'exemple à considérer. Une fois ajouté, vous pourrez inclure des ressources dans l'application.

Cela inclura déjà certaines, vous savez, des bibliothèques de NCache, dans le cadre de ce nouveau package NuGet. Ensuite, vous incluez cette référence en utilisant Alachisoft.NCache.Client. Ajoutez également Exécution.Mise en cache, d'accord, et à partir de là, vous pouvez définir un gestionnaire de cache, qui contient plusieurs méthodes. Par exemple, laissez-moi vous montrer comment initialiser le cache. Allons-y. Soyez indulgents, j'ai du mal. Pour une raison que j'ignore, je n'arrive pas à y accéder ; je pense qu'il y a un problème avec la boîte elle-même. Quoi qu'il en soit, les API sont assez intuitives. Laissez-moi vous montrer notre PowerPoint. Cet exemple utilise cela, mais je ne peux pas le démontrer car je ne peux pas accéder au code. Il ne me le permet pas.

Donc, c'est un handle de cache et c'est le morceau de code que je voulais montrer, que le CacheManager.GetCache vous permettra de vous connecter au cache. Vous pourrez ensuite appeler cache.Obtenir pour récupérer les données du cache. De même, vous pouvez appeler cache.Ajouter or cache.AddAsync pour ajouter des enregistrements dans le cache et les insérer de la même manière que dans upsert où il ajoute, ainsi que met à jour les données dans le cache et de la même manière, vous pouvez appeler cache.Supprimer.

Donc ça échantillon est disponible, téléchargeable et exécutable sur votre cache. Il suffit de pointer vers le cache depuis l'application. Plusieurs configurations sont possibles. Vous pouvez spécifier le nom et l'adresse IP du cache en ligne, ou utiliser un fichier client.ncconf, inclus dans le projet avec ce package NuGet. Si je vous présente rapidement quelques ressources, vous constaterez que de nombreux fichiers sont ajoutés, et celui-ci permet de se connecter au cache. Il est donc déjà capable de se connecter à mon « democache ». Si je l'exécute, il effectuera une action sur mon cache et lancera les opérations de mise en cache.

De la même manière, j'ai un autre exemple qui va donner, vous savez, quelques options supplémentaires, par exemple, il y avait une question sur chercher à l'intérieur NCache, d'accord. Je vous recommande donc d'utiliser cet exemple. Il est destiné à la recherche SQL. Il est téléchargé depuis GitHub et utilise la recherche, il contient des données d'exemple et appelle la recherche via SQL. Il offre de nombreuses fonctionnalités, toujours dans le même esprit ; les exemples sont assez intuitifs. Vous pouvez insérer des éléments, puis effectuer des requêtes à l'aide de balises nominatives, d'index définis ou de projections.

Malheureusement, je ne peux pas entrer dans ces méthodes en raison des problèmes environnementaux, mais encore une fois, elles serviraient de point de référence pour leur utilisation. NCache à partir de n'importe quelle application, qui doit utiliser la mise en cache au sein de l'application, ou qui a un cas d'utilisation de recherche au sein de l'application.

Cache Client

Il y avait une autre question à propos de Cache Client, cette topologie est donc également une option sans modification de code. Toutes les données mises en cache depuis une base de données sont NCacheVous pouvez le mettre en cache en utilisant le cache client. Il s'agit d'un cache superposé à un autre. Il fonctionne sans modification de code. Il s'agit d'un cache synchronisé avec un cache clusterisé, ce qui évite tout problème de cohérence des données. La synchronisation est effectuée par NCacheToutes les mises à jour effectuées sur un cache client sont impérativement propagées au cache clusterisé, puis aux autres caches clients. Ce cache gère la synchronisation. Pour les scénarios de données de référence, où les écritures sont peu nombreuses, cette option est fortement recommandée.

Réplication WAN

De même, le NCache a aussi un Réplication WANNous proposons des topologies active-passive et active-active. Ainsi, l'intégralité de vos données de cache peut être répliquée d'un centre de données à un autre via notre cache pont. Ce dernier est sauvegardé sur un serveur actif-passif, ce qui permet de disposer d'un cache source et d'un cache cible, d'une réplication unidirectionnelle ou d'une migration est-ouest des données d'un centre de données à l'autre, pour les scénarios de reprise après sinistre ou de migration est-ouest, ou encore pour les situations où vous avez besoin des données d'une application et devez les utiliser pour l'application cible. Vous pouvez ainsi transférer l'intégralité des données de cache d'un centre de données à l'autre.

L'autre option est active-active. Dans ce cas, les deux sites sont actifs : le site 1 transfère les données au site 2, et le site 2 au site 1. Là encore, il ne faut pas modifier le code. Il s'agit simplement d'une configuration. Une fois le pont configuré, vous connectez les deux caches ensemble. NCache prend le relais et démarre la réplication des données entre ces caches.

Ceci s'applique également à la topologie multi-active-active. Ainsi, il n'est pas nécessaire d'avoir seulement deux sites, mais bien trois, quatre ou cinq sites, tous échangeant des données. NCacheLa capacité de synchroniser les données de tous les sites simultanément. De plus, cette opération est asynchrone, ce qui évite les coûts de réplication côté application ou côté utilisateur. Elle est effectuée au niveau de l'application. Vos applications clientes sont connectées ici et là. Elles ne subissent aucune dégradation de performances due à cette réplication WAN. Elle est gérée en arrière-plan. NCacheN'hésitez pas à me contacter si vous avez des questions. Nous allons maintenant conclure la présentation et les fonctionnalités. Zack, n'hésitez pas à me contacter si vous avez des questions.

Oui, nous en avons quelques-unes. Et j'apprécie votre patience, tout le monde. C'est donc l'occasion de poser d'autres questions si vous vous les êtes posées tout au long de la présentation. Commençons par une.
Comment vérifier si votre cache fonctionne correctement ? Recevons-nous des notifications, etc. ? Comment savoir s'il y a un problème ?

Bien sûr. Nous avons outils de suivi et de gestion. Une solution consiste à inspecter visuellement l'état du cluster, notamment l'utilisation du processeur et de la RAM. Si vous connaissez votre base de référence, vous savez combien de requêtes vos applications génèrent et quelle est leur utilisation typique. NCache Grâce à ces compteurs, vous pouvez effectuer une inspection visuelle grâce à nos tableaux de bord de surveillance et de gestion. Nous générons des alertes pour toute situation : démarrage ou arrêt d'un cache, jonction ou déconnexion d'un nœud, saturation du cache, ou encore état défectueux du cluster (split-brain, par exemple). Ces alertes sont enregistrées dans les journaux d'événements Windows. Vous pouvez également configurer des alertes par e-mail. NCache, et il peut également vous envoyer un e-mail. Il s'agit donc d'une surveillance proactive, avec des alertes. NCache, Où NCache Vous recevrez une alerte et pourrez agir en conséquence. Nous disposons également de données historiques capturées sous forme de journaux de compteurs de performances, ainsi que de journaux de cache. Pour les situations où vous ne saviez pas ce qui s'était passé et où vous avez constaté des problèmes. NCache, nous pouvons venir nous impliquer et nous pouvons revoir NCache journaux et évaluer l'état du cache dans ce cas. Il existe donc de nombreuses pistes à explorer à ce sujet.

Ça a l'air bien. Autre question :
Quelle est la dernière version de .NET qui NCache prend actuellement en charge les clients ?

D'accord. En général, nous utilisons la dernière version du framework .NET, .NET Core. .NET 6 est actuellement pris en charge ; c'est une condition préalable. NCache. Vous devez avoir .NET 6 comme une chose obligatoire sur NCache Concernant les serveurs, vos applications peuvent utiliser n'importe quel framework .NET, notamment les versions 3.5 à 4.0, 4.5, voire 4.7 et 4.8. Elles peuvent également utiliser n'importe quel framework .NET ou .NET Core. La limitation concerne uniquement le serveur. Dès qu'un framework plus récent, comme .NET 7, est testé (nous le testons déjà dans notre laboratoire d'assurance qualité), nous le validons et nous le prenons officiellement en charge.

Magnifique. Autre question :
Quel est, selon vous, le nombre maximal de caches groupés entre mes serveurs de cache ? Puis-je créer, par exemple, 15 caches groupés entre mes serveurs ?

D'accord. Tout d'abord, NCache Il n'y a aucune limite au nombre de caches configurables. D'ailleurs, dans mon environnement de démonstration, j'en ai configuré deux. Vous pouvez donc en créer autant que nécessaire. Cependant, il existe une recommandation technique, ou une recommandation liée à la capacité, que nous recommandons généralement en environnement de production : ne pas dépasser quatre ou cinq caches. Chaque cache étant un cluster de cache distinct, il consomme toutes les ressources de stockage, de clustering et de communication, ce qui engendre également une surcharge de gestion. Ainsi, augmenter le nombre de caches augmente la capacité de l'environnement, ou au sein de celui-ci. Nous recommandons donc de limiter ce nombre à quatre ou cinq, si possible. Si vous devez disposer de plusieurs caches, vous pouvez aller jusqu'à dix. Mais, comme je l'ai dit, il s'agit là encore d'une recommandation. Il n'y a pas de limite réelle. C'est une recommandation générale de notre part.

Ok. Laissez-moi ajouter une dernière chose, car je sais que nous sommes à la fin de la session et que vous avez d'autres choses à faire.
Pouvez NCache fournir une réplication DR ?

Oui, c'est le cas. La fonctionnalité de réplication WAN dont je viens de parler, la dernière topologie, couvre la reprise après sinistre. Les sites peuvent transmettre les données du site actif, ce qui permet de disposer d'un site de reprise après sinistre entièrement sauvegardé. Il suffit d'effectuer un basculement côté application. Comme toutes les données sont déjà sauvegardées, il n'y a aucune perte de données en cas de panne complète d'un centre de données ou si vous devez le mettre hors service pour maintenance.

Très bien. Je pense que nous avons réussi à en gérer le plus possible. Mesdames et Messieurs, sachez que nous sommes également disponibles en dehors de ces sessions. Nous serions ravis de collaborer avec vous pour analyser vos configurations existantes, si vous utilisez déjà NCache. Si vous êtes nouveau dans NCache, nous serions heureux de vous proposer un essai et d'organiser des séances d'accompagnement pour vous expliquer comment cela fonctionnerait dans vos applications intégrées, mais surtout, sachez que vous pouvez nous contacter à tout moment pour toute question concernant NCache, ou même utiliser le produit et si vous avez besoin d'aide. De nombreuses nouveautés arrivent bientôt, ainsi que de nouvelles versions. Restez connectés ! D'autres webinaires seront bientôt disponibles.

Un tonnerre d'applaudissements pour Ron. J'apprécie vraiment que vous ayez pris le temps de nous accorder une séance aujourd'hui et j'ai hâte à la prochaine. Merci à tous. Merci Zack. Bien sûr. Très bien, tout le monde. Passez une excellente journée et au plaisir de vous retrouver pour notre prochain webinaire. Petite précision : après la fin de ce webinaire, nous publierons un enregistrement sur notre site web. Si vous n'avez pas eu l'occasion d'obtenir des réponses à vos questions ou si vous souhaitez revenir sur certains points abordés, n'hésitez pas à revenir sur notre site web pour visionner l'enregistrement.

Très bien. Salut à tous. Vous avez passé une bonne journée. Merci à tous. Au revoir.

Que faire ensuite?

• NCache DÉTAILS
• Télécharger NCache
• Demander une démo personnalisée en direct