NCache Architecture

Spectacle enregistré
Par Ron Hussain et Zack Khan

Le webinaire d'aujourd'hui sera basé sur NCache Architecture. Nous allons maintenant aborder un aperçu de la mise en cache distribuée et comment elle résout vos goulots d'étranglement dans .NET et .NET Core. Nous allons passer en revue les cas d'utilisation courants, ainsi que l'architecture du cache distribué et les détails du clustering, ainsi que toutes les questions que vous pourriez vous poser concernant non seulement NCache, mais la mise en cache en général. Désormais, à tout moment tout au long de ce webinaire, nous avons la possibilité de poser des questions ici dans l'onglet Questions GoToWebinar, alors veuillez jeter un œil à votre convenance pour l'onglet Questions. Et, une fois que vous aurez écrit une requête, je pourrai en parler lors de 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 séance pour pouvoir répondre à toutes les autres questions qui pourraient nous être posées, mais nous avons hâte de passer un bon moment.

Alors, sans plus tarder, je vais céder la parole à Ron, et commençons. Très bien, merci, Zack. Donc, comme Zack vient de le mentionner, le sujet d'aujourd'hui est NCache architecture. Dans ce webinaire, je vais expliquer 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 vos applications. Quels sont ces cas d’utilisation et comment en tirer pleinement parti ? NCache au sein de vos applications serveur ?

J'espère donc que tout le monde pourra voir mon écran. Si je peux obtenir une confirmation rapide à ce sujet, je m'y mettrai rapidement. Ouais, je pense que tout va bien si tu peux. Et voilà, je pense. Ouais, ça a l'air bien. Parfait. D'accord, commençons rapidement par cela.

Le problème de l'évolutivité

Très bien, définissons d'abord ce que NCache est? 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 de serveur typique dans laquelle des applications sont déployées, il s'agit généralement de plusieurs instances ou de plusieurs serveurs, vous savez, si ces applications sont déployées. On peut donc affirmer sans se tromper que votre niveau d’application est très évolutif.

Vous pouvez ajouter autant de serveurs dans un niveau d'application. Vous pouvez créer un formulaire Web, un formulaire d'application, dans lequel plusieurs serveurs d'applications ou serveurs Web hébergent la même application, mais ils travaillent en équipe et se partagent la charge des requêtes entre eux. Et, si vous optez pour une architecture plus récente, avec même une architecture de microservices, vous avez la possibilité de faire évoluer individuellement vos services d'application, des microservices qui nécessitent plus de calcul ou plus de capacité de traitement des requêtes.

Le niveau App est donc très évolutif. C’est évolutif linéairement. À mesure que vous grandissez, vous êtes en mesure de gérer de plus en plus de demandes. Le problème entre en jeu lorsque vous utilisez une base de données, telle qu'une base de données relationnelle. Parce que toutes ces applications, quel que soit leur niveau d'évolutivité, elles devraient toujours communiquer avec une base de données principale. Et lorsqu’ils communiquent avec une base de données principale, il s’agit généralement d’une source unique. Et ce n’est pas très évolutif. C'est très bien pour le stockage ; vous pouvez disposer de beaucoup de ressources disque. Ainsi, vous pouvez en tirer des avantages en matière de stockage. Mais lorsque vous avez une énorme charge transactionnelle sur vos applications, et que cela se traduit par une charge transactionnelle de base de données, les bases de données ont tendance à s'étouffer. Et c’est le principal problème, vous savez, où l’application a du mal à gérer les requêtes. Ce n'est pas évolutif et l'expérience de l'utilisateur final est également compromise.

NoSQL databases résolvent quelque peu ce problème. Vous pouvez avoir une base de données SQL, mais cela nécessite que votre application soit ré-architectée de telle manière qu'elle cesse d'utiliser une base de données relationnelle et commence à utiliser une base de données relationnelle. NoSQL database et c'est un gros projet. Donc, NoSQL n'est pas toujours une solution à un problème d'évolutivité.

La solution: NCache Cache distribué

Alors, que devrions-nous faire maintenant lorsque nous avons cela ? La solution est très simple : vous devez disposer d'un cache distribué en mémoire, comme dans NCache. Tout d'abord, il est en mémoire, donc l'avantage numéro un que vous obtenez est que les performances de votre application seront augmentées. C'est ultra-rapide par rapport à une base de données relationnelle. Et le principal avantage est qu’il est évolutif de manière 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 qui peut fonctionner sur plusieurs boîtiers. Et, comme vous le savez, vos exigences ou vos besoins augmentent, vous devez disposer de plus de capacité de traitement des requêtes qui doivent être gérées à partir de votre niveau d'application, vous pouvez ajouter plus de serveurs au moment de l'exécution dans le cluster de cache.

La bonne chose à propos de NCache c'est que vous l'utilisez en complément d'une base de données relationnelle ; ou une base de données back-end, cela ne remplace pas vos sources de données conventionnelles. C'est quelque chose qui complétera, vous savez, les sources de données existantes de manière à pouvoir augmenter les performances de vos applications. Il est capable d'augmenter la capacité de traitement des requêtes pour vos applications. Et, à mesure que vous développez l'application, vous pouvez toujours augmenter le nombre de serveurs dans le cluster de cache, car ce sont des serveurs dans un cluster, ils travaillent donc en équipe. Ils sont capables de répartir la charge des requêtes entre eux de manière à vous offrir ainsi une évolutivité linéaire. Donc, NCache est un modèle évolutif linéairement et très facile à utiliser. Parlons du fonctionnement de l'architecture de déploiement. Ainsi, dans un environnement de production généralement important, voici comment NCache ressemblerait à:

Vous auriez un tas de serveurs. Il peut s'agir d'un service Windows ou Linux, conçu de telle manière que NCache se situe entre votre application et la base de données. Par exemple, vous pouvez commencer avec deux ou trois NCache serveurs, puis vous pouvez augmenter jusqu'à quatre ou cinq NCache serveurs et différents types d'applications, par exemple, votre ASP.NET ou ASP.NET Core applications Web, votre .NET ou .NET Core services, ou .NET/.NET Core applications serveur. Ou même cela pourrait être Java ou Node.js. Ainsi, ces applications peuvent également profiter de la mise en cache distribuée.

NCache lui-même est écrit en .NET/.NET Core. Il fonctionne aussi bien sous Windows que sur les boîtiers Linux. De même, vos applications pourraient être sur n’importe quelle plate-forme et cela fonctionnerait sans problème. En règle générale, nous vous recommandons d'avoir NCache sur des serveurs de configuration dédiés, qui hébergent uniquement NCache, afin que vous disposiez d'une nature dédiée aux ressources pour NCache. Et puis vos serveurs d’applications se trouvent sur un niveau distinct. Afin que vous disposiez également de ressources dédiées à vos applications. Mais il existe également une autre option de déploiement, qui permet, pour des configurations plus petites, d'avoir NCache assis sur les mêmes boîtiers, où vos applications s'exécutent également. Donc c'est toujours une possibilité avec NCache. Mais, comme indiqué, l’option recommandée est de disposer d’un niveau de cache distinct, comme indiqué dans le diagramme. Et puis NCache se situe entre votre application et la base de données. L'idée ici est de mettre en cache toutes les données que vous utilisez le plus fréquemment dans vos applications. Il peut s'agir d'une donnée de référence ou d'une donnée transactionnelle. Par "référence", j'entends des données qui nécessitent plus de lecture, et par "transactionnelles", j'entends des données qui sont à la fois intensives en lecture et en écriture. Et, une fois que vous savez quelles données mettre en cache, vous pouvez appeler ces données votre « ensemble de travail ». Pour la première fois, vous pouvez récupérer ces données de la base de données, puis vous pouvez également les ajouter à l'intérieur NCache et les appels ultérieurs peuvent être traités via NCache seulement, vous enregistrez des voyages coûteux dans la base de données. C'est ce que nous appelons généralement le modèle « cache-aside », dans lequel toutes les modifications que vous apportez sont également propagées au cache puis à la base de données. Et aucune base de données n'existe dans le cache, vous la récupérez toujours dans la base de données et la conservez à l'intérieur NCache mais vous vérifiez toujours 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 vous revenez à partir de ce point.

Lecture/écriture

L'approche alternative consiste à utiliser la « lecture continue » ou « l'écriture directe », qui est représentée ici par des lignes pointillées. NCache a une fonctionnalité qui peut automatiser cela, où elle vous offre une option de « mise en cache » et elle est appelée « lecture continue » pour les lectures et « écriture directe » pour les écritures. Cela fonctionnera de telle manière que vous utilisez toujours le cache comme source principale et que vous implémentez un gestionnaire de lecture et d'écriture sur le cache et qui se chargera de la mise à jour des sources de données backend. Ainsi, quelles que soient les opérations de lecture que vous effectuez, si les données n'existent pas, elles accéderont de manière transparente à votre base de données en fonction de votre fournisseur, les récupéreront pour votre application, reviendront également à l'application et les stockeront également à l'intérieur. NCache. Pour les mises à jour, il mettra à jour le cache ainsi que la base de données selon une approche synchronisée ou asynchrone, en fonction du 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és sous forme de serveur, où plusieurs applications ou formulaires de candidature, ils peuvent se connecter à NCache et ils peuvent alors profiter d'une mise en cache distribuée, où l'accès à la mémoire améliore les performances des applications. Et le fait d’avoir plusieurs serveurs dans le niveau de cache peut vous offrir une évolutivité linéaire. J'espère que c'était clair ; s'il vous plaît laissez-moi savoir s'il y a des questions. Eh bien, heureusement, pour le moment, il semble qu'il n'y en ait pas, alors n'hésitez pas à continuer. Très bien.

NCache Chiffres d'évolutivité

Alors ensuite, je parlerai de NCacheles chiffres d'évolutivité. Nous venons de le mentionner NCache est capable de résoudre le problème d’évolutivité de votre application. Donc, NCache lui-même est évolutif linéairement. Ainsi, le niveau d'application étant évolutif, vous savez, ayant un goulot d'étranglement de base de données résolu grâce à un modèle linéairement évolutif, voici quelques chiffres que vous pouvez prendre comme référence. Il s'agissait de nos tests de référence que nous avons effectués dans notre environnement d'assurance qualité. Nous avons utilisé des serveurs riches en CPU et en RAM afin de pouvoir vraiment les étendre et les utiliser dans une situation de charge élevée. Nous avons commencé avec un serveur et avons continué à augmenter la charge des applications avec deux serveurs. Dès qu'un ensemble de serveurs a atteint sa capacité maximale de CPU et de RAM, c'est à ce moment-là que nous avons ajouté un autre serveur.

C'est la règle empirique ; où vous pouvez continuer à utiliser les serveurs de cache existants, commencez avec deux NCache serveurs, et lorsque vous voyez que ces deux serveurs sont au maximum de leur capacité matérielle, si votre processeur est au maximum ou si votre RAM est au maximum, c'est à ce moment-là que vous faites un choix que je dois maintenant faire évoluer et je besoin d'ajouter un troisième serveur dans le cluster de cache. C'est exactement ce que nous avons fait avec une taille moyenne d'objet de 1 kilo-octet : nous avons continué à augmenter la charge des applications et à augmenter le nombre de serveurs. Jusqu'à ce que l'ensemble de serveurs donné soit atteint au maximum. Et il ne s’agissait pas de données instantanées ; il s'agissait de données d'application réelles mais simulées dans notre laboratoire d'assurance qualité. Ainsi, avec deux serveurs, avec trois, quatre, cinq, jusqu'à cinq serveurs, nous avons pu traiter 2 millions de requêtes par seconde avec une taille moyenne d'objet de 1 kilo-octet.

Il s’agissait donc d’une combinaison de lectures et d’écritures appliquées de manière cohérente sur le cache. Ainsi, au total, un débit de 2 millions de requêtes par seconde a été atteint. Et en même temps, sans faire de compromis sur les performances. Ainsi, le débit ne consiste pas seulement à avoir un grand nombre de requêtes par seconde ; mais la latence des requêtes individuelles doit également être maintenue, et elle doit être ultra-rapide. Une démonstration vidéo ainsi qu'un livre blanc sont publiés sur notre site Internet (Voir ici). Et c’est quelque chose que vous pouvez également consulter.

Utilisations courantes du cache distribué

Bon, 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'application. Ce sont maintenant les données qui proviennent d’une base de données principale. Nous avons déjà établi que la base de données est généralement lente car elle est basée sur disque, en comparaison la RAM est une source plus rapide. L’autre problème est que la base de données a tendance à s’étouffer en cas de trafic élevé. Si vous avez une charge transactionnelle importante et qu'il n'y a qu'un seul serveur, on s'attend à ce qu'il ne vous offre pas les performances dont vous avez besoin du côté de l'application. Il est donc tout à fait logique de mettre en cache les données des applications dans vos applications en utilisant NCache. C'est très simple; tu utilises NCache API et vous appelez simplement le cache. Vous vous connectez au cache en appelant les API d'initialisation du cache. Une fois connecté au cache, vous pouvez alors appeler 'cache.Ajouter, cache.Mettre à jour, cache.Supprimer' ou 'cache.Obtenir' pour récupérer les données du cache. Je vais donc vous montrer quelques exemples vers la fin. Mais l'idée ici est que quelles que soient les données, vous pensez que vous allez les lire plus d'une fois, qu'il s'agisse de données de référence ou de données transactionnelles. Pour les données de référence, 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.

  

  Effectivement, les données dans le cache seront utilisables pendant une période plus longue. 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 cela vous offre une évolutivité 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 également en cache une partie, voire la plupart de vos données transactionnelles. D'après notre expérience, toutes les données que vous lisez plus d'une fois, même si c'est quelque chose que vous lirez deux ou trois fois, nous vous recommandons de les mettre en cache. Parce que même si elles sont modifiées dans la base de données, et après cette modification, si vous lisez plus d'une fois (deux ou trois fois), il est tout à fait logique de mettre ces données en cache, de sorte que vous n'ayez pas à le faire. accédez à la base de données principale. Et 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 quelque chose que vous pouvez aussi, vous savez, toujours considérer.

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

  D'accord, généralement, le déploiement par défaut est celui que nous vous recommandons d'avoir NCache sur des cases séparées, puis votre candidature sur des cases séparées, n'est-ce pas ? De sorte que, quand NCache est basé sur le protocole TCP, il s'agit donc d'un appel réseau. Il existe une fonctionnalité appelée "Client-Cache", qui est un cache local placé sur les boîtiers d'application. Et, dans certains cas, si vous avez vraiment besoin de plus d'interprètes et que vous ne voulez pas vraiment avoir de latence causée par le réseau, cela peut également être fait "in-proc", ce qui signifie qu'il sera intégré à votre processus de candidature. Ainsi, lorsque cela se produit, le sous-ensemble des données est automatiquement placé dans le cache client. Cela permettra d’économiser toute communication de processus à processus. Et cela permettra également d’économiser toute communication réseau ou toute surcharge réseau. Nous avons donc une fonctionnalité ; c'est quelque chose que j'aborderai une fois que nous aurons abordé nos topologies. Je vais donc partager quelques détails supplémentaires, mais juste pour vous donner un aperçu rapide, voici comment fonctionne le cache client. C'est un cache qui se trouve sur le même boîtier où se trouvent vos applications. Et l’idée ici est que cela ne nécessite pas de déplacements fréquents sur le réseau si le cache client est activé. Et cela fonctionne sans aucune modification de code. Donc, j'espère que cela répond à la question. S'il vous plaît laissez-moi savoir s'il y a d'autres questions. Ouais, ça a l'air bien. Ron, enlève-le. Très bien.

• ASP.NET & ASP.NET Core Cache haute performance

  Le prochain cas d'utilisation de NCache est dans une application Web. S'il y a, vous savez, certaines exigences liées à la mise en cache des données utilisateur, n'est-ce pas ? Et généralement, il s'agit d'ASP.NET ou d'ASP..NET Core état de la session. Désormais, ces données n'appartiennent pas à la base de données, car ce sont des données transitoires. Il s'agit de données qu'un utilisateur va construire et qui restent dans le champ d'application tant que cet utilisateur est actif. Dans certains cas, vous pouvez les conserver dans la base de données pour un point de vue historique, mais dans la plupart des cas, les données appartiennent à un utilisateur.

  Donc, Microsoft ASP.NET ou ASP.NET Core session. Il existe peu d'options que vous pouvez utiliser sur le serveur d'état que vous pouvez utiliser dans le processus, vous pouvez utiliser un serveur de base de données, toutes ces options ont des problèmes. Par exemple, in-proc est un point de défaillance unique ; vous devez utiliser l'équilibrage de charge de session persistante. ASP.NET State Server est encore une fois un point de défaillance unique, et vous savez, il n'est pas évolutif. La base de données est une option, encore une fois, ce n'est pas un point de défaillance unique car vous pouvez la sauvegarder, mais dans certains cas, cela peut être un point de défaillance unique, mais elle est lente et non évolutive. Alors, que devrions-nous faire ici ? Encore une fois, pensez à utiliser NCache pour ASP.NET et ASP.NET Core mise en cache de l'état de la session. Cela fonctionne de telle manière que vous branchez notre fournisseur. C'est une option sans changement de code, mais dès que vous vous connectez NCache dans vos applications, NCache devient votre stockage de session principal. Et l’idée ici est que ce sera ultra-rapide car il est basé sur la RAM. C'est très évolutif car il existe plusieurs serveurs. Et, à l'intérieur NCache, une fois que nous aurons progressé dans la présentation et que j'aborderai les topologies, vous comprendrez que NCache dispose de sauvegardes, à l'aide de réplications. Et les données de session sont des données utilisateur, n'est-ce pas ? Ce sont donc des données que vous ne voudriez perdre dans aucune situation, car une fois que vous perdez ces données, cela a un impact sur l'utilisateur, cela a un impact sur l'entreprise. Ainsi, avec la réplication, les données sont également sauvegardées.

  

  Donc, si je dois énumérer les avantages dont vous bénéficiez, et vous savez, tout d’abord, vous allez améliorer les performances de votre application grâce à l’accès en mémoire. Vous disposez de plusieurs serveurs prenant en charge vos applications pour la mise en cache des sessions, c'est donc très évolutif. En plus de cela, il intègre des fonctionnalités de haute disponibilité et de fiabilité des données. Ainsi, il n'y a pas de perte de données de session ni de temps d'arrêt 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 de session persistante car NCache est une entité partagée. La demande peut être adressée à n'importe quel serveur Web ; il pourra toujours trouver des données de NCache basé sur notre protocole. Donc, tout cela sans aucun changement de code également.

  Un autre cas d'utilisation ici, vous pouvez également regrouper votre état d'affichage si vous utilisez des formulaires Web ASP.NET. C'est là qu'il mettra également en cache l'état d'affichage. L'état d'affichage devient lourd ; cela consomme beaucoup de bande passante. Il fait partie de vos paquets de requêtes et de réponses et est toujours renvoyé au navigateur. Et ce n'est jamais vraiment utilisé là-bas, mais c'est quelque chose qui est stocké sur le navigateur, du côté client. Et lorsque vous publiez, c'est là que l'état d'affichage est rétabli côté serveur. Donc avec NCache, nous vous permettons de mettre en cache l'état d'affichage côté serveur, afin que votre charge utile ne soit plus associée à un état d'affichage lourd. Cela améliore les performances. Bien que, vous le savez, l’état d’affichage soit quelque chose qui est toujours stocké du côté du navigateur. Mais si vous le conservez côté serveur, là où il est nécessaire, vous saurez améliorer le comportement global de l'application. Cela ne consommera plus votre bande passante car le paquet de requête et de réponse réel n'est plus associé à un état d'affichage important. Et nous allons également être très sécurisés car l'état d'affichage est stocké côté serveur, et vous pouvez ensuite configurer un cryptage et des fonctionnalités de sécurité par-dessus. Et c'est aussi une option sans changement de code. Mais cela ne s’applique qu’aux anciens formulaires Web. Je vous recommande donc, si vous disposez d'une application de formulaires Web ASP.NET, d'envisager également un état d'affichage de mise en cache.

  Et puis nous avons ASP.NET et ASP.NET core mise en cache des réponses. Ainsi, pour les pages statiques ou les parties de page statiques dans une page, vous devriez envisager de mettre en cache ces sorties de page. Et en ASP.NET core, nous proposons une option de mise en cache des réponses que vous pouvez choisir, et il s'agit également d'une option sans changement de code. En plus de cela, nous avons également ASP.NET et ASP.NET Core SignalR Backplane. Parce que dans un formulaire Web, si vous utilisez SignalR, vous avez absolument besoin d'un fond de panier. Et les fonds de panier typiques, tels qu'un système de fichiers ou une base de données, peuvent présenter tous ces problèmes d'évolutivité et de performances dont nous venons de parler. Avec NCache, sera ultra-rapide, très évolutif et fiable, car nous utilisons un système de messagerie très fiable en coulisses. Voici donc quelques-uns des cas d'utilisation que vous pouvez exploiter sur ASP.NET ou ASP.NET Core applications.

Avant de passer à Zack ; Je pense qu'il y a une question postée. Ouais. Donc, la question est venue de dire essentiellement et DB par défaut. Donc, au milieu de votre... je voulais attendre que vous l'ayez terminé, mais la question est essentiellement posée. Et au cas où, pourriez-vous développer la question, monsieur ?

Salut Ron, c'est NCache convient également à des fins de publication de données, avec l'exigence, où l'exigence est de sauvegarder les données en cache en mémoire avec des options pour synchroniser les données dans la base de données en tant que processus en arrière-plan ? Et peut NCache s'occuper de ce mécanisme de synchronisation entre le cache mémoire et les bases de données par défaut ?

Oui, c'est une très bonne question. Pour les cas avancés, cela peut toujours être une exigence. Cela fonctionne de deux manières. La première est que votre application utilise désormais des données provenant de NCache, mais les données existent dans la base de données. Ce sont donc deux sources différentes qui doivent être synchronisées pour la lecture ainsi que pour l’écriture. Maintenant, si l'application qui est 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 maintenant d'utiliser la lecture et l'écriture. Et oui, cela peut être fait de manière asynchrone ou synchronisée, selon vos besoins. Donc, ce qui se passera réellement, c'est que chaque fois que vous essaierez d'extraire des données de NCache et il n'existe pas dans le cache et vous souhaitez qu'il soit mis en cache, vous appellerez automatiquement la lecture, et cela lira à partir de la base de données principale en fonction de votre code. Et de même, si les données proviennent d'une base de données et, encore une fois, ces données doivent être mises à jour dans la base de données, dès que vous mettez à jour les données dans le cache, dans ce cas, vous utiliserez l'écriture directe. Désormais, l'écriture directe peut également être en é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 à l'aide de votre gestionnaire d'écriture directe. Et si vous souhaitez une invocation asynchrone de cela, dans ce cas, vous pouvez utiliser l'écriture différée, afin que cela puisse être fait en arrière-plan. Mais, NCache et votre application en est responsable, où NCache appelle votre code et votre application l'invoque.

Une autre situation pourrait être qu'il existe d'autres applications qui peuvent modifier directement les données dans la base de données et que votre application n'en est pas consciente. Donc, dans ce cas, ce qui se passera réellement, c'est que vous devrez utiliser nos fonctionnalités de synchronisation de bases de données. Vous devriez proposer une dépendance personnalisée ; vous savez, SQL Server a une notification en chaîne. Nous avons des dépendances de base de données. Il existe donc de nombreuses fonctionnalités de synchronisation grâce auxquelles tout changement dans la base de données est capturé par NCache automatiquement. Et vous pouvez à nouveau utiliser la lecture continue et recharger les données à l'intérieur NCache aussi. Donc, pour résumer, NCache peut, vous savez, gérer les deux situations : soit c'est votre application qui est la seule entité à changer 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 de la portée de l'application qui utilise la mise en cache.

Ainsi, les deux scénarios sont couverts, et NCache vous donnera une option de synchronisation de 100 que vous connaissez pour ces cas. Si vous parlez de cache mémoire, le cache mémoire est généralement également proposé par ASP.NET, n'est-ce pas ! Mais si vous faites référence NCache comme cache mémoire, j'ai donc déjà répondu à la question. Alors, s'il vous plaît, faites-moi savoir s'il y a d'autres questions, et nous pourrons partir de là.

• Messagerie Pub/Sub

  Ça a l'air bien. Je pense que nous pouvons avancer. Bien sûr. Très bien, je vais maintenant aborder la messagerie Pub-Sub. Comme vous pouvez le voir, NCache est déjà partagé entre les applications, n'est-ce pas. C'est donc une entité que vous pouvez utiliser pour vos besoins en données. Vous pouvez y ajouter des données ; vous pouvez en récupérer des données. Vous pouvez bénéficier d'avantages en termes de performances et d'évolutivité grâce à NCache. Vous pouvez étendre ce cas d'utilisation en utilisant NCache comme plate-forme de messagerie également. Donc, NCache la messagerie est très puissante à l'intérieur NCache. Il s'agit d'un mécanisme asynchrone piloté par les événements dans lequel plusieurs applications peuvent gérer entre elles les exigences de messagerie ou les exigences de coordination des applications. Si vous avez besoin de plusieurs applications pour communiquer entre elles, établir une communication est un défi. Donc, il faudrait s'appuyer sur quelque chose qui est une entité centralisée, NCache est cette entité. Et grâce à sa prise en charge de la messagerie, il est en mesure de vous offrir cette option permettant à une application d'ajouter des données ou des messages à votre ordinateur. NCache, et ces messages peuvent être propagés à tous les abonnés à l'autre bout du fil : les autres applications qui ont besoin, vous savez, de ces messages.

  

  De même, il pourrait également s’agir de messages basés sur des 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 basés sur les données, de sorte qu'ils couvrent les deux zones dans lesquelles les données sont renseignées. NCache et vous souhaitez que d'autres applications en soient conscientes, vous pouvez gérer les exigences de messagerie grâce à cela. Il peut également s'agir d'une messagerie personnalisée ou d'une messagerie pilotée par une application dans laquelle une application doit communiquer avec une autre application. Il est encore une fois basé sur un modèle évolutif en mémoire. Il propose également des options de réplication fiables, vous le savez. Il est basé sur une plate-forme de messagerie Pub-Sub conventionnelle où nous avons un concept de sujet et un concept de courtier de messages, où plusieurs applications y sont connectées. Ainsi, vous pouvez définir des applications d’éditeur et d’abonné. Les applications de l'éditeur publient, vous savez, des messages à NCache qui sont ensuite transmises à tous ces abonnés. Et puis, les abonnés peuvent également 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, celui de la recherche en texte intégral. Ainsi, si vous avez une application et que vous devez répondre à toutes les exigences de recherche en texte intégral depuis NCache, vous pouvez envisager d'utiliser nos fonctionnalités de recherche en texte intégral basées sur Lucine.NET.

  Vous savez, en général, l'API Lucene est autonome. C'est vrai, chez les gars, vous pouvez l'étendre sur plusieurs serveurs. NCache vous donne également la possibilité de charger des index dans la mémoire. Donc, NCache utiliserait des index basés sur disque, mais cela vous permet en fait, vous savez, d'étendre la capacité de stockage et de traitement des requêtes en y disposant de plusieurs serveurs. Ainsi, même s'il est basé sur disque, il sera toujours meilleur qu'une source unique sur la base de données. Parce que, dans les cas où vous avez une charge transactionnelle importante, chaque serveur sera responsable de son propre ensemble de requêtes d'index. Donc, ça va être très évolutif ; ça va être très fiable aussi. Puisqu'il s'agit d'un stockage assisté, lorsqu'il s'agit d'index de scènes, la persistance elle-même est une fonctionnalité avec un NCache. Toutes les données que vous stockez à l'intérieur NCache peut également être conservé sur le disque, ou, en fonction de certains fournisseurs de bases de données, il peut également être conservé sur certaines bases de données. Mais Lucene est la seule fonctionnalité où NCache utilise le disque par rapport à la RAM, car la nature du cas d'utilisation est telle qu'elle nécessite que les données soient persistantes.

  

J'espère que c'était simple. Voilà donc quelques-uns des cas d’utilisation. Encore une fois, dans ces cas d’utilisation, nous avons de nombreuses fonctionnalités ; tout type d'application, toute exigence spécifique au sein d'une application, peut être entièrement gérée à l'aide de nos fonctionnalités de mise en cache d'objets et de mise en cache de session.

Juste une petite question, Ron.
Existe-t-il un moyen pour moi d'accéder à mes données dans le cache comme je le fais dans ma base de données MySQL ? Je souhaite pouvoir exécuter des requêtes SQL sur mes données de cache. Puis-je faire cela?

Sûr. NCache tout d'abord prend en charge une recherche SQL et des requêtes LINQ. Donc, si vous avez la possibilité d'écrire une application qui peut simplement se connecter à NCache, puis exécutez des recherches basées sur des critères. C'est donc l'option la plus simple que vous pouvez utiliser pour rédiger une recherche basée sur des critères. Par exemple, vous pouvez sélectionner tous les produits pour lesquels prix du produit est supérieur à 10 et inférieur à 100. Vous pouvez également rechercher tous les produits en fonction d'une catégorie ; vous pouvez trouver des clients en fonction d'une région. Ainsi, vous pouvez proposer des recherches basées sur SQL ou des recherches basées sur LINQ, et NCache vous donnerait les données du cache. C'est donc une option.

L'autre option est que nous avons une intégration LINQ Pad. Donc, si vous souhaitez simplement visualiser des données sans, vous savez, avoir à passer par un développement d'application, LINQ Pad est un moyen simple d'exécuter des requêtes LINQ, puis de visualiser des données en exécutant des requêtes LINQ.

Et puis, dans notre prochaine version, la troisième option est de fournir un outil d'analyse de données. Nous allons donc vous proposer un moyen automatisé, un outil de surveillance, qui vous donnera la possibilité de surveiller vos données qui existent dans le cache. Et il vous donnera ces options de recherche basées sur des critères à partir d'une interface graphique, c'est donc quelque chose qui est en cours ; les exigences ont été remplies, le travail de développement est terminé. Je pense que cela fera partie de notre prochaine version.

J’attends vraiment tout ça avec impatience. Parfait. Ouais. Très bien. Je pense que tout va bien pour le moment, Ron. Je garderai également quelques-unes de ces questions pour la fin, car nous en avons quelques-unes intéressantes, mais oui, continuons. Bien sûr.

Cluster dynamique d'auto-guérison

Donc, je vais ensuite aborder le cluster de cache dynamique, vous savez, tous les détails à ce sujet. NCache est basé sur le protocole de clustering de cache basé sur TCP IP. Il s'agit de notre propre clustering de cache implémenté. Nous n'utilisons aucun clustering tiers ou Windows à cet effet. C'est un protocole 100% propriétaire. C'est écrit en .NET et .NET Core, donc vous savez que c'est très pratique en termes de --- les sockets TCP sont également .NET et .NET Core basé. Il s'agit d'une architecture 100 % peer-to-peer, il n'y a donc pas de point de défaillance unique. Vous pouvez ajouter ou supprimer des serveurs au moment de l'exécution. Vous n'êtes pas obligé d'arrêter le cache ou les applications clientes qui y sont connectées. Ainsi, de manière dynamique, vous pouvez apporter des modifications à un cluster de cache en cours d'exécution et, NCache ne vous posera aucun problème pour cela. Lorsque vous ajoutez un serveur, les clients sont avertis au moment de l'exécution, ils savent donc automatiquement que ce serveur ne fait plus partie du cluster de cache, ils commencent donc à utiliser le serveur supplémentaire, le cluster s'ajuste automatiquement. De même, une fois que vous supprimez un serveur, d’autres serveurs détectent que ce serveur a définitivement disparu. Ils avertissent les clients et ceux-ci cessent d'utiliser le serveur perdu. Il existe une prise en charge du basculement de connexion, qui est également construite du côté client, de sorte que tout serveur en panne garantira que, vous savez, le cluster veillera à ce que les clients en soient conscients et qu'ils basculent la connexion et commencent à utiliser le survivant. les serveurs.

Ainsi, dans tous les cas, toute modification apportée au cluster est propagée aux clients. Les clients sont intelligents, ils sont toujours au courant de l'état du cluster de cache. Ainsi, cela garantit qu’il n’y a pas de temps d’arrêt ou de perte de données, car nous avons également intégré la prise en charge de la réplication. Donc, NCache est hautement disponible et, en outre, il est très fiable grâce à la réplication. Il garantit une disponibilité à 100 % du côté de l'application, sans aucune interruption de l'application, vous pouvez continuer à l'utiliser. NCache.

Topologies de mise en cache

Ensuite, je parlerai des topologies de mise en cache. C'est la partie principale que je voulais couvrir. Nous avons le choix entre quatre options. La première option est encore une fois destinée aux configurations plus petites. Ceux-ci dictent la manière dont vous configurerez un cache.

Cache en miroir

Nous avons donc la possibilité de configurer un cache en utilisant une topologie de cache en miroir, et la façon dont cela fonctionne est que vous n'avez que deux serveurs au maximum. L'un de ces serveurs agirait comme un serveur actif, sur lequel tous les clients seraient connectés. L'autre serveur agirait comme un serveur passif, qui servirait de sauvegarde, et la sauvegarde serait effectuée par NCache. Cette topologie, une fois configurée, elle suit automatiquement l'architecture. Vous n'êtes pas obligé, en gros, vous savez, de définir si cela devient actif ou cela devient passif, cela se fait par NCache automatiquement. Mais, une fois que vous faites cela, ce qui se passera réellement, c'est que toutes les applications clientes se connecteront au serveur actif et c'est à partir de là qu'elles vont lire et écrire des données. Toutes les données dont nous disposons sur le serveur actif seront sauvegardées sur le serveur passif via une option de mise en miroir asynchrone. Ainsi, le client met à jour les retours actifs, de sorte que le coût de la réplication n'est pas encouru du côté de l'application client. L'application client sera ultra rapide. Dans les coulisses, NCache devrait mettre à jour la sauvegarde. Et la sauvegarde est là pour une raison importante : si le serveur tombe en panne, le serveur de sauvegarde est automatiquement mis à jour en tant que serveur actif et les clients basculent leurs connexions et commencent à utiliser le serveur nouvellement actif et précédemment sauvegardé. Et maintenant que le premier serveur revient, il rejoindra à nouveau en tant que nœud de sauvegarde, et non en tant que nœud actif, car nous en avons déjà un actif dans le cluster de cache. Et tout cela s’effectue de manière transparente dans vos applications. Vous n'avez aucune intervention à effectuer lorsqu'un serveur est ajouté ou qu'un serveur est perdu.

Cette topologie est très bonne pour les lectures comme pour les écritures. Donc, bon pour référence, bon pour les données transactionnelles, mais il y a un problème de capacité car vous n'avez que deux serveurs au maximum et, sur ces deux serveurs, un seul serveur est actif à un moment donné. Ainsi, pour les configurations plus petites, avec des données fiables, vous connaissez la mise en cache, cela pourrait être l’une des options.

Cache répliqué

Passons à autre chose, la deuxième option est un cache répliqué. C'est encore une fois pour les petites configurations. Cela fonctionne de telle manière que tous les serveurs sont actifs, comme vous pouvez le voir, le serveur 1 et le serveur 2 sont tous deux actifs. Les clients sont répartis entre différents serveurs, donc, si vous avez six clients comme indiqué dans le diagramme, certains d'entre eux se connecteront au serveur 2 et d'autres au serveur 2. Bon, ces trois-là sont connectés au serveur XNUMX et ceux-ci sont connectés à serveur XNUMX.

Cela se fait automatiquement ; l'équilibrage des connexions est quelque chose qui se construit à l'intérieur NCache. Tous les serveurs sont actifs mais chaque serveur dispose d'une copie du cache. Ainsi, quelles que soient les données que vous avez sur le serveur 1, une copie se trouve sur le serveur 2 et cette copie est conservée à l'aide de mises à jour de synchronisation. Ainsi, quelles que soient les mises à jour que vous effectuez sur un serveur, ces mises à jour doivent être appliquées sur d'autres serveurs lors d'un appel de synchronisation et, ce que nous entendons par là, c'est que le client va attendre que toute cette opération soit terminée. Si l'opération échoue sur un serveur, l'ensemble de l'opération est annulée. Et c’est ainsi que nous obtenons une copie synchronisée à 100 % sur tous les serveurs. Maintenant, c'est très bien en termes de fiabilité, mais, et aussi si vous avez un cas d'utilisation intensive en lecture, parce que vous avez plus de copies de données ou plus de copies provenant de différents serveurs, donc, à mesure que vous avez plus de serveurs, votre capacité de lecture augmentera parce que vous avez plus de serveurs pour répondre aux demandes. Mais comme vous venez de le remarquer, nous avons une mise à jour de synchronisation, toute opération d'écriture doit donc être appliquée sur tous les serveurs. C'est donc bon pour les configurations plus petites en termes de capacité d'écriture. Si vous disposez de trois ou quatre serveurs, vous devez appliquer la même opération trois ou quatre fois, ce qui peut avoir un impact négatif sur l'augmentation des performances. Cette topologie est donc davantage recommandée pour les scénarios de données de référence, pour les configurations plus petites. Il est évolutif pour les lectures, pas très évolutif pour les écritures, mais il est très fiable. Il apporte une haute disponibilité et une fiabilité des données, car si vous perdez un serveur, par exemple le serveur 1, il n'y a pas de perte de données ni de temps d'arrêt car ces applications basculeront et commenceront à choisir le serveur survivant et disposeront d'une copie du cache. Déjà disponible.

Cache partitionné et cache de réplique de partition

L'option suivante est que vous pouvez choisir, vous savez, vous pouvez configurer un cache à l'aide d'un cache partitionné. Désormais partitionné et la réplique de partition est la topologie la plus populaire, vous le savez. Le cache partitionné vous permet de répartir les données entre vos nœuds de serveur disponibles. Par exemple, si vous avez deux serveurs et que vous avez des données, la moitié des données iraient sur le serveur 1, l'autre moitié sur le serveur 2. La distribution des données fait également partie de NCache. Ce n'est pas quelque chose que font vos applications, cela est fait automatiquement par les applications au moment de l'exécution. Il existe une carte de distribution intelligente et un algorithme de hachage, qui dictent quelles données seront envoyées à quel serveur.

Ainsi, sur cette base, ce sont vos applications qui vont répartir les données de manière égale entre tous les serveurs du cluster de cache. Désormais, les données sont réparties uniformément, de sorte que la charge de vos requêtes sera également répartie uniformément. Ainsi, cela vous donnera plus de capacité de lecture et d’écriture en fonction du nombre de serveurs. Si vous avez deux serveurs, vous avez deux serveurs travaillant en équipe. Et, si vous passez de deux à trois, vous disposez de plus de serveurs gérant vos demandes de lecture et d’écriture. Ainsi, vous bénéficiez d’une plus grande évolutivité pour les lectures et les écritures. Ainsi, de manière évolutive linéaire, vous obtenez plus d’évolutivité si vous ajoutez plus de serveurs. En ajoutant plus de serveurs, vous regroupez également les ressources de mémoire, car les données sont distribuées, vous regroupez donc le stockage de tous les serveurs. Ainsi, si vous disposez de deux serveurs, vous disposez d’une capacité de deux serveurs. Si vous ajoutez un troisième ou un quatrième serveur, vous augmentez votre capacité de, vous savez, ces nombreux serveurs. Ainsi, la capacité globale est regroupée, de sorte que vous obtenez une croissance linéaire à mesure que vous ajoutez davantage de serveurs dans le cluster de cache.

Très bon pour les lectures, très bon pour les écritures, très évolutif pour référence ainsi que pour les données transactionnelles. Le seul inconvénient de cette topologie est qu’elle ne dispose d’aucune sauvegarde. Si vous perdez un serveur, vous perdez cette partition. Ainsi, lorsque cela se produit, vous devez disposer d’un moyen de construire ces données à partir d’une base de données principale. Ainsi, si votre objectif principal est d'atteindre des performances élevées, s'il s'agit d'une application centrée sur les performances, et que vous pouvez vous permettre de revenir à une base de données, ce qui est généralement le cas, vous ne comptez pas sur 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 vous le savez, les exigences de fiabilité des données doivent également être satisfaites à partir de NCache, j'ai une meilleure topologie, appelée Partition of Replica cache. Désormais, l'architecture globale est exactement comme partitionnée avec une amélioration des répliques, où chaque serveur a une partition de données, mais chaque serveur conserve 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 2, le serveur 2 est actif, sa sauvegarde est sur 1. Et vous avez la possibilité de choisir des options de sauvegarde synchronisées ou asynchrones. Si vous choisissez la partition de la réplique avec asynchrone, le client mettra à jour la partition active et renverra les opérations terminées sur le client, puis, NCache mettra à jour la partition de sauvegarde dans les coulisses. Si vous choisissez la synchronisation, l'application client mettra à jour l'actif et la sauvegarde en tant qu'opération transactionnelle. Quoi qu’il en soit, vous savez, la synchronisation est évidemment plus fiable, l’async est plus rapide. Mais de toute façon, NCache est capable de gérer, vous savez, la fiabilité des données de telle manière que si un serveur tombe en panne, la topologie de sauvegarde s'active et vous ne constatez aucune perte de données ni aucun temps d'arrêt des applications. Droite.

Alors laissez-moi vous montrer rapidement cette topologie avec 3 serveurs. Ainsi, nous bénéficions de tous les avantages de hautes performances pour les lectures, de hautes performances pour les écritures, vous savez, d'une évolutivité linéaire pour les lectures ainsi que pour les écritures. En plus de cela, nous bénéficions d’avantages en matière d’évolutivité, de haute disponibilité et de fiabilité des données. Si un serveur tombe en panne, il n'y aura pas de perte de données ni de temps d'arrêt des applications.

Démo

J'espère que c'est clair. Permettez-moi maintenant de vous présenter notre environnement de démonstration et laissez-moi vous montrer rapidement comment vous pouvez construire ces topologies de mise en cache, puis je vous montrerai également comment tester rapidement un cluster de cache. Mais en attendant, n'hésitez pas à me faire savoir si vous avez des questions. Eh bien, juste un petit rappel que tout ce que nous montrons, nous pouvons également le faire avec vous avec des sessions de prise en main et des sessions de support technique dans vos environnements, pour vos cas d'utilisation spécifiques. Donc, tout ce dont nous discutons ici, même après le webinaire, nous serions heureux, en tant qu'équipe, de pouvoir également nous réunir avec vous à ce sujet, afin de pouvoir démontrer comment cela fonctionnerait pour vous.

En ce qui concerne les questions, j'en ai une qui est arrivée juste à la fin. L’un d’eux est l’un de vos favoris.
Il y a eu de nombreuses discussions concernant l'utilisation de Hazelcast pour la mise en cache des applications. Qu'est-ce que NCache à condition que Hazelcast ne le fasse pas ?

D'accord. 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. Ce qu'il y a de bien avec NCache c'est qu'il fonctionne sur .NET, ainsi que, vous savez, sur Windows, ainsi que sur Linux. Ainsi, la plate-forme et la compatibilité prennent en charge cela NCache offres, aucun autre produit n'est capable d'atteindre cela. C'est donc le premier élément, où c'est le choix le plus privilégié si vous êtes, vous savez, réfléchi à la plate-forme que vous envisagez d'utiliser. L'autre différence est que, et j'encourage tout le monde à consulter, vous savez, notre pages de comparaison, vous y trouverez également du très bon matériel. Mais pour résumer rapidement, NCache La prise en charge de la mise en cache d'objets possède de nombreuses fonctionnalités qui manquent complètement aux autres produits. Par exemple, pour la recherche SQL, nous avons un ensemble élaboré de fonctionnalités disponibles à l'intérieur NCache. Nous avons un chargeur de cache et un rafraîchisseur de cache. Ce sont des fonctionnalités totalement uniques à NCache. Notre gestionnaire de lecture et d'écriture capable d'exécuter .NET et .NET Core code côté serveur, c'est quelque chose qui est une fonctionnalité absolument unique pour NCache, et la liste est longue, n'est-ce pas. Ainsi, certaines des fonctionnalités que, vous savez, vous pouvez personnaliser côté serveur. Ceux-ci ne sont disponibles que dans NCache et puis, du point de vue des applications, de nombreuses fonctionnalités manquent dans d’autres produits. J’encourage donc tout le monde à consulter notre page de comparaisons. Certaines comparaisons, fonctionnalité par fonctionnalité, sont publiées, et cela vous donnera des informations plus détaillées à ce sujet.

C'est définitivement notre question 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. Ouais, je pense que nous sommes prêts à partir. Continuez s'il vous plaît. Bien sûr.

Créer un nouveau cache en cluster

Alors, permettez-moi de faire une démonstration rapide du produit en créant un nouveau cache cluster. Appelons-le cache de test. Bien, laissez-moi déplacer ce point ici, soyez patient avec moi. D'accord.

Nous venons donc d’expliquer quatre topologies de mise en cache. Je vais utiliser le cache Partition of Replica, car c'est le cache le plus recommandé avec l'option de réplication asynchrone. Je conserverai tous ces paramètres par défaut.

Continuez et je vais vous montrer à quel point il est facile de configurer un cache à l'aide d'outils GUI. Il s'agit de notre gestionnaire Web, mais vous pouvez également tout réaliser en utilisant nos applets de commande PowerShell, et vous pouvez également automatiser ce déploiement, si cela est nécessaire. Je vais ajouter le serveur un, où NCache est installé. Je vais ensuite ajouter le serveur 2. Du coup, mes 2 boites avec NCache avec une taille de 2 Go va être, vous savez, mis en place. Donc, mon idée ici est que je vais créer un cluster de cache à 2 nœuds en utilisant 2 Go de taille de cache sur chacun. Donc, un total de quatre concerts avec 2 serveurs où NCache est déjà installé. Et puis, j'utiliserai ma box pour me connecter à ce cluster de cache.

Paramètres TCP. c'est le port que vous devez configurer, une fois que vous avez fait cela. Conservez-le par défaut ou spécifiez n'importe quel port sur lequel le pare-feu n'a pas, vous savez, d'impact sur ce port.

Si vous devez configurer le cryptage et la compression, voici l'écran. Je vais le garder tel quel. Choisissez ensuite. Expulsions, si votre cache est pleine, c'est quelque chose que vous pouvez choisir. Une option est que votre cache ne procédera tout simplement à aucune opération d’écriture. Cela vous donnera une erreur, « le cache est plein ». Une autre option consiste à configurer l'expulsion et, sur la base de ces algorithmes, cela supprimera certains éléments du cache au moment de l'exécution. Ainsi, en fonction de la priorité et de l'utilisation, les éléments les moins récemment ou fréquemment utilisés peuvent être supprimés, et cinq pour cent des éléments seront supprimés du cache. Je démarrerai ce cache à la fin et au démarrage automatique, de sorte qu'à chaque redémarrage de mon serveur ou NCache le serveur redémarre, il est capable de redémarrer les caches qui sont arrêtés.

Je choisirai terminer, et c'est tout. C'est dire à quel point il est simple de configurer un cluster de cache. Et dans quelques instants, il me montrera une autre vue, où ce cache sera démarré, puis je vous montrerai quelques détails de surveillance et de gestion à partir de là. Nous avons des vidéos plus détaillées disponibles sur les configurations de cache, donc si vous avez des questions, faites-le-moi savoir maintenant, ou nous pouvons également, vous savez, nous fier à ces vidéos.

Je peux sélectionner et choisir le cluster de surveillance, ce qui ouvrira un autre tableau de bord, qui me permettra de surveiller entièrement mon cache. Il me montre un cluster de cache entièrement connecté, des compteurs de débit de requêtes, des compteurs de latence, puis des ajouts, des récupérations, des compteurs de mise à jour, sont également présents. De même, il me montre l'utilisation du processeur et de la mémoire ainsi que les situations de cache plein.

J'ai également des tableaux de bord pour le client, ainsi qu'une vue de rapport, où nous voyons des tableaux de bord côté serveur et côté client. Pour le moment, aucune application n'y est connectée, mais il existe un moyen de simuler une charge à l'aide de ce bouton de test de contrainte. Ainsi, je peux démarrer une charge factice ou une activité sur mon cluster de cache en appelant ce test-stress. Dès que je ferai cela, vous verrez qu'un client est connecté et cette topologie nécessite que mes données soient distribuées, n'est-ce pas. Ainsi, certaines données iraient sur le serveur 1 et d'autres sur le 2. Ainsi, ce client utilise uniformément les deux serveurs. Comme vous pouvez le constater, les requêtes arrivent sur les deux serveurs, la taille du cache augmente sur les deux serveurs.

Nous avons également des partitions actives et de sauvegarde affichées sur les deux serveurs. Et si je vous montre rapidement les compteurs de latence, c'est une latence inférieure à la milliseconde, voire à la microseconde, en ce qui concerne mes opérations. Et je peux voir le tableau de bord client affichant ces statistiques côté client et, de la même manière, nous avons un rapport qui affiche les statistiques côté serveur.

Ron, j'ai une question, en fait, nous avons reçu quelques questions, donc l'une d'elles est :
Quelle est votre recommandation d’expulsion ? Et, si l'expulsion est au moins, attendez la suivante, si l'expulsion est désactivée, pouvons-nous augmenter la taille du cache ou la diminuer ?

Bien sûr. Donc, vous savez, l'expulsion est quelque chose qui doit être configuré en fonction de votre cas d'utilisation, n'est-ce pas. Si les données sont quelque chose que vous pouvez vous permettre d’expulser, c’est vrai. L'expulsion elle-même supprimera certaines données si votre cache est plein. La situation idéale est que vous n’ayez jamais à faire cela et que votre cache respecte largement sa capacité, n’est-ce pas. Ainsi, vous donnez suffisamment de taille ou suffisamment de mémoire à votre cache pour qu’il ne soit jamais plein. Mais dans les cas où c’est le cas, vous savez, cela arrive à un point où il devient plein. Dans ce cas, si vos données sont quelque chose que vous pouvez toujours reconstruire à partir d’une base de données principale, il est recommandé d’activer les expulsions. Par exemple, pour les sessions ASP.NET, nous ne recommandons pas d'activer les expulsions, car vous supprimeriez certains utilisateurs pour faire de la place aux nouveaux utilisateurs, et tous les utilisateurs disposent de leurs données importantes, n'est-ce pas. Ce sont donc des données que vous ne voudriez pas perdre dans un scénario donné. Ainsi, pour ces scénarios, nous vous recommandons d’augmenter la taille de votre cache. Planifiez la taille de votre cache de manière à ce qu'elle soit suffisamment grande et au cas où elle serait pleine NCache vous permet de modifier la taille du cache au moment de l'exécution. Vous pouvez modifier cela, n'est-ce pas, et sur cette base, vous pouvez augmenter puis enregistrer ces paramètres sur un cache en cours d'exécution. Il est donc applicable à chaud et augmentera la taille du cache au moment de l’exécution.

D'autres questions? On dirait que cela a répondu, et j'en garderai quelques-uns pour la fin, afin que vous puissiez terminer votre démonstration. Bien sûr. Donc, pour revenir à mon environnement de démonstration, vous savez, vous pouvez ajouter des clients, par exemple, je peux ajouter ma box en tant que client et voici un aperçu rapide d'un exemple d'application que je peux exécuter à partir de ma box. Par exemple, ceci est également disponible sur GitHub, donc si vous recherchez NCache sur GitHub, vous verriez quelques échantillons, et j'en ai extrait un. Donc, ce que vous devez vraiment faire dans votre application est d’inclure ce package NuGet qui est Alachisoft.NCache.SDK, et si cela vous intéresse mise en cache des données de l'application, c'est l'échantillon que vous devriez considérer. Et, sur cette base, une fois cela ajouté, vous pouvez inclure certaines ressources dans l’application.

Cela inclura déjà certaines, vous savez, des bibliothèques de NCache, dans le cadre de ce nouveau package NuGet. Et puis vous incluez cette référence en utilisant Alachisoft.NCache.Client. Ajoutez également Runtime.Caching, c'est vrai, et sur cette base, vous pouvez définir un handle de cache et, à l'intérieur de celui-ci, nous avons un tas de méthodes. Par exemple, laissez-moi vous montrer comment initialiser le cache. Entrons réellement à l'intérieur de cela. Supportez-moi. J'ai du mal. Quoi qu'il en soit, pour une raison quelconque, je ne parviens pas à entrer dans cette boîte, 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 à partir de notre PowerPoint. Cet exemple utilise en fait cela, je ne suis pas en mesure de le démontrer car je ne suis pas en mesure d'entrer dans le code. Cela 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. Ensuite tu peux appeler cache.Obtenir pour obtenir réellement des 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 comme dans upsert où il ajoute et 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 et vous pouvez le télécharger et l'exécuter sur votre cache. Tout ce que vous avez à faire est de pointer vers le cache depuis une application. Il existe un tas de configurations. Vous pouvez spécifier le nom du cache et l'adresse IP en ligne, ou vous pouvez vous appuyer sur un client.ncconf, que ce package NuGet inclut dans le projet. Donc, si je vous montre rapidement quelques ressources, vous voyez, beaucoup de fichiers sont effectivement ajoutés, et ce fichier ici est un fichier qui permet de se connecter au cache. Donc, il est déjà capable de se connecter à mon « démocache ». Si je l'exécute, il effectuera une activité sur mon cache et lancera les opérations de mise en cache.

De même, 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, droite. Je vous recommande donc d'utiliser cet exemple ici. C'est pour la recherche SQL. Il est à nouveau téléchargé depuis GitHub, et encore une fois, il utilise la recherche, il contient un exemple de données, puis sa recherche d'appel à l'aide de SQL. Et il a de nombreuses fonctionnalités ici, encore une fois dans le même esprit, les échantillons sont assez intuitifs. Vous pouvez insérer des éléments, puis interroger à l'aide de balises de nom, vous pouvez interroger, vous savez, interroger à l'aide d'index ou de projections définis.

Malheureusement, je ne peux pas aborder ces méthodes en raison des problèmes environnementaux, mais encore une fois, celles-ci serviraient de point de référence pour l'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 sur Cache Client, cette topologie est donc également une option sans changement de code. Toutes les données que vous cachez à partir d'une base de données à l'intérieur NCache, vous pouvez le mettre en cache davantage en utilisant le cache client. C'est un cache au-dessus d'un autre cache. Fonctionne sans aucune modification de code. Il s'agit d'un cache synchronisé avec un cache clusterisé, il n'y a donc aucun problème de cohérence des données. La synchronisation se fait par NCache. Toutes les mises à jour effectuées sur un cache client sont propagées au cache cluster, puis propagées aux autres caches clients, et dans le cache gère toute la synchronisation. Pour les scénarios de données de référence, dans lesquels vous n’avez pas beaucoup d’écritures, il s’agit d’une option très recommandée.

Réplication WAN

De même, le NCache a aussi un Réplication WAN. Nous avons des topologies actif-passif et actif-actif. Ainsi, l’intégralité de vos données de cache peut être répliquée d’un centre de données à l’autre via notre cache pont. Le pont lui-même est sauvegardé sur un serveur passif actif, vous disposez donc 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 des scénarios de reprise après sinistre ou pour la migration d'est en ouest, vous savez, ou pour les situations où vous avez besoin de données d'une application et que vous devez les utiliser avec l'application cible. Ainsi, vous pouvez transférer l’intégralité des données du cache d’un centre de données à un autre.

L'autre option est active-active. En cela, nous avons les deux sites actifs, donc le site un transfère les données vers le site deux et le site deux transfère les données vers le site un. Encore une fois, c'est une option sans changement de code. C'est juste une configuration. Une fois le pont configuré, vous connectez deux caches ensemble et NCache prend le relais et démarre la réplication des données entre ces caches.

Et cela s'étend également à la topologie multi-active-active, donc il n'est pas nécessaire qu'il y ait seulement deux sites, il peut s'agir de trois, quatre ou cinq sites où tous les sites transfèrent des données entre eux. Donc, NCacheLa capacité de Google, vous savez, à synchroniser les données de tous les sites en même temps. Et, soit dit en passant, cela se fait de manière asynchrone, de sorte que le coût de la réplication n'est plus, vous savez, supporté du côté de l'application ou du côté de l'utilisateur. C'est fait sur l'application. Vous avez des applications client connectées ici ainsi qu'ici. Ils ne constatent aucune dégradation des performances en raison de cette réplication WAN. Cela se fait en coulisses par NCache. Faites-moi savoir s'il y a des questions. Concluons la présentation et les fonctionnalités définies à ce stade. Zack, fais-moi savoir s'il y a des questions.

Oui, nous en avons quelques-uns. Et tout le monde, vous savez, j'apprécie votre patience, c'est donc aussi le bon moment pour poser d'autres questions si vous vous êtes posé la question tout au long de la présentation. Alors, commençons par un.
Comment confirmer si votre cache fonctionne dans un état sain ? Recevons-nous des notifications, etc. ? Comment savoir s'il y a un problème ?

Sûr. Nous avons outils de suivi et de gestion. Ainsi, une chose pourrait être que vous inspectiez visuellement et que vous voyiez l’état du cluster. Vous voyez, l'utilisation du processeur, l'utilisation de la RAM. Si vous connaissez votre base de référence, combien, vous savez, combien de requêtes vos applications génèrent et quelle est l'utilisation typique de NCache à partir de ces compteurs, vous pouvez inspecter visuellement à l'aide de nos tableaux de bord de suivi et de gestion. Et puis, nous avons des alertes pour n'importe quelle situation, par exemple, vous démarrez un cache, arrêtez un cache, un nœud rejoint, quitte, la taille du cache devient pleine ou le cluster passe dans un état malsain, comme un cerveau divisé, nous avons des alertes, auquel nous nous connectons dans les journaux d'événements Windows. Et puis, vous pouvez également configurer des alertes par e-mail depuis NCache, et il peut également vous envoyer un e-mail. Il s'agira donc d'une surveillance proactive, d'alertes provenant de NCache, Où NCache serait alerté et vous pouvez prendre des mesures en fonction de cela. Et puis nous avons des données historiques capturées sous la forme de journaux de compteurs de performances, ainsi que de journaux de cache. Pour les situations où vous ne saviez pas ce qui n'allait pas et où vous avez constaté des problèmes avec NCache, nous pouvons venir nous impliquer et nous pouvons examiner NCache journaux et évaluez l’état du cache dans ce cas. Donc, beaucoup d’entre vous connaissent des pistes à cet égard que nous pouvons explorer.

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

D'accord. En règle générale, nous avons tendance à être au courant des dernières .NET framework version, .NET Core. .NET 6 est actuellement pris en charge, c'est une condition préalable pour NCache. Vous devez avoir .NET 6 comme élément obligatoire sur NCache les serveurs. Mais vos candidatures peuvent être sur n'importe quel, vous savez, .NET framework, je pense qu'à partir de 3.5, 4.0, 4.5, voire 4.7, 4.8. Vos applications peuvent être sur n'importe quel serveur .NET ou .NET Core cadre. Ce n'est qu'une limitation côté serveur. Et, dès qu'une compatibilité de framework plus récente, vous savez, est testée, par exemple pour .NET 7, nous la testons déjà dans notre laboratoire d'assurance qualité. Donc, une fois que nous aurons, vous savez, signé, nous publierons également, vous savez, un support officiel pour cela.

Merveilleux. Une autre question est :
Selon vous, quelle est la quantité sûre de caches en cluster entre mes serveurs de cache ? Puis-je créer, disons, 15 caches en cluster entre mes serveurs de cache ?

D'accord. Tout d'abord, NCache n'impose aucune limite sur le nombre de caches que vous pouvez configurer. En fait, si vous regardez mon environnement de démonstration, j'ai deux caches configurés. Ainsi, vous pouvez en créer autant que nécessaire. Mais il existe une recommandation technique ou une recommandation liée à la capacité que nous recommandons généralement dans un environnement de production de ne pas dépasser quatre à cinq caches. Parce que chaque cache est un cluster de cache distinct. Cela va en fait consommer toutes les ressources pour le stockage, pour le clustering, pour la communication, il y a également une surcharge de gestion du cluster. Ainsi, à mesure que vous augmentez le nombre de caches, vous introduisez en fait un problème de capacité sur cet environnement ou au sein de cet environnement. Nous vous recommandons donc de le conserver, vous savez, entre quatre et cinq heures, si possible. Dans une situation où vous devez disposer de plusieurs caches, vous pouvez l'étendre jusqu'à 10. Mais, comme je l'ai dit, c'est encore une fois une recommandation. Il n’y a pas de limite réelle qui impose cela. Il s’agit d’une recommandation générale de notre part.

D'accord. Permettez-moi d'en ajouter une de plus puisque, je sais que nous sommes à la fin de la session et, je sais que les gens ont d'autres choses sur le docker.
Pouvez NCache fournir une réplication DR ?

Oui. La fonctionnalité de réplication WAN dont je viens de parler, la dernière topologie, qui couvre la reprise après sinistre, la reprise après sinistre. Les sites peuvent être transmis avec les données du site actif, vous disposerez donc d'un site DR entièrement sauvegardé. Il vous suffit de faire un switch côté application. Étant donné que toutes les données sont déjà sauvegardées, il n'y a aucune perte de données dans la situation où un centre de données tombe complètement en panne ou si vous devez le mettre hors service vous-même pour la maintenance.

D'accord. Je pense que nous en avons réussi autant que possible. Mesdames et messieurs, sachez que nous sommes également disponibles en dehors de ces séances. Nous sommes très heureux de travailler avec vous, côte à côte, lorsqu'il s'agit d'examiner vos configurations existantes, si vous êtes déjà un utilisateur de NCache. Si vous êtes nouveau sur NCache, nous serions heureux de vous proposer un essai et de vous organiser des séances de soutien pour vous expliquer comment cela fonctionnerait dans vos applications intégrées, mais surtout, sachez que vous pouvez nous contacter à tout moment lorsqu'il s'agit de toute question concernant NCache, ou même en utilisant le produit et si vous avez besoin d'aide. Nous avons beaucoup de nouveautés à venir, de nouvelles versions également, alors, vous savez, restez à l'écoute et nous aurons bientôt d'autres webinaires de ce type.

Une salve d'applaudissements pour Ron. J'apprécie vraiment, vous savez, que vous ayez pris le temps de participer à une séance aujourd'hui et j'attends avec impatience notre prochaine. Merci tout le monde. Merci, Zack. Bien sûr. Très bien, tout le monde. Passez tous une merveilleuse journée et nous avons hâte de vous voir lors de notre prochain webinaire. Et juste un avertissement, une fois ce webinaire terminé, nous aurons un enregistrement du webinaire téléchargé sur notre site Web, une fois que tout sera fait et dépoussiéré. Donc, si vous n'avez pas eu l'occasion, vous savez, d'obtenir des réponses à vos questions, si vous souhaitez revenir sur l'un des points que nous avons soulevés, n'hésitez pas à revenir sur notre site Web et à consulter le webinaire enregistré.

Très bien alors. Salut à tous. Vous en avez un bon. Merci les gars. Bye Bye.

Que faire ensuite?

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