DDD 2017 London

Mise à l'échelle des applications .NET avec la mise en cache distribuée

Par Iqbal Khan
Président et évangéliste de la technologie

Si vous augmentez le volume de transactions de données, le volume de sessions ou la taille des objets, cette conférence est pour vous. Découvrez comment améliorer les performances des applications à l'aide d'un cache distribué entre vos applications et votre base de données. Cette conversation porte sur :

• Aperçu rapide des goulots d'étranglement d'évolutivité dans les applications .NET
• Description de la mise en cache distribuée et comment elle résout les problèmes de performances
• Où pouvez-vous utiliser la mise en cache distribuée dans vos applications
• Quelques fonctionnalités importantes dans un cache distribué
• Exemples pratiques utilisant un cache distribué

Vue d’ensemble

Bonjour à tous, je m'appelle Iqbal Khan. Je suis un évangéliste de la technologie à Alachisoft. Nous sommes les fabricants de NCache. Combien de personnes ont entendu parler de NCache avant que? Bon, bon numéro. Le sujet d'aujourd'hui est la mise à l'échelle des applications .NET avec la mise en cache distribuée. Il ne s'agit pas NCache, il s'agit globalement du problème d'évolutivité auquel les applications .NET sont confrontées et de la manière de résoudre ce problème.

Je préfère une discussion plus interactive. Donc, au lieu d'attendre la fin pour poser des questions, veuillez lever la main si vous avez une question pendant que je parle. Je vais passer par une combinaison de code architectural puis réel et je vais aussi vous montrer NCache comme exemple de ce à quoi ressemble une cache.

Qu'est-ce que l'évolutivité?

Alors, éliminons quelques définitions. Je suis sûr que la plupart d'entre vous le savent déjà, mais qu'est-ce que l'évolutivité ? L'évolutivité n'est pas la performance des applications. Il s'agit de performances d'application sous des charges de pointe. Ainsi, si vous avez une application qui fonctionne très rapidement avec 5 utilisateurs, elle n'est pas nécessairement évolutive à moins qu'elle ne fonctionne très rapidement avec 5,000 50,000, 500,000 5 ou XNUMX XNUMX utilisateurs. Bien sûr, si votre application ne fonctionne pas rapidement avec XNUMX utilisateurs, vous avez d'autres problèmes que l'évolutivité.

Évolutivité linéaire vs évolutivité non linéaire

L'évolutivité linéaire est davantage une architecture de déploiement. Votre application est-elle conçue de manière à pouvoir continuer à ajouter plus de serveurs dans un environnement à charge équilibrée, puis à mesure que vous ajoutez plus de serveurs, vous augmentez la capacité de transaction. Au fait, lorsque j'utilise le mot évolutivité, je veux dire l'évolutivité des transactions et non les données de l'évolutivité. Nous ne parlons pas d'énormes quantités de données. Nous ne parlons pas de téraoctets ou de pétaoctets de données. On parle de beaucoup d'activités. Ainsi, si votre application est conçue de manière à pouvoir ajouter plus de serveurs et que, à mesure que vous ajoutez plus de serveurs, votre capacité augmente de manière linéaire, vous êtes évolutif de manière linéaire.

Sinon, alors vous avez plus une courbe logarithmique, pour ceux d'entre vous qui se souviennent encore de leur calcul de l'université et le problème avec cette courbe est que vous verrez une augmentation, mais après un certain point, ajouter plus de serveurs n'a en fait aucun avantage, fait chuter les performances car il y a des goulots d'étranglement dans votre application qui ne disparaissent pas. Donc, vous ne voulez certainement pas être non linéaire.

Quelles applications ont besoin d'évolutivité ?

Alors, quelles applications ont besoin d'évolutivité ? Ce sont généralement des applications serveur bien sûr. Applications Web, ASP.NET, maintenant ASP.NET Core aussi. Services Web. Encore une fois, vous pouvez le faire via WCF. Vous pouvez le faire API Web ASP.NET ou ASP.NET Core API Web. Et, c'est-à-dire que les services Web sont généralement le backend de l'Internet des objets, qui est un espace en émergence assez rapide de nos jours.

Ce sont aussi des applications de traitement de données volumineuses. Donc, si vous avez beaucoup de données, c'est là que la partie données de l'évolutivité vient, mais même là, il ne s'agit pas des données, mais de la vitesse à laquelle vous pouvez les traiter. Donc, si vous avez une application de traitement de données volumineuses, elle doit évoluer. La plupart des applications de traitement de données volumineuses ne sont généralement pas en .NET. Ils sont plus du côté Java et je me concentre davantage sur l'application .NET. Mais, d'un point de vue conceptuel, les applications de traitement de données volumineuses nécessitent également une évolutivité.

Et, enfin, toutes les autres applications serveur. Vous pouvez être une institution financière, vous pouvez être une grande banque, vous avez des millions de clients, ils appellent, changent d'adresse, émettent une nouvelle carte, ou quoi que ce soit et vous devez traiter, peut-être qu'ils veulent transférer des fonds et vous devez traiter toutes ces demandes dans un certain délai à des fins de conformité. Donc, vous avez beaucoup de ces processus par lots back-end en cours et ils doivent traiter de plus en plus de transactions dans ce très petit laps de temps, petit en termes de quelques heures que vous obtenez chaque nuit. Donc, n'importe quelle application serveur. Donc, si vous avez l'une de ces applications et qu'elles ont besoin d'évolutivité, vous êtes au bon endroit, aujourd'hui.

Le problème de l'évolutivité

Alors, quel est le problème d'évolutivité ? Eh bien, le niveau d'application n'est pas le problème. Dans la plupart de ces applications que j'ai mentionnées, le niveau d'application semble parfaitement fonctionner. Vous pouvez ajouter plus de serveurs. Vous avez généralement un environnement à charge équilibrée. Si vous avez, disons, une application ASP.NET, vous aurez un équilibreur de charge en haut et vous aurez un groupe de serveurs auxquels l'équilibreur de charge envoie le trafic et que vous avez besoin de plus de trafic, comme vous devez gérer plus d'utilisateurs, vous ajoutez simplement plus de serveurs. Donc, c'est très simple.

Mais le problème est que votre base de données, qu'il s'agisse de données relationnelles ou de données mainframe, devient le goulot d'étranglement. Et, relationnel ne signifie pas une base de données spécifique. Cela pourrait être un serveur SQL, cela pourrait être Oracle, MySQL, Db2, n'importe lequel d'entre eux. Toutes les bases de données relationnelles ont cette faiblesse inhérente qu'elles ne peuvent pas mettre à l'échelle. Alors, c'est exactement pourquoi NoSQL mouvement a commencé et en fait nous avons même un produit sur l'espace .NET appelé NosDB qui est une source ouverte NoSQL database mais le NoSQL databases ne sont pas toujours la réponse. Je veux dire qu'ils résolvent définitivement le problème d'évolutivité. Techniquement parlant, si vous utilisez un NoSQL database vous n'aurez pas de goulots d'étranglement d'évolutivité. Mais le problème est que, pour une combinaison de raisons techniques et commerciales, vous ne pouvez pas déplacer toutes vos données en dehors du mainframe relationnel ou hérité vers NoSQL.

Ainsi, le NoSQL est plus une partie de ce que nous appelons les nouvelles données, vous savez. Les données commerciales traditionnelles résident toujours dans des bases de données relationnelles pour diverses raisons. Donc, cela signifie que vous devez résoudre ce problème tout en vivant avec des bases de données relationnelles. Vous ne pouvez pas dire que je vais simplement supprimer la base de données relationnelle de ma photo. En fait, même aucun de nos clients ne déménage complètement dans un NoSQL. Ils déplacent certaines des données dans NoSQL. Même les plus gros joueurs comme MongoDB, ils ont la même histoire que les gens qui déménagent NoSQL database déplacer certaines données vers NoSQL et ils conservent toujours les données traditionnelles dans la base de données relationnelle.

Déploiement de cache distribué (NCache)

Donc, vous devez résoudre le problème avec les bases de données relationnelles dans l'image et c'est là qu'un cache distribué entre en jeu. En fait, cela vous donne souvent le même avantage NoSQL database. C'est en fait, si vous y réfléchissez, c'est un NoSQL magasin de valeur de clé en mémoire. Donc, vous savez, si vous avez examiné NoSQL databases, il y a la base de données de documents JSON, il y a le magasin de valeurs clés et il y a la base de données de graphes et il y a les autres types. Donc, le magasin de valeur de clé, si c'est un ... La seule chose qu'un cache distribué est qu'il ne fait pas de persistance, tout est en mémoire. C'est le magasin de valeur clé. Et, il est distribué sur plusieurs serveurs, il vous offre donc le même avantage, il évolue car vous pouvez ajouter plus de serveurs. Alors, considérez cela comme le niveau d'application ici. Ici se trouve le niveau d'application, puis généralement un équilibreur de charge ici quelque part. Et, à mesure que vous ajoutez plus de serveurs dans ce niveau, la base de données va devenir de plus en plus sollicitée, à moins que vous ne mettiez un niveau de mise en cache entre les deux.

Le niveau de mise en cache évolue tout comme le niveau d'application. Il n'y a pas de goulots d'étranglement, car vous continuez à ajouter de plus en plus de boîtes. Les données sont réparties sur plusieurs serveurs. Ce sont des serveurs à bas prix d'ailleurs. Ce ne sont pas des serveurs de type base de données haut de gamme. En fait, nos clients… La configuration typique est d'environ 16 Go de RAM, environ 8 cœurs, comme une boîte de serveur Web typique mais juste plus de mémoire. 16 gig, 16 à 32 gig, nous ne recommandons même pas d'aller plus de 32. En fait 64 gig est à peu près le maximum que nous recommanderons à nos clients. Nous dirons, ajouter plus de serveurs. Pourquoi donc? Parce que, si vous augmentez trop la mémoire, .NET a ce truc appelé ramasse-miettes. De plus, le ramasse-miettes nécessite beaucoup de puissance de traitement. Ainsi, plus vous avez de mémoire, plus il doit faire de récupération de place et plus votre processeur doit devenir rapide, puis votre cache ne ressemble plus de plus en plus à une base de données et il devient plus cher et tout. Il est donc préférable d'avoir plus de serveurs que quelques serveurs haut de gamme.

Ainsi, un cache distribué forme essentiellement un cluster de serveurs. Il s'agit généralement d'un cluster basé sur TCP et ce cluster signifie que chaque serveur du cluster se connaît et regroupe les ressources en une seule capacité logique. Avoir le cluster signifie que lorsque vous avez besoin d'augmenter la capacité, vous ajoutez simplement un autre serveur au cluster. Ou, lorsque vous avez besoin de diminuer la capacité, vous supprimez un serveur. Et, lorsque vous avez ce niveau de mise en cache, il s'agit d'un magasin en mémoire, car vous n'avez pas besoin de conserver les données. Ce n'est pas un magasin permanent. Le magasin permanent est toujours la base de données et, comme il s'agit d'un magasin en mémoire, il doit également fournir la réplication des données.

Le but dans toute cette image est essentiellement d'aller au cache environ 80% du temps. Donc, si vous pouviez imaginer, si vous alliez au cache 80% du temps, votre base de données serait totalement sans stress, vous savez. Vous pourriez vraiment augmenter un peu l'évolutivité.

Question : L'application n'a-t-elle toujours pas trop besoin de parler à la base de données ?

Ce n'est pas le cas, en fait. Donc, cela dépend des données. Mais la plupart des données d'application se situent entre la catégorie des données de référence ou des données transactionnelles qui ne changent pas toutes les quelques secondes. Il change peut-être toutes les quelques minutes. Ainsi, pour toutes ces données, vous effectuez beaucoup plus de lectures que d'écritures. Ainsi, la première lecture va à la base de données et même qu'il existe des fonctionnalités telles que NCache a une fonctionnalité où vous pouvez précharger le cache avec des données. Ainsi, vous pouvez réchauffer le cache avec toutes les données que vous pensez avoir et même ce trafic n'est pas touché, la base de données n'est pas touchée. Mais cela dépend des données. Par exemple, si vous avez un autre type de données, disons, si vous deviez y stocker des sessions, alors pour chaque lecture, il y a une écriture. Donc, cela dépend et je vais passer en revue ces détails, mais c'est une bonne question.

Eh bien, la raison pour laquelle vous ne le seriez pas, c'est que le cache charge les données et les conserve dans le cache. Ainsi, le trafic entre le cache et la base de données est très peu fréquent. Encore une fois, comme je l'ai dit, 80 % du temps, les lectures sont effectuées et le cache contient les données. Ainsi, lorsque vous le cachez, vous le mettez en cache pendant un certain temps et pendant cette durée, le cache ne va pas à la base de données à chaque fois. Mais, l'application arrive à chaque fois dans le cache. Ainsi, même si vous avez beaucoup de trafic, tout arrive dans le cache et du coup la base de données est très légère.

En fait, il y a un partitionnement pour chaque boîte qui stocke des données différentes et il y a aussi une certaine redondance intégrée pour la fiabilité, mais j'y reviendrai plus en détail.

Donc, cette image (Fig-1) est destinée à vous convaincre que, dans l'environnement à haute évolutivité d'aujourd'hui, le cache distribué est en quelque sorte la meilleure pratique de facto. Donc, si vous concevez votre application, gardez un cache à l'esprit. Peu importe le cache. C'est une discussion distincte. La première discussion est que vous devez concevoir l'application de manière à ce que vous alliez dans un cache distribué. Si vous faites cela et que vous pouvez être sûr que lorsque l'entreprise a besoin de votre application pour fonctionner, l'application ne va pas s'étouffer.

Et, si vous ne le planifiez pas à l'avance, le véritable inconvénient de ne pas pouvoir évoluer est que ce problème survient lorsque l'entreprise se porte vraiment bien. Imaginez si vous êtes une compagnie aérienne et que vous venez de lancer cette promotion du week-end dans un lieu de vacances et que des millions de nouveaux utilisateurs viennent sur un site Web pour rechercher des vols et peut-être acheter des billets. Si les performances de votre site Web ont commencé à ralentir à chaque clic pendant une minute, vous perdez des clients. Et si cela va encore plus mal et que votre application commence à planter parce que la base de données vient de s'étouffer, vous perdez beaucoup d'affaires. Donc, vous devez planifier à l'avance. Même si vous n'êtes pas confronté à ce problème aujourd'hui et, encore une fois, il ne s'agit pas de performances.

Beaucoup de gens pensent qu'il faut utiliser le cache car cela améliorera les performances. Cela améliore les performances, mais les bases de données sont assez rapides de nos jours. Si vous n'avez que ces cinq utilisateurs. Je n'ai entendu personne se plaindre de la lenteur de la base de données. Donc, le problème n'est pas la performance. Le problème est l'évolutivité, car il n'y a qu'un seul serveur de base de données et vous pouvez ajouter plus de serveurs dans la couche d'application, puis soudainement la base de données devient un goulot d'étranglement.

Question : Doit-on utiliser des VM ou des boîtiers physiques pour les clusters de cache ?

Très bonne question. J'allais en parler et j'ai oublié et c'est bien que tu demandes. Donc, il peut s'agir de boîtes physiques. Nous avons toujours des clients qui ont des box physiques mais de plus en plus de nos clients passent aux VM et maintenant la nouvelle tendance ce sont les containers. Donc, au minimum, vous aurez des machines virtuelles. Ainsi, chaque serveur de cache est une machine virtuelle. Ainsi, vous disposez d'au moins deux machines virtuelles de serveur de cache. Comme je l'ai dit 16 à 32 concerts chacun. Bien sûr, vous ne voulez pas avoir les deux VMS sur le même boîtier physique. Parce que vous perdez alors cet avantage de haute disponibilité. Parce que, si cette boîte plante, les deux VMS ont disparu.

Encore une question. Alors, les données physiques sont stockées en mémoire ?

En mémoire. Exactement exactement. Tout est stockage en mémoire. Et, parce que c'est un magasin temporaire, vous le stockez quelques minutes, quelques heures, quelques jours, quelques semaines, vous savez, vous ne le stockez pas de façon permanente. Le magasin permanent est toujours la base de données. Quoique ce soit. Cela pourrait être, comme je l'ai dit, cela pourrait être un ordinateur central hérité, cela pourrait être relationnel, cela pourrait être NoSQL.

Même avec NoSQL database, vous devez utiliser un cache distribué. Car NoSQL n'est pas aussi rapide qu'un cache distribué et parce que nous avons les deux produits que nous connaissons. Nous réalisons les benchmarks. C'est toujours 10 fois plus rapide.

Je ne connais pas NoSQL database, alors je me demandais simplement pourquoi cela fonctionne mieux qu'une base de données relationnelle?

Il évolue davantage car il distribue également sur plusieurs serveurs. Ainsi, tout comme un cache distribué peut avoir 5, 10, 15, 20 serveurs, vous pouvez faire la même chose avec un NoSQL database. Vous ne pouvez pas avoir 20 serveurs pour SQL. Vous pouvez en avoir peut-être 2, pour actif-passif ou actif-actif mais c'est à peu près tout. Vous savez, vous ne pouvez pas vraiment évoluer. Donc, c'est pour des raisons d'évolutivité.

Donc, ce sont soit les machines virtuelles, soit les conteneurs deviennent de plus en plus populaires pour la gestion et cela peut être soit sur site, soit dans le cloud, n'importe quel environnement.

Utilisations courantes du cache distribué

Donc, j'espère que cette image (Figure-1) vous convaincra que vous devez utiliser la mise en cache. Alors, maintenant vous êtes convaincu, disons. La prochaine question qui vient est, comment puis-je l'utiliser? Où est-ce que je l'utilise, tu sais ? Donc, il y a trois endroits communs où vous utilisez la mise en cache.

Mise en cache des données d'application

Premièrement, ce dont j'ai parlé jusqu'à présent, c'est-à-dire les données d'application, c'est-à-dire cette image exacte. Vous cachez les données ici, de sorte que vous n'ayez pas à accéder à la base de données. La seule chose à garder à l'esprit dans mise en cache des données d'application est que maintenant les données existent à deux endroits. L'un est le cache, l'autre est la base de données. Lorsque les données existent à deux endroits, qu'est-ce qui pourrait mal ? Synchronisation. C'est donc un si gros problème que la plupart des gens ont peur d'utiliser le cache, pour autre chose que des données en lecture seule. Si vous demandez à une personne moyenne, avez-vous pensé à utiliser le cache ou faites-vous du cache ? Parfois, les gens construisent ces tables de hachage ou certaines dans le magasin de mémoire, ils ne mettent que des données en lecture seule. Des données qui ne changent jamais dans l'intégralité de l'application ou dans des délais vraiment très confortables. Eh bien, les données en lecture seule ou les données de référence ne représentent que 10 à 15 % du total des données. Donc, cela vous donne beaucoup d'avantages, mais le véritable avantage est que vous pouvez mettre en cache toutes les données. Cela signifie que vous devez vraiment être capable de gérer…

Un bon cache distribué doit gérer la synchronisation. Ainsi, il doit s'assurer que le cache est toujours frais. Ainsi, vous avez cette confiance dans le cache que tout ce que vous lisez dans le cache est la dernière copie de ces données.

Et, si vous n'avez pas cette confiance, vous serez limité aux données en lecture seule, ce qui minimise ou réduit à peu près la valeur du cache.

Mise en cache spécifique à ASP.NET

Ainsi, le deuxième avantage est le Mise en cache spécifique à ASP.NET. je ne passe pas en ASP.NET Core pour le moment, mais je vais en quelque sorte en parler brièvement. Mais, la mise en cache ASP.NET, il y a trois endroits où vous faites cela et deux au moins maintenant. Si vous avez le framework MVC, vous n'avez pas l'état d'affichage, mais les sessions de chaque application ASP.NET ont des sessions et les sessions doivent être stockées quelque part. Par défaut, ils sont soit stockés en mémoire, c'est-à-dire In-Proc, qui se trouve dans le processus de travail de l'application ASP.NET ou du serveur SQL. Le serveur d'état n'est pas disponible dans le cloud, il est uniquement sur site et tous ont des problèmes. Certains ont des problèmes d'évolutivité. En fait, tous ont des problèmes d'évolutivité. Certains ont également des problèmes de performances. Comme la base de données SQL a également des problèmes de performances.

Ainsi, un très bon cas d'utilisation du cache distribué consiste simplement à mettre ces sessions dans le cache. Vous savez, ces sessions sont stockées… si vous les stockez en SQL, elles sont stockées sous forme de blobs. De plus, les bases de données relationnelles ne sont pas conçues pour le stockage d'objets blob. Mais, NoSQL ou les magasins de valeurs clés, la valeur est le blob. Donc, il s'intègre vraiment très bien dans un cache distribué. Bien sûr, vous devez également résoudre… de plus en plus de personnes se tournent vers plusieurs bases de données ou plusieurs centres de données pour la reprise après sinistre ou pour l'équilibrage de charge, l'équilibrage de charge géographique. Donc, vous devez également résoudre ce problème.

Un état d'affichage est quelque chose qui n'est plus dans ASP.NET mais si vous êtes précédent - je pense ASP.NET 5. Si vous êtes sur ASP.NET 4, alors l'état d'affichage ou pré MVC, l'état d'affichage existait. Il existe toujours dans la majorité des applications ASP.NET qui ont été développées pendant tout ce temps.

Pour ceux d'entre vous qui ne savent pas ce qu'est un état d'affichage, un état d'affichage est une chaîne cryptée qui est envoyée par le serveur Web au navigateur, uniquement pour revenir lorsqu'une publication se produit. Ainsi, cette chaîne pourrait être des centaines de kilo-octets et elle se déplace vers le navigateur, est stockée dans le navigateur, puis revient. Multipliez cela par des millions de transactions que votre application doit traiter et cela a deux problèmes, l'un consomme beaucoup de bande passante, ce qui n'est pas une bande passante bon marché, vous devez payer pour la bande passante. Deuxièmement, cela ralentit le temps de réponse car il s'agit d'une charge utile lourde qui se déplace. C'est donc un cas idéal pour mettre cela en cache sur le serveur et envoyer simplement une petite clé et quand elle reviendra la prochaine fois, l'état d'affichage est extrait du cache et servi à la page. Encore une fois, l'état d'affichage n'est une question que si vous n'utilisez pas le framework MVC et ce n'est certainement même pas là dans ASP.NET Core parce que ASP.NET Core est MVC.

Le cache de sortie ASP.NET fait également partie de l'ASP..NET framework, pas dans l'ASP.NET Core où il met en cache à peu près les sorties de page. Donc, si votre page ne change pas à la prochaine requête, pourquoi l'exécuter à nouveau ? Ainsi, ASP.NET met la page en cache, de sorte que la prochaine fois que la requête arrive avec les mêmes paramètres, le même tout, une sortie de la dernière exécution sera servie à la page.

Donc, ce framework est déjà là et c'est vraiment une bonne chose d'utiliser un cache distribué pour cela, de sorte que, dans un environnement multi-serveurs, une fois mis en cache, il est immédiatement disponible pour tous les serveurs. ASPIC.NET Core n'a que des sessions pour la mise en cache et il n'y a pas d'état d'affichage et il n'y a pas de cache de sortie. Mais, il y a une autre chose qui s'appelle la mise en cache des réponses. Alors, ASP.NET Core a en quelque sorte normalisé maintenant avec les applications Web globales où la mise en cache du contenu se produit en dehors du serveur. Donc, c'est aussi un bon candidat pour la mise en cache. Alors, ASP.NET Core a ceci un concept de middleware de mise en cache de réponse. Il existe donc un middleware intégré que vous pouvez utiliser, puis vous pouvez créer un middleware tiers. Aimer NCache en fournira un très prochainement.

Donc, de toute façon, pour la mise en cache ASP.NET et c'est une chose importante à garder à l'esprit maintenant, c'est que vous ne stockez plus ces données dans le cache. Ainsi, contrairement aux données d'application où les données existent à deux endroits, maintenant les données n'existent qu'à un seul endroit et c'est le cache et c'est un cache en mémoire. Ainsi, lorsque le magasin en mémoire est votre seul magasin, qu'est-ce qui pourrait mal tourner ? Oui. Je veux dire, si cette boîte tombe en panne, vous êtes arrosé. Parce que la mémoire est volatile. Ce n'est pas persistant. Donc, la façon de gérer cela est bien sûr de faire une réplication. Avoir ces données sur plus d'un serveur. Mais, encore une fois, deux problèmes très différents à résoudre. Un bon cache distribué doit faire une réplication intelligente. Si vous souhaitez stocker en toute confiance des sessions ASP.NET, par exemple. Sinon, que va-t-il se passer ? Revenons à cela, vous savez, la compagnie aérienne. Je viens d'aller sur ce site. Je vais acheter pour 5,000 XNUMX $ de billets. J'ai fait toute ma recherche de vol, toutes sortes de combinaisons et je suis sur le point de… J'ai saisi mes informations de paiement et je suis sur le point de les soumettre et, du coup, j'ai renvoyé vers, vous savez, la page de démarrage, peu importe, parce que ma session est perdu. Parce que lorsque j'ai cliqué sur Soumettre, il est allé au serveur Web, ce serveur Web n'était pas là, il s'est écrasé et la session a disparu. Donc, certainement pas une bonne image.

Partage de données d'exécution via des événements

Le troisième cas d'utilisation est un partage de données d'exécution à travers les événements. C'est quelque chose que beaucoup de gens ne savent pas, il devient de plus en plus populaire qu'un cache distribué une fois que vous l'avez dans votre environnement, c'est une plate-forme vraiment puissante pour le partage de données entre plusieurs applications via comme un Pub / Sous-marin modèle ou autre partage de données basé sur des événements.

Par exemple, vous pouvez avoir plusieurs applications qui doivent partager des données. Une application produit quelque chose, le met dans le cache, déclenche certains événements, il y a des abonnés à cet événement. Donc, il existe d'autres instances d'application ou d'autres applications, souvent une sorte de flux de travail se produit dans les applications. Que quelque chose est fait en premier et ensuite, sur la base de cela, quelque chose d'autre est fait. Et, dans ce cas, il y a ces abonnés à ces événements. Ces demandes seront notifiées.

Pensez maintenant à cette image (Figure 1) ici. Ne voyez pas cela comme un cache entre l'application et la base de données. Considérez cela comme un bus de messages et ces applications sont toutes connectées au bus de messages. Une application de ce serveur met des données dans le cache, déclenche un événement. D'autres applications peut-être sur certains de ces serveurs seront averties et elles iront immédiatement consommer les données. Manière très puissante.

Certaines personnes utilisent des files d'attente de messages. Pour beaucoup de ces files d'attente de messages ont un but précis. Un cache distribué n'est pas là pour les remplacer complètement mais un sous-ensemble des cas. Lorsque tout le partage de données se fait au sein du même centre de données, il ne s'agit pas d'un environnement très distribué et d'un environnement à fort trafic. Une file d'attente de messages n'est pas évolutive, contrairement à un cache distribué. Parce qu'une file d'attente de messages n'a pas de cluster comme celui-ci. Vous ne pouvez pas vraiment en ajouter plus. Ainsi, si vous aviez des millions de transactions en cours et qu'une partie de celles-ci était également constituée d'informations sur les messages, les files d'attente de messages ne peuvent pas gérer cette charge, mais un cache le peut.

Ainsi, un partage de données d'exécution est un moyen vraiment puissant et je vais y toucher. Encore une fois, dans le partage de données d'exécution, les données n'existent généralement que dans le cache. Cependant, une forme différente de celui-ci peut exister dans la base de données. Parce qu'il a été lu à partir de la base de données, transformé sous une autre forme, puis mis dans le cache pour le partage.

Ainsi, certaines fonctionnalités sont communes à tous les caches. Certains ne sont que NCache côté .NET mais tout ce qui est NCache côté .NET n'est pas une fonctionnalité propriétaire de .NET. Parce que vous voyez les mêmes fonctionnalités du côté Java et tous les caches Java. Ainsi, Java est un marché beaucoup plus avancé ou beaucoup plus mature car Java est la technologie côté serveur depuis plus longtemps que .NET. Donc, vous voyez que... Du côté de Java. Du côté .NET, vous le verrez dans certains des caches, pas tous. Par example, AppFabric, je pense ne pas l'avoir. Redis en a une partie pas tout. NCache a un plein soufflé comme les caches Java.

Donc, ce sont les trois cas d'utilisation. Des questions à ce sujet, avant de plonger plus profondément dans chacun d'eux ?

Démonstration pratique

Avant d'aborder l'une de ces questions, laissez-moi d'abord vous montrer à quoi ressemble une cache ? Je vais bien sûr utiliser NCache comme exemple, mais le but est de vous donner une idée de ce à quoi ressemble vraiment une cache. Ainsi, par exemple, j'ai trois machines virtuelles dans Azure. Ils sont en cours d'exécution. Demo1 et demo2 sont mes machines virtuelles de serveur de cache. Donc, je vais avoir un cluster de cache à 2 nœuds.

Le client de démonstration est mon serveur d'application. Il s'agit donc d'une VM cliente de cache.

Créer un cache en cluster

Je suis connecté à la machine virtuelle du client de démonstration ici. Je vais continuer et créer un cache en cluster. En cas de NCache, je vais utiliser cet outil appelé NCache Gérante, qui est un outil graphique. Je viendrai ici et dirai, laissez-moi d'abord m'assurer que le cache n'existe pas déjà. D'accord, ce n'est pas le cas, d'accord, je vais venir ici et dire créer un nouveau cache en cluster.

En cas de NCache tous les caches sont nommés. Donc, mon cache s'appelle démoCache. Je vais juste laisser tous les paramètres par défaut. Je ne vais pas entrer dans les détails. Je vais juste garder… Je ne parlerai que des parties qui sont importantes.

La première chose que vous choisirez est ce que nous appelons un mise en cache de la topologie dans NCache et c'est là que l'un d'entre vous a posé la question sur le partitionnement. Les données sont-elles vraiment distribuées ou les mêmes données existent-elles dans chaque serveur. Ainsi, la réplique de partition est une topologie qui NCache vous donne.

Par exemple, je vais rapidement sauter ceci et je parlerai rapidement de ce qu'est cette topologie ? Donc, une topologie de réplique de partition… Donc, c'est une topologie partitionnée, c'est une réplique de partition.

Dans un partitionnement, chaque serveur a 1 nième des données. Donc, si vous avez, disons, en cas de NCache, lorsque vous créez un cache en cluster, il crée mille compartiments. Donc, si vous avez un cluster à deux serveurs, chaque serveur 500. Si vous en avez trois, chaque serveur est un tiers de mille.

Ainsi, ces seaux sont essentiellement comme des seaux de table de hachage. Chaque compartiment se voit attribuer une plage de valeurs clés. Il existe donc une fonction de carte de hachage qui transforme vos clés en valeurs de hachage et elles tomberont dans les compartiments dans lesquels elles devraient tomber en fonction des clés. Ainsi, une réplique partitionnée a une partition sur chaque serveur. Disons, si vous deviez venir ici. Disons, voici un cluster de trois serveurs, donc, les trois partitions et chaque partition a une sauvegarde ou une réplique sur un serveur différent.

En cas de NCache la réplique n'est pas active. C'est passif. Ainsi, seule la partition communique avec les répliques. L'application parle aux partitions. Donc, disons que chaque client de cache, chaque serveur d'application se connecte à tous les serveurs de cache. Il se connecte et obtient toutes les informations d'appartenance au cluster. La carte de distribution est cette carte de compartiment. Ainsi, il obtient la carte des compartiments qui lui indique où se trouve chaque compartiment ? Sur cette base, il sait, d'accord, si je dois ajouter l'élément numéro trois, je dois aller sur le serveur 2. Parce que c'est là que vit la partition 2, qui est censée avoir la clé pour l'élément numéro 3. Donc, ça va directement à ce serveur et il peut le faire.

Et, ensuite, si un serveur tombe en panne, alors, disons, la partition 3 tombe en panne, donc la réplique 3 deviendra immédiatement active. Donc, ça va devenir une partition maintenant. Il passera d'une réplique à une partition. Parce que, tu ne sais pas, tu veux continuer. Le cache doit s'exécuter, l'application doit continuer. C'est la haute disponibilité, n'est-ce pas. Donc, et puis cette partition trois se rend compte qu'il n'y a que deux serveurs, donc, elle doit se fusionner dans ces deux partitions et en quelque sorte s'en aller, disparaître. Ainsi, il se fusionne dans les deux autres partitions, puis une fois que cela est fait, une réplique pour la partition deux est créée ici.

Donc, encore une fois, juste pour vous donner un aperçu de ce que signifie cette topologie et c'est ainsi que la distribution se produit pour garantir que lorsque vous ajoutez plus de serveurs, vous avez de plus en plus de stockage et c'est également ainsi que la réplication se produit afin que chaque donnée existe dans deux serveurs . Ainsi, il n'y a aucune perte de données si un serveur tombe en panne.

Encore une fois, la théorie de la haute disponibilité dit que deux serveurs ne tomberont pas en panne simultanément. Les chances que deux serveurs tombent en panne simultanément sont astronomiquement faibles par rapport à n'importe quel serveur qui tombe en panne. Bien sûr, comme je l'ai dit, si deux serveurs sont sur la même alimentation, cette alimentation tombe en panne, alors je suppose que tout est redondant. Alors deux choses n'échoueront pas en même temps. Donc, c'est pourquoi avoir juste deux copies est plus que suffisant.

Retournons. Donc, c'était la réplique de la partition. Ensuite, je choisirai une réplication asynchrone.

Donc, il y a deux modes. La plupart des caches distribués font ce qu'on appelle la cohérence éventuelle. Ce qui veut dire qu'à cause de la distribution, si vous deviez faire une synchronisation immédiate alors tout va ralentir. Mais la plupart des données que vous pouvez vous permettre sont en quelque sorte mises en file d'attente et mises à jour asynchrones. Ainsi, l'async est ce qui sera pris par défaut ici.

Je choisirai le client démo ou la démo 1 est le premier serveur. Je choisirai la démo 2 comme deuxième serveur.

Je vais venir ici, je vais juste prendre les valeurs par défaut.

Je vais spécifier la quantité de mémoire que chaque serveur doit utiliser.

Bien sûr, dans votre cas sera beaucoup plus. Donc, disons que si vous avez 16 Go de mémoire dans chaque boîte, vous devez en allouer une partie pour la partition et une autre pour la réplique. Donc, disons, 2 à 3 Go devraient être laissés pour le système d'exploitation et d'autres processus et il reste environ 13 Go. Ainsi, par 7.5 ou 6.5 concerts, un pour la partition, un pour la réplique. Et, parce que vous spécifiez cette taille pour vous assurer que le cache ne consomme pas plus que cela. Parce que c'est un magasin en mémoire, la mémoire est toujours limitée et sur cette boîte il peut y avoir d'autres applications en cours d'exécution. Donc, vous voulez en quelque sorte limiter la quantité de mémoire que le cache doit utiliser et une fois que le cache a utilisé cette mémoire…

Donc, alors la page suivante serait. Disons que vous avez utilisé toute cette mémoire. Donc, maintenant, le cache est plein. Donc, il n'y a que deux choses qui peuvent arriver. Premièrement, il expulse certaines des données les plus anciennes ou d'autres ou deuxièmement, il rejette les nouvelles insertions. Donc, vous devez choisir ces deux-là. Bien sûr, vous voulez faire votre planification de capacité, où les données qui sont, si les données d'application, c'est bien de les expulser parce que vous pouvez toujours les recharger à partir de la base de données. Il n'est pas acceptable d'expulser des sessions. Donc, vous voulez faire votre planification de capacité de manière à ce que ces sessions ne soient jamais évincées. Maintenant, vous avez assez de mémoire, assez de RAM et assez de serveurs pour avoir toujours de la mémoire pour les sessions. Et, vous voulez faire expirer les sessions, pas expulser le thème. Expulser signifie que les sessions n'ont toujours pas expiré mais qu'il n'y a plus de mémoire, donc, vous êtes en quelque sorte expulsé de force. Expiration en cas de NCache signifie que vous avez spécifié qu'une session n'est valable que pour, disons, 20 minutes d'inactivité. Après cela, la session doit être nettoyée. Donc, c'est l'expiration. Donc, l'expiration est OK, il n'y a pas de problème mais l'éviction est quelque chose que vous ne devriez pas faire à la session, c'est bien de les faire aux données d'application.

Alors, que faites-vous en cas de NCache, vous créez un cache pour les sessions et un cache pour les données d'application. Donc, c'est comme ça que vous séparez les deux. Alors, disons que je viens de créer ce cache. Donc, c'est un cache à deux nœuds. Je vais continuer et ajouter un nœud client qui est ma boîte le client de démonstration et maintenant je vais juste démarrer le cache.

Simuler le stress et surveiller les statistiques du cache

Donc, comme vous pouvez le voir, c'est assez simple. C'est une sorte d'interface de style Explorer. À partir d'un endroit, vous pouvez continuer et créer un cache multi-serveurs, le gérer, le surveiller, puis une fois que vous avez fait cela, ce qui se passe est, disons, maintenant que c'est fait, je verrai des compteurs PerfMon et je vais exécutez cet outil appelé outil de test de stress fourni avec NCache, qui vous permet de simuler très rapidement l'utilisation de l'application.

Alors, disons que je viens de le faire et maintenant ça commence à… Donc, ça fait environ 500 à 800 transactions par serveur. Donc, c'est environ fois 2, c'est la charge. Je veux augmenter la charge. Donc, je veux ajouter un autre outil de test de stress. Nos clients l'utilisent beaucoup car presque tout le monde veut voir comment le cache fonctionne dans son environnement. Vous savez, nous avons tous les benchmarks publiés et tout, mais ils veulent le voir dans leur environnement. Ainsi, au lieu de programmer et d'appliquer pour le faire, cela peut très rapidement simuler. Alors, disons, j'en ai couru deux et maintenant la charge a augmenté. Donc, je peux continuer à en ajouter de plus en plus jusqu'à ce que j'atteigne le maximum de ces deux serveurs. C'est donc là que vient l'évolutivité.

Ces deux serveurs fonctionnent actuellement très rapidement. Mais, à mesure que j'augmente la charge, après un certain point, ils atteignent leur maximum, ce qui arrive à une base de données. La seule différence est que vous pouvez venir ici et ajouter un autre nœud. Donc, si vous aviez une troisième machine virtuelle, vous venez ici et ajoutez cela ici et dès que vous faites cela, tout à coup, la charge sera distribuée et, nous avons cette image où, vous savez, où je vous ai montré où vous avez commencé avec les deux serveurs et maintenant ces deux ont atteint leur maximum, vous voulez en ajouter un troisième. Donc, vous venez d'obtenir une autre machine virtuelle et de l'ajouter et maintenant cela devient un serveur à trois et NCache réajustera automatiquement tout, nous repartitionnerons ou redishommage à la carte du seau. Donc, il y a un troisième serveur ajouté au moment de l'exécution. Donc, tout à coup, vous n'avez plus ce problème de capacité.

Ouais, donc, ce que vous faites, c'est que vous installez le NCache logiciel serveur, sur toutes ces machines virtuelles. Dans le cas du cloud, vous avez généralement une image de machine virtuelle préconfigurée sur laquelle vous créez les instances et vous lancez simplement une nouvelle machine virtuelle, elle a NCache logiciel en cours d'exécution et vous l'ajoutez simplement à ce cluster.

Mais, encore une fois, le point principal étant que, contrairement à une base de données où une fois que vous atteignez cet état maximal, vous êtes arrosé, vous savez. Que fais-tu? Vous savez, d'accord, je veux en acheter un plus cher. Eh bien, vous devez aller acheter une autre boîte et faire tomber cette boîte et c'est un cauchemar. Ici, vous venez d'ajouter une autre boîte.

En utilisant NCache avec des sessions ASP.NET

Donc, je vais aller à celui-là maintenant. Donc, maintenant que nous savons à quoi ressemble une cache. Donc, maintenant nous voyons que… en cas de NCache, tous les caches sont nommés. Donc, tant que vous connaissez le nom du cache, vous vous connectez simplement au cache. Alors, comment se connecte-t-on au cache pour les sessions ? C'est le plus simple. Encore une fois, la plupart de nos clients, la première chose qu'ils font avec NCache ils l'utilisent pour les séances. Pourquoi? Parce qu'il n'y a pas de programmation nécessaire. La seule chose dont vous devez vous assurer en cas de sessions est que tous les objets que vous mettez dans la session sont tous sérialisables. Si vous stockez déjà une session dans SQL, vous vous en êtes déjà assuré. Si vous stockez des sessions en mode In-Proc, vous ne l'avez peut-être pas assuré. Donc, vous savez, c'est le seul test que vous devez faire. Mais après c'est assez simple.

Je vais juste vous montrer un petit échantillon ici. Ainsi, par exemple, il existe ici un exemple appelé exemple de fournisseur de magasin de sessions. Donc, j'ai une application ASP.NET. Je vais aller sur le web.config. Supposons que je sois sur cette boîte de serveur d'applications, vous savez. Si vous voyez cette image ici. En fait, permettez-moi de revenir ici. Donc, voici le serveur de cache, mais mon application s'exécute sur cette boîte. Donc, sur cette boîte, j'ai créé deux clusters de serveurs et j'y ai ajouté un client, d'accord. Donc, maintenant, ce qui s'est passé sur ce client, c'est qu'en cas de NCache, oups non pas ici. D'accord, en cas de NCache il crée en fait dans le dossier de configuration un fichier client.ncconf, il crée donc une entrée. C'est ainsi que l'application sait à quel serveur se connecter.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <ncache-server connection-retries="3" retry-connection-delay="0" retry-interval="1" command-retries="3" command-retry-interval="0.1" client-request-timeout="90" connection-timeout="5" port="9800" local-server-ip="10.2.0.5" enable-keep-alive="False" keep-alive-interval="0"/>
    <cache id="demoCache" client-cache-id="clientCache" client-cache-syncmode="optimistic" skip-client-cache-if-unavailable="True" reconnect-client-cache-interval="10" default-readthru-provider="" default-writethru-provider="" load-balance="False" enable-client-logs="False" log-level="error">
      <server name="10.2.0.5"/>
      <server name="10.2.0.6"/>
    </cache>
  </configuration>

Encore une fois, ce ne sont que la liste initiale des serveurs. Ce n'est pas la liste finale. Pourquoi? Parce que, pour un environnement à haute disponibilité, que se passerait-il si vous ajoutiez ce troisième serveur au moment de l'exécution ? Ce n'est pas dans cette liste, n'est-ce pas ? Donc, disons, c'était le point huit (.0.8), quelque chose. Donc, ce n'est que la liste initiale. Une fois que l'application connaît l'un d'entre eux, elle s'y connecte. La première chose qui arrive à l'application, une fois qu'elle se connecte, reçoit les informations d'appartenance au cluster et également chaque fois que l'appartenance au cluster change et que vous ajoutez un autre serveur et que l'appartenance au cluster mise à jour est envoyée au client et tout est conservé en mémoire. Tout est caché de votre application. Tout est géré par le NCache partie client mais c'est ainsi que l'application sait se connecter à votre cache.

Donc, en cas de sessions, vous venez juste ici. Ainsi, dans les sessions, vous devez d'abord ajouter l'assembly.

...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
    <compilers>
		<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
	</compilers>
	<assemblies>
	<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769" /></assemblies>
</compilation>
...

En cas de NCache vous venez de … cet assemblage implémente le interface du fournisseur d'état de session qui fait partie de l'ASP.NET framework et en faisant ça NCache devient un tiers, un stockage personnalisé. Et donc, ce n'est qu'un copier-coller, puis les changements réels dans la balise d'état de session. Donc, ce que vous faites ici, vous vous assurez que le mode est personnalisé.

...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
    <providers>
        <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
    </providers>
</sessionState>
...

Donc, les modes sont, il y a In-Proc, le serveur d'état, le SQL et il y a la coutume. Il y a donc quatre modes que vous avez. Donc, si le mode est personnalisé, vous voulez également vous assurer que le délai d'expiration est celui que vous souhaitez que le délai d'expiration de la session soit, puis copiez les détails du fournisseur. C'est-à-dire, en cas de NCache c'est cette ligne et la seule chose qu'ils doivent changer est le nom du cache. Ainsi, par exemple, ici, le nom du cache est déjà modifié. Vous faites ce changement, c'est tout. Et, dès que vous apportez cette modification, ASP.NET redémarre quand même votre processus de travail et vous verrez que chaque session sera enregistrée en tant qu'objet unique dans le cache et vous constaterez immédiatement une énorme amélioration des performances. Parce que, maintenant, vous ne les enregistrez pas dans SQL.

Ainsi, le moyen le plus rapide de bénéficier d'un cache distribué comme NCache est juste, le mettre pour les sessions. Parce que, pour l'objet pour la mise en cache des données d'application, il y a plus de travail. Bien sûr, vous savez, vous voulez faire cela et c'est ce que je vais aborder, mais le premier cas d'utilisation est la spécification ASP.NET.

Des questions à ce sujet ? Ainsi, ce que nous avons vu, par exemple, certains de nos clients haut de gamme ont environ 50 à 100 serveurs au niveau application. Pour cela, disons, garder un ratio de 1 à 5 est ce qui se passe généralement. Ainsi, pour une configuration de 100 serveurs, ils auront 20 serveurs de cache. Plus de 50, c'est très peu, vous savez, il faut vraiment avoir beaucoup de trafic pour avoir plus de 50 serveurs dans un environnement à charge équilibrée. La plupart des clients ont entre 4 et 12 serveurs. Et, comme je l'ai dit, nous recommandons d'avoir un rapport de 4 à 1 ou 5 à 1 selon la nature de l'application. Parfois, cela peut même être supérieur à 5 pour 1, mais je veux dire que c'est comme le cas d'utilisation moyen. Ainsi, si vous avez un 5 à 1 et que vous avez 12 serveurs dans le niveau application, vous avez un niveau de mise en cache à trois serveurs. Donc, pas tant que ça de connexions, ouais.

Théoriquement, oui. Si vous continuez à ajouter de plus en plus de serveurs, vous allez avoir beaucoup de serveurs redondants. Mais, les cas d'utilisation dont nous parlons, ça ne tombe pas. Le traitement de données volumineuses pourrait avoir 50 ou 100 serveurs, mais il n'y a pas de clients dans ce cas et un traitement de données volumineuses n'appartient qu'au serveur. Parce que tout tourne sur le serveur lui-même. Mais, dans le cas d'une application Web ou d'une application de services Web, nous appelons le commerce électronique, le modèle commercial en ligne. Je veux dire que c'est à peu près. Je pense que vous pouvez supposer que dans la plupart des cas, vous aurez moins de 20 serveurs et un très petit pourcentage de clients en aura plus de 20 et plus de 50 est très faible.

Ouais absolument. Donc, par exemple, si je devais venir ici, je vais juste… si je devais venir ici. je n'utilise pas le Package NuGet ici mais je pourrais venir ici et aller au NuGet et je pourrais dire ici NCache, par exemple, et vous obtiendrez un NCache SDK, NCache Services de session pour l'entreprise et le professionnel et il y a aussi un Open-Source, il y a aussi NHibernate. Donc, il y a un tas de NuGets. Donc, un exemple typique… pour les sessions, vous incluez simplement ce package NuGet de session. Pour la mise en cache des données d'application, vous incluez simplement le SDK et cela inclura tout ce dont vous avez besoin.

Présentation de la mise en cache des données d'application (API)

Alors, mise en cache des données d'application est quelque chose où vous devez programmer. Ainsi, vous voyez le cache comme une base de données. Vous vous connectez au cache. En cas de NCache nous avons cette méthode appelée Initialiser le cache.

Connexion au cache

Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();

Récupération des données

Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");

Écrire des données

cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

Vous pouvez avoir d'autres méthodes pour d'autres caches et il y a un nom de cache en cas de NCache comme nous en avons parlé et cela vous donne une poignée de cache.

Alors, passons à une application. Encore une fois, nous allons juste entrer dans… Il s'agit d'une simple application console. Ce que vous faites, c'est que si vous aviez inclus le package NuGet, tout cela sera fait pour vous. Vous feriez référence à certains NCache assemblées. Donc, il n'y a que deux assemblys que vous devez référencer, NCache.Durée ainsi que NCache.La toile. NCache.La toile est l'API publique réelle en cas de NCache. Ensuite, dans votre application, vous incluez l'espace de noms. Alors, vous avez le NCache.Durée ainsi que NCache.Web.Caching comme espaces de noms.

Ensuite, au début de l'application, vous obtenez le nom du cache à partir, disons, de App.config, puis vous initialisez le cache et vous obtenez un handle de cache. Donc, voici cette poignée de cache que vous devez utiliser partout dans l'application.

Maintenant, allons dans cette poignée de cache. Alors, tu peux faire cache.Ajouter, spécifiez la clé. La clé est comme je l'ai dit, généralement une chaîne. L'objet est votre objet réel, quel qu'il soit. C'est n'importe quel objet .NET, NCache va en fait le sérialiser et l'envoyer au cluster. Donc, tout cela se passe côté client, sur le serveur d'applications.

// Alachisoft (R) NCache Sample Code.
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Web.Caching;
using System;
using System.Configuration;

namespace Alachisoft.NCache.Samples
{
    /// <summary>
    /// Class that provides the functionality of the sample
    /// </summary>
    public class BasicOperations
    {
        private static ICache _cache;

        /// <summary>
        /// Executing this method will perform all the operations of the sample
        /// </summary>
        public static void Run()
        {
            // Initialize cache
            InitializeCache();

            // Create a simple customer object
            Customer customer = CreateNewCustomer();
            string key = GetKey(customer);

            // Adding item synchronously
            AddObjectToCache(key, customer);

            // Get the object from cache
            customer = GetObjectFromCache(key);

            // Modify the object and update in cache
            UpdateObjectInCache(key, customer);

            // Remove the existing object from cache
            RemoveObjectFromCache(key);

            // Dispose the cache once done
            _cache.Dispose();
        }

        /// <summary>
        /// This method initializes the cache
        /// </summary>
        private static void InitializeCache()
        {
            string cache = ConfigurationManager.AppSettings["CacheID"];

            if (String.IsNullOrEmpty(cache))
            {
                Console.WriteLine("The CacheID cannot be null or empty.");
                return;
            }

            // Initialize an instance of the cache to begin performing operations:
            _cache = NCache.Web.Caching.NCache.InitializeCache(cache);

            // Print output on console
            Console.WriteLine(string.Format("\nCache '{0}' is initialized.", cache));
        }

        /// <summary>
        /// This method adds object in the cache using synchronous api
        /// </summary>
        /// <param name="key"> String key to be added in cache </param>
        /// <param name="customer"> Instance of Customer that will be added to cache </param>
        private static void AddObjectToCache(string key, Customer customer)
        {
            TimeSpan expirationInterval = new TimeSpan(0, 1, 0);

            Expiration expiration = new Expiration(ExpirationType.Absolute);
            expiration.ExpireAfter = expirationInterval;

            //Populating cache item
            CacheItem item = new CacheItem(customer);
            item.Expiration = expiration;

            // Adding cacheitem to cache with an absolute expiration of 1 minute
            _cache.Add(key, item);

            // Print output on console
            Console.WriteLine("\nObject is added to cache.");
        }

Et, une fois que vous avez fait cela, vous pouvez également faire _cache.Obtenir et récupérer ce même objet. Donc, si vous deviez voir cela en termes d'API, voici cache.Get, Get, Contient, Ajouter, Insérer, Supprimer et tous les trois ont une version asynchrone, ce qui signifie essentiellement que l'application n'attend pas que le cache soit mis à jour, le contrôle revient immédiatement. Mais, la clé est généralement une chaîne. Il s'agit généralement de quelque chose comme ça. Vous avez le nom du type. En cas de NCache ça dépend. Si vous avez utilisé cette fonctionnalité appelée cache client. Donc, je vais juste sauter là-dessus.

Cache client (près du cache)

Donc, par défaut, vous supposerez que chaque fois que vous faites un cache.Obtenir, vous accédez en fait au niveau de mise en cache. Mais, il y a une chose intéressante que la plupart des gens ne réalisent pas, c'est que, si vous avez utilisé un cache In-Proc, comme l'objet cache ASP.NET et que vous avez décidé de passer à quelque chose comme NCache car nous avons dit que cela améliorerait vos performances et votre évolutivité. Eh bien, c'est une sorte d'amélioration de l'évolutivité, mais tout à coup, vos performances vont en fait chuter, nous avons de nombreux clients qui nous appellent et nous disent, vous savez, mon application a en fait ralenti depuis que je me suis branché NCache. Alors, pourquoi en ai-je vraiment besoin, vous savez. Ce n'est vraiment pas bon, c'est un-vous savez. Donc, nous devons leur expliquer que lorsque vous faites un cache In-Proc, il n'y a pas de sérialisation, il n'y a pas de communication inter-processus entre l'application et le cache, que ce soit sur la même boîte ou dans une boîte séparée, généralement c'est un boîte séparée, à droite. Donc, si l'objet est conservé sur votre tas sous forme d'objet, c'est super rapide, n'est-ce pas. Vous venez d'aller chercher une référence. Rien ne peut égaler cette performance. Mais la raison pour laquelle vous passez à un cache distribué est que ce modèle In-Proc présente de nombreuses limitations. Il ne peut pas évoluer. Vous ne pouvez pas ajouter de plus en plus de données, c'est un seul processus et si vous avez plus d'un processus, la duplication n'est pas synchronisée. Donc, il y a beaucoup d'autres problèmes qui expliquent pourquoi vous passez à un cache distribué, mais vous perdez cet avantage, n'est-ce pas. Donc, ce que nous avons fait, c'est que nous avons trouvé cette chose appelée un cache client qui du côté Java est appelé près du cache et du côté .NET par le temps et le cache est le seul qui l'a.

Donc, ce que cela fait réellement, cela crée en fait un cache local In-Proc dans l'application. Ainsi, il conserve cet objet sous une forme d'objet sur votre tas. Ainsi, vous obtenez les mêmes performances que celles auxquelles vous êtes habitué dans le cache In-Proc autonome. La seule différence est que ce cache sait qu'il fait partie d'un cache en cluster. Ainsi, tout ce qu'il conserve dans sa copie locale, il a un lien vers le niveau de mise en cache. Il a dit au niveau de mise en cache que, vous savez, j'ai cet objet, s'il vous plaît, informez-moi si quelqu'un modifie cet objet. Donc, le cas échéant, disons, si ce client a le numéro d'article un autre client et, bien sûr, cet article numéro un est également dans ce niveau de mise en cache. Un autre client arrive et met à jour cet article numéro un. Le niveau de mise en cache sait que ces caches clients ont l'élément numéro un, donc, ils le notifient par le biais d'événements, vous savez. En cas de NCache ce sont des événements assez rapides. Ce ne sont pas des événements .NET, ce sont des communications au niveau du socket. Ainsi, le cache client se met immédiatement à jour. Donc, nous parlons peut-être d'un délai d'une milliseconde.

Donc, de cette façon, vous êtes sûr que vous êtes, tout ce que vous obtenez est tout ou la plupart du temps exact. Il y a techniquement une petite probabilité qu'il s'agisse d'une copie plus ancienne. En cas de NCache, si cela vous préoccupe trop, vous pouvez utiliser ce que nous appelons le mode de synchronisation pessimiste où chaque fois que vous récupérez quelque chose, vous savez, NCache vérifie en interne le niveau de mise en cache pour voir s'il a une dernière copie. Si ce n'est pas le cas, il le donne à partir des données du cache client, sinon il va le chercher à partir du niveau de cache. Mais, vous n'en avez pas besoin dans la plupart des cas. Dans la plupart des cas, vous êtes d'accord pour prendre autant de risques. Cela vous donne donc l'amélioration des performances du cache In-Proc. Mais, encore une fois, votre application ne sait pas que tout cela se produit.

En cas de NCache votre application le sait. L'application pense qu'elle parle simplement au niveau de mise en cache. Il n'y a qu'un seul cache auquel il parle. Ça s'appelle ma cache ou autre. C'est le cache de démonstration et, le cache de démonstration peut avoir un cache client branché via la configuration en cas de NCache. Des questions à ce sujet ?

API JCache (JSR 107)

Donc, je veux dire, voici à quoi ressemble un cache typique. C'est assez facile de faire cette programmation. Que se passe-t-il maintenant du côté de Java, car encore une fois je ne cesse de les féliciter car ils sont beaucoup plus avancés à ce sujet. Ils ont toute une API standard appelée JCache. Donc, l'API JCache est une fonctionnalité très… elle a toutes les fonctionnalités dont je viens de parler ou dont je parle. Ainsi, JCache est une norme que chaque cache Java doit implémenter s'il veut être compatible avec l'industrie.

API IDistributedCache

Du côté de .NET, il n'y a pas encore une telle chose. Il existe un objet cache ASP.NET qui, jusqu'à récemment, n'était pas connectable. Donc, si vous programmez dans le cache ASP.NET, vous ne pouvez pas vous connecter NCache à sa place. Ainsi, vous ne pouvez pas brancher un cache tiers. Ce n'est qu'un cache autonome. Dans .NET 4.0, ils ont démarré un cache .NET qui n'a jamais vraiment repris. Maintenant en ASP.NET core ils ont un iDistributedCache interface. Ce qui est encore une fois, une méthode de saisie très basique.

Ainsi, le problème avec l'API standard serait que vous ne pourrez pas profiter de toutes les fonctionnalités qu'un bon cache devrait vous offrir. Vous êtes vraiment limité à l'entrée de base. Mais encore une fois, la plupart de nos clients encapsulent de toute façon le niveau de mise en cache. Donc, même s'ils font tout le NCache appels, toute l'application n'y est pas exposée. Donc, de toute façon, voici à quoi ressemble l'API.

Fonctionnalités de mise en cache des données d'application

Passons maintenant à quelques-unes des fonctionnalités qui sont importantes. Donc, la plupart d'entre eux… allez-y. Juste une simple question. Y a-t-il une différence entre insérer et ajouter ? Oui, insérer signifie ajouter ou mettre à jour. Si les données existent déjà, mettez-les à jour, si ce n'est pas le cas, ajoutez-les. L'ajout échouera si les données existent déjà. Et, encore une fois, c'est une API de cache ASP.NET à laquelle nous nous sommes en quelque sorte collés, car nous voulons être aussi proches de la norme à l'époque. Non, non ce n'est pas le cas. Je veux dire, nous l'avons gardé. L'objet de cache ASP.NET a maintenant disparu car maintenant, comme je l'ai dit, dans l'ASP.NET Core n'est plus là, ASP.NET l'a toujours mais ASP.NET Core ne le fait pas.

Expirations absolues

Donc, la première chose que vous devez garder à l'esprit est de garder le cache frais dont nous avons parlé, n'est-ce pas. Comment faites-vous cette technique numéro un est Expirations. Les expirations ressemblent à ceci, revenons à cela. Alors, disons que j'ai… Vous voyez ça les gars ? Peut-tu voir ceci? D'ACCORD. Disons que j'ai une clé et une valeur ou un objet. Je veux l'ajouter au cache et je vais spécifier une expiration d'une minute. Donc, cela s'appelle le expiration absolue.

public static void AddObjectToCache(string key, Customer customer)
    {
        DateTime expirationInterval = new DateTime();
        expirationInterval.AddMinutes(1);
        //Adding item with an absolute expiration of 1 minute
        _cache.Add(key, customer, expirationInterval, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
        Console.WriteLine("\nObject is added to cache");
    }

L'expiration absolue signifie qu'après 1 minute, expirez cela quoi qu'il arrive. Cela signifie que je dis au cache, je ne me sens vraiment pas à l'aise de le mettre en cache pendant plus d'une minute. Parce que, je fais une supposition éclairée qu'il est prudent de garder cela dans le cache pendant une minute.

Expirations glissantes

L'expiration glissante, par contre, a un but totalement différent. C'est pour le nettoyage de choses comme les sessions. Cela n'a rien à voir avec la synchronisation ou la mise à jour du cache. Ainsi, l'expression absolue est quelque chose que presque tous les caches ont. En fait, même l'ASP.NET Core IDistributed Cache Interface a l'expression absolue.

Synchroniser le cache avec la base de données

Mais qu'y a-t-il de mal à ce que l'expression soit le seul moyen de créer du cache ou de garder le cache à jour ? C'est que vous devinez que ces données ne vont pas changer. Et si c'était le cas ? Que se passe-t-il s'il existe d'autres applications, il existe d'autres scripts, qui modifient les données qui, dans n'importe quelle entreprise, il y a généralement plus d'un endroit à partir duquel les données sont mises à jour. Ainsi, si vous ne pouvez pas prédire la fréquence de mise à jour des données, les expressions ne sont qu'un point de départ. Vous devez passer à l'étape suivante, qui est de synchroniser le cache avec la base de données. Donc, en gros, en synchronisant le cache avec la base de données en cas de NCache nous utilisons cette fonctionnalité qui fait partie d'ADO.NET .NET appelée dépendance SQL.

Dépendance SQL essentiellement, laissez-moi vous montrer à quoi cela ressemble. Donc, en cas de dépendance SQL, je fais le même cache.Add, right. J'aurai la clé et au lieu d'avoir la valeur, j'aurai un élément de cache qui est notre propre structure dans laquelle nous mettons l'objet réel et maintenant nous avons ceci, puis nous spécifions cette chose appelée dépendance SQL, dépendance du serveur SQL qui est cette variable qui crée essentiellement l'instruction SQL.

private static void AddProductToCacheWithDependency(Product product)
    {
        // Any change to the resultset of the query will cause cache to invalidate the dependent data
        string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);

        // Let's create SQL depdenency
        CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);

        CacheItem cacheItem = new CacheItem(product);
        cacheItem.Dependency = sqlServerDependency;

        // Inserting Loaded product into cache with key: [item:1]
        string cacheKey = GenerateCacheKey(product);
        _cache.Add(cacheKey, cacheItem);
    }

Ce code est en cours d'exécution sur la boîte du client, ici.

Il communique avec le serveur de cache. Il indique au serveur de cache d'utiliser la fonctionnalité de dépendance SQL ADO.NET pour se connecter à ma base de données. Donc, cela me donne en fait une chaîne de connexion à la base de données. Donc, maintenant que l'application indique au cache, voici ma base de données pour cet élément mis en cache, voici l'instruction SQL qui représente les données correspondantes dans la base de données.

Intégration Entity Framework / Entity Framework Core

Bonne question. Dans le cas d'Entity Framework, l'implémentation que nous avons pour Entity Framework, nous l'avons implémentée à l'intérieur. Même avec Entity Framework, il existe deux façons d'utiliser un cache. Soit vous, dans le cas d'EF Core, la nouvelle architecture permet désormais au cache tiers de se brancher, mais jusqu'à EF6, il n'y avait aucun moyen de brancher un cache. Donc, vous devrez de toute façon effectuer ces appels d'API. Donc, disons que vous avez récupéré une collection d'entités et que vous les mettez en cache, vous pouvez spécifier la dépendance SQL. Avez-vous compris ce que je voulais dire?

En cas de NCache tu dis NCache voici mon instruction SQL. NCache nous utiliserons ADO .NET pour nous connecter à votre base de données et utiliserons la fonctionnalité de dépendance SQL ADO.NET pour ensuite surveiller cet ensemble de données. Alors, NCache dit au serveur SQL, veuillez m'informer si cet ensemble de données change. Ensuite, le serveur SQL envoie une notification de base de données à NCache car NCache n'est pas un client de la base de données, puis NCache sait maintenant que ces données ont changé dans la base de données. Donc, même si vous aviez EF, c'est en quelque sorte contourner cela et maintenant que NCache sait que ces données ont changé NCache a deux options. Il peut soit supprimer cet élément du cache et lorsque vous le supprimez, vous savez, la prochaine fois que quelqu'un en aura besoin, il ne le trouvera pas dans le cache, il devra donc aller le chercher dans la base de données. Donc, d'une certaine manière, vous le rendez frais ou NCache peut recharger ces données à partir de la base de données elle-même pour vous et ce n'est pas possible à moins que vous n'utilisiez une autre fonctionnalité appelée lecture, j'y reviendrai.

Ainsi, la dépendance SQL garantit essentiellement que si vous ne pouvez pas prédire quand les données pourraient changer, vous dites simplement NCache ou votre cache, veuillez surveiller la base de données pour moi.

La dépendance SQL a une limitation selon laquelle vous ne pouvez pas avoir de jointures. Donc, c'est une chose à table unique. Il existe d'autres moyens de surveiller. Par exemple, en cas de NCache il y a une fonctionnalité appelée Dépendance personnalisée, qui est votre code. NCache appelle votre code et dit s'il vous plaît allez surveiller votre source de données et voyez si les données ont changé. Donc, c'est un peu comme un sondage. Alors, NCache interrogera votre dépendance personnalisée et il pourrait alors s'agir d'une structure complexe.

Oui exactement. En fait, lorsque vous faites la dépendance SQL, le cache ne communique pas aussi souvent avec la base de données, car c'est seulement... Ainsi, la base de données est celle qui initie la communication car il y a un événement. C'est une architecture événementielle. Ainsi, la base de données envoie un événement chaque fois que les données changent.

En fait, le serveur SQL a cette fonctionnalité où il surveille l'ensemble de données et il déclenche ensuite des notifications de base de données aux clients. Alors, NCache devient un client de base de données.

Ainsi, une option consistait à supprimer cet élément du cache. L'autre consiste simplement à le recharger. Eh bien, le rechargement signifie le NCache doit avoir un moyen de savoir comment aller chercher ces données et cela signifie qu'il y a cette fonctionnalité appelée lecture qui est votre code que vous écrivez et enregistrez avec le serveur de cache, le cluster de cache. Je vais vous montrer rapidement à quoi ressemble ce code.

Cache de lecture

Non, en fait c'est juste votre code personnalisé. Ainsi, même vous pouvez également effectuer les appels ORM dans ce code. Donc, tout ce code ressemble à ceci. Donc, il y a une interface IReadThruProvider, ici.

...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
    object connString = parameters["connstring"];
    sqlDatasource = new SqlDatasource();
    sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}

// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
    sqlDatasource.DisConnect();
}

// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
    ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
    cacheItem.ResyncOptions.ResyncOnExpiration = true;
    // Resync provider name will be picked from default provider.
    return cacheItem;
}
...

Donc, il y a l'interface IReadThruProvider. Il a trois méthodes. Il y a un Init qui n'est appelé que lorsque le cache démarre. Il est donc censé se connecter à votre source de données. Il y a une disposition qui est à la fin et il y a une charge. Ainsi, load vous donne une clé et vous êtes censé rendre un élément de cache.

Ainsi, sur la base de cette clé, votre code doit savoir où aller car il s'est déjà connecté à votre source de données. Donc, que vous l'utilisiez ORM, que vous fassiez des appels EF, des appels NHibernate, des appels ADO.NET, c'est tout votre code, puis vous irez le charger, disons, vous irez charger cet objet à partir de la base de données et vous mettez-le et vous mettez des expirations ou toute autre métadonnée que vous voulez avec et vous le renvoyez NCache. NCache le mettra alors en cache, avant de le restituer à l'application.

Donc, tout le but de la lecture à travers… laissez-moi juste venir à cette lecture à travers elle-même. La lecture directe est un moyen pour le cache de pouvoir charger des données à partir de votre base de données. Ainsi, vous déplacez en fait une partie de votre code de persistance vers le niveau de mise en cache. Et, si vous avez plusieurs applications qui souhaitent partager un cache, il est parfait d'avoir un mécanisme de lecture et d'écriture. Parce que vous consolidez, vous créez les applications, en quelque sorte moins de code, vous savez. Ainsi, ils auront moins de code car de plus en plus de code de persistance va au niveau de mise en cache. C'est un avantage. Vous savez, l'encapsulation et la consolidation.

Le deuxième avantage de la lecture est ce dont nous venons de parler à propos du rechargement. Ainsi, le rechargement se produit dans deux cas. L'un en synchronisation de base de données, l'autre en expiration. L'expiration est également un excellent cas si vous avez une application à très fort trafic qui, disons, vous avez une sorte de table de recherche ou de tarification qui change et vous avez des milliers de demandes qui arrivent, si vous n'avez pas le fonction de rechargement, puis lorsque les données expirent, des milliers de ces requêtes iront dans la base de données. Et ils chargeront tous le même objet dans le cache. Ce qui est finalement juste beaucoup de trafic vers la base de données. Vous multipliez cela par des milliers d'éléments que vous pourriez avoir, votre base de données verra beaucoup de trafic inutile.

En fait, l'un de nos clients est un client de commerce électronique très haut de gamme dans le secteur des fleurs aux États-Unis, qui a eu ce problème. Ainsi, lorsqu'ils ont implémenté la fonction de rechargement, tout ce problème a soudainement disparu car cet élément n'est plus jamais supprimé du cache. Ainsi, les anciennes copies sont conservées jusqu'à un certain point et la nouvelle copie est mise à jour par-dessus. Ainsi, l'application n'a jamais besoin d'accéder à la base de données. Donc, parce que même en exploration, il ne fait que mettre à jour la nouvelle copie. Donc, c'est beaucoup de… Donc, ce sont les deux avantages de la lecture que vous pouvez combiner avec cette synchronisation.

Cache d'écriture

L'autre aspect est l'écriture directe, qui fonctionne exactement comme la lecture continue, sauf qu'elle est destinée à l'écriture et qu'une écriture peut être ajoutée, insérée, supprimée ou supprimée. Encore une fois, de la même manière que vous avez Init, vous avez Dispose et maintenant vous avez Écrire vers la source de données. Il indique quelle est l'opération et contient également les données et vous allez mettre à jour la base de données. Ainsi, l'écriture immédiate signifie que vous mettez à jour le cache, le cache met à jour la base de données.

Alors, quel est l'avantage de l'écriture continue ? Eh bien, un avantage est le même que la lecture. Vous consolidez toute la persistance. Deuxièmement, l'avantage est l'écriture différée. Parce que les mises à jour de la base de données ne sont pas aussi rapides que, vous le savez, et si vous pensez que la mise à jour de la base de données réussira, mettez simplement à jour le cache et laissez le cache mettre à jour la base de données de manière asynchrone. Bien sûr, vous pouvez être averti si quelque chose échoue, mais vous pouvez passer à autre chose et cela améliore également les performances de mise à jour de votre application. Ainsi, vous n'avez plus besoin d'attendre que les mises à jour de la base de données soient terminées, car elles sont toutes en file d'attente. Donc, c'est la partie écriture derrière. Et la file d'attente d'écriture différée est à nouveau répliquée sur plusieurs serveurs. Ainsi, si un serveur tombe en panne, aucune de vos opérations n'est perdue, en cas de NCache.

Mais c'est ton code. je veux dire NCache appelle le vôtre. Donc, tout cela est votre code. Alors, NCache vous appelle et vous comprenez ce que signifie l'écriture ou ce que signifie la lecture.

Ainsi, la lecture et l'écriture sont une autre fonctionnalité très puissante que vous pouvez combiner avec l'expiration et la synchronisation. Donc, vous devez vous assurer que le cache reste frais, puis vous devez vous assurer que vous utilisez la lecture, l'écriture. Maintenant que vous commencez à le faire, vous pouvez mettre en cache beaucoup de données. Et maintenant, ce cache commence à ressembler à la base de données. Cela signifie que vous ne pouvez pas vraiment obtenir, vous savez, la clé ne suffit plus maintenant. Vous devez être capable de faire des recherches. Vous devez être en mesure de récupérer les choses de manière plus intelligente. C'est donc là que vous devriez pouvoir effectuer des requêtes de type SQL sur le cache. Par exemple, quelque chose comme sélectionner des clients, où le point client Ville équivaut à Londres. Il vous donne une collection de tous les objets client qui correspondent à ces critères. Et le cache indexe ces objets en fonction, disons, de l'attribut city. C'est ainsi qu'il vous permet de rechercher.

Donc, si vous n'êtes pas en mesure de le faire, votre application devient plus complexe car vous ne pouvez rechercher que des éléments sur des clés et, vous savez, vous avez l'habitude de faire beaucoup d'autres choses avec la base de données que vous ne pouvez pas faire avec le cache.

Il n'y a pas de jointures dans un cache mais vous pouvez faire des regroupements. Et, ce genre de but est que vous pouvez obtenir des données, puis les regrouper, puis en fonction de ces groupes, vous pouvez dire, donnez-moi tout ce qui appartient à ces groupes, sous-groupes, étiquettes, étiquettes de nom. Donc, il y a d'autres choses que vous pouvez faire pour regrouper logiquement les choses et les données elles-mêmes que vous mettez en cache peuvent provenir de jointures. C'est juste que le cache ne peut pas être… le cache n'est pas un moteur de recherche. Donc, si vous avez des données de jointure, vous les regroupez simplement.

Dépendances du cache

Donc, il y a une fonctionnalité et encore parce qu'il y a tellement de choses que je ne peux pas vraiment couvrir en ce moment. Donc, il y a une fonctionnalité appelée dépendance de cache qui vient de l'objet cache ASP.NET d'ailleurs, NCache a également mis en place ce qui permet… Vous indiquez au cache cet élément dépend de cet élément. Si jamais cet élément est mis à jour ou supprimé, celui-ci est automatiquement supprimé. Donc, en créant ces relations, vous pouvez avoir ce un à plusieurs, disons, si vous aviez une relation un à plusieurs où le côté plusieurs ne peut pas exister sans le côté un. Disons qu'il s'agit d'un client et d'une commande. Ainsi, si vous supprimez le client, vous souhaitez également supprimer la commande. Ainsi, vous pouvez laisser le cache gérer cela pour vous. De même, lorsque vous mettez en cache, disons, vous avez une collection d'objets, vous pouvez soit mettre en cache la collection entière comme un seul objet, soit les diviser en un individu. Si vous les décomposez, vous souhaitez créer les dépendances de cache. Ainsi, si un objet est supprimé, cette collection n'est plus valide.

Ouais, donc, c'est tout un sujet sur lequel j'ai une discussion, que vous pouvez venir sur notre site Web. Permettez-moi de vous montrer rapidement. Donc, il y a tout un discours là-dessus. Je pense que c'est Gestion des données relationnelles dans un cache. Donc, cela va sur tous les un-à-plusieurs, un-à-un, plusieurs-à-plusieurs, qui va sur les collections que tout ce dont vous venez de parler. Allez juste jeter un oeil à ça. Je vais passer rapidement parce qu'il ne nous reste plus de temps.

Donc, j'ai en quelque sorte essayé d'expliquer pourquoi vous devriez utiliser un cache et comment vous devriez l'utiliser et en maximiser les avantages. je vais sauter le partage de données d'exécution partie, je pense que j'en ai assez couvert. Vous pouvez aller sur notre site Web et en savoir plus. J'ai parlé du cache client, j'ai parlé de la haute disponibilité grâce au partitionnement et tout ça.

Réplication WAN du cache distribué

Il existe également plusieurs centres de données. Vous savez, vous vous attendez à ce que votre base de données soit capable de gérer plusieurs centres de données, alors pourquoi pas le cache, vous savez. Donc encore, NCache vous offre cette fonctionnalité. Du côté Java, vous avez des caches qui font cela. Côté .NET NCache est le seul. Ainsi, vous pouvez avoir un centre de données actif-passif ou actif-actif et les caches sont synchronisés. Encore une fois, vous ne pouvez pas avoir un cluster couvrant le WAN, car les performances meurent. Vous devez effectuer une réplication ou une synchronisation asynchrone sur le WAN, car lorsque vous avez deux centres de données, ils peuvent ne pas se trouver au même emplacement.

Devenir Clients est Ryanair qui est une grande compagnie aérienne ici et ils ont un centre de données à Dublin, Londres et Francfort. Donc, ils doivent s'assurer qu'ils peuvent se synchroniser. En cas de NCache Nous avons aussi Réplication WAN. Il existe également un concept de session multicentre de données dans lequel la session peut se déplacer d'un centre de données à l'autre. Mais, de toute façon, votre cache doit pouvoir prendre en charge plusieurs centres de données. Alors, assurez-vous que vous examinez cela.

NCache vs Redis

La plupart des gens de .NET connaissent Redis. NCache, je suis désolé, Microsoft les a sélectionnés comme leur choix pour Azure même si Redis vient d'un arrière-plan Linux. Je pense que la principale raison pour laquelle Microsoft les a choisis est qu'ils voulaient avoir plusieurs langues. Alors, Redis couvre beaucoup de langues. NCache est à peu près axé sur .NET. Nous avons aussi l'API Java mais NCache lui-même est axé sur .NET. Je veux faire un aperçu très rapide des deux juste pour que vous puissiez voir ce que cela signifie et ensuite vous pouvez venir sur notre site Web et en fait il y a comme un véritable Comparaison. Vous pouvez faire une comparaison des fonctionnalités ici. Et, ensuite, vous pouvez également télécharger ceci. Alors, jetez un oeil à ça. C'est basé sur leur documentation et la nôtre. Donc, ce n'est rien mais… il n'y a pas de tournure là-dedans.

NCache est également open source, tout comme Redis. En cas de NCache vous avez le … vous pouvez venir sur notre site Web et vous pouvez download soit l'édition Enterprise ou l'open source ou vous pouvez également aller sur GitHub, où se trouve NCache? Ici même sur GitHub et alors vous pouvez voir NCache ici aussi.

Ainsi, cette édition d'entreprise est entièrement prise en charge. En cas de Redis Microsoft a porté Redis de Linux à Windows. Ainsi, on pourrait penser que Microsoft utiliserait le port dans Azure, mais ce n'est pas le cas. Donc, le port qu'ils ont a beaucoup de problèmes. Beaucoup de clients nous en ont fait part.

Donc, si vous utilisez Redis dans Azure, ils utilisent la version Linux, c'est stable, il n'y a pas de problème, mais vous perdez toutes les fonctionnalités dont nous venons de parler. Si vous souhaitez effectuer un support sur site, NCache vous donnera soit l'open source est entièrement gratuit, l'entreprise est quelque chose que vous obtenez plus de fonctionnalités que vous ne payez pour le support également. Si vous voulez sur place avec Redis, les seules options que vous avez sont d'utiliser la version Linux de Redis laboratoires. Ils ont aussi maintenant ceci dans docker. Ainsi, vous pouvez l'exécuter techniquement sur Windows mais toujours l'environnement Linux pour eux. Le sur site de Windows provient de Microsoft, qui, comme je l'ai dit, est instable et sans support.

En azur Redis vous donne un modèle de service de cache, NCache vous donne un modèle de machine virtuelle. Le modèle VM vous donne beaucoup plus de contrôle. Tout ce dont nous venons de parler de lecture, d'écriture, de chargeur de cache, de synchronisation de base de données, vous obtenez tout ce contrôle et il n'y a qu'une API client.

C'est juste un aperçu rapide des deux. Je voulais en quelque sorte mentionner. Fondamentalement, NCache est le plus ancien cache de l'espace .NET. Nous avons des tonnes et des tonnes de clients qui utilisent NCache. Beaucoup d'entre eux sont également au Royaume-Uni. Vous savez, le Royaume-Uni est notre deuxième plus grand marché et si vous avez une application .NET, j'espère que vous préférez que toute la pile soit .NET. NCache vous donne cette pile .NET, Redis ne le fait pas.

Des questions avant que je conclue cet exposé ? Mais alors vous exposez vous-même le partitionnement. Parce que, dans une base de données relationnelle, vous devez ensuite programmer l'application de manière à ce que les données résident dans l'une ou l'autre. Je veux dire que tout le concept de No SQL est qu'ils font le sharding pour vous parce que tout est basé sur la clé. Dans un relationnel, vous avez beaucoup plus de complexités et jusqu'à présent, aucune des bases de données relationnelles n'a été en mesure de résoudre le problème d'évolutivité. Ils ont essayé très fort et ils ont énormément amélioré leurs performances. Il y a beaucoup d'options en mémoire, donc ils ont aussi des bases de données en mémoire et ils font beaucoup de tables en mémoire et d'autres choses. Ainsi, les performances se sont considérablement améliorées, mais les performances ne sont pas le problème ici. Vous savez, c'est le problème, c'est l'évolutivité. Pouvez-vous gérer cette charge et jusqu'à présent, ils ne le peuvent pas.

Donc, la raison pour laquelle nous avons l'indexation est que vous pouvez effectuer une recherche sur ces attributs. Ainsi, vous pouvez faire une instruction SQL et rechercher les attributs de l'objet sur lequel vous avez été indexé.

Donc, ce que nous faisons, c'est que nous ne vous permettons pas d'effectuer une recherche à moins que l'index ne soit créé. Donc, si vous faites une recherche NCache lancera une exception indiquant que cet attribut n'a pas été indexé. Donc, un peu d'une manière plus douloureuse, oui. Mais, ce que nous disons à nos clients, c'est que, peu importe ce que vous essayez de rechercher, vous devez créer un index. Et contrairement à une base de données où tout est SQL, ici tout ne passe pas par le SQL. Encore une fois, vous faites beaucoup de choses uniquement via l'API, puis certaines choses via SQL.

Tu veux dire pour le nom du cache ? Il existe une convention selon laquelle la clé doit contenir les informations de type, puis en fonction de certains, disons, s'il s'agit d'un objet individuel et du type et soit la valeur de la clé primaire, soit le nom de l'attribut de la clé primaire, puis la valeur, c'est le chose commune et ensuite si vous enregistrez l'ensemble de la collection, disons que vous enregistrez toutes les autres commandes pour le client et que vous voudrez peut-être le récupérer en fonction du client, la clé peut être le client, l'ID client, mes commandes ou quelque chose comme ça, tu sais. Ainsi, les clés doivent être significatives en fonction de la manière dont vous souhaitez récupérer les données.

Oui, ce sont toutes des options que vous pouvez choisir. Si vous regardez ma vidéo sur la gestion des données relationnelles, je passe en revue toutes ces options. Et, encore une fois avec la mise en cache, disons que vous avez une relation plusieurs à plusieurs dans la base de données. Il n'y a pas beaucoup à beaucoup au niveau de l'application. Dans l'application, vous vous approchez de ce côté ou de ce côté. C'est toujours un à plusieurs. Donc, ce sont des choses comme ça qui changent soudainement la perspective.

Vous n'essayez pas de recréer toute la base de données en mémoire. Pouvez-vous récapituler les avantages de l'utilisation d'un cache distribué ? Vous avez dit que c'était l'évolutivité. Y en a-t-il d'autres ? Je pense que l'avantage le plus important est l'évolutivité. L'avantage secondaire est la performance et encore une fois pour les cas d'utilisation, pour les cas d'utilisation spécifiques à ASP.NET, les sessions, il y a un énorme avantage. Car, les alternatives à un cache distribué sont toutes très lentes ou non évolutives. Donc, si vous faites un In-Proc, ce n'est pas évolutif. Parce que vous devez suivre le même processus à chaque fois.

J'enregistre également ceci et je pense qu'il en va de même pour le SDD Conf. Nous aurons cette discussion sur YouTube et si vous venez sur notre stand et laissez-nous vous scanner, nous pourrons vous envoyer par e-mail le lien vers la discussion et vous pourrez ensuite le partager avec vos collègues. Merci beaucoup les gars pour votre patience.

Que faire ensuite?

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