Camp de codes de Boston 27

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

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

Vos applications .NET peuvent rencontrer des goulots d'étranglement de base de données ou de stockage en raison de la croissance de la charge des transactions. Découvrez comment supprimer les goulots d'étranglement et faire évoluer vos applications .NET à l'aide de la mise en cache distribuée. 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é

Je m'appelle Iqbal Khan. Je suis un évangéliste de la technologie à Alachisoft. Nous sommes une société de logiciels basée dans la baie de San Francisco. Je suis personnellement basé à Tampa, mais nous avons ce produit appelé NCache. C'est un cache distribué .NET. Aujourd'hui, je vais parler de la façon dont vous pouvez faire évoluer les applications .NET avec la mise en cache distribuée. Ce n'est pas une discussion sur NCache, il s'agit du problème d'évolutivité et de la manière dont vous pouvez le résoudre avec la mise en cache distribuée. Que devrais tu faire? Comment devriez-vous l'utiliser? Quelles sont certaines des meilleures pratiques ? Si vous avez des questions, n'hésitez pas à m'arrêter. Ainsi, nous pouvons avoir une discussion plus interactive. Laissez-moi commencer.

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

Alors, éliminons quelques définitions. Le premier est l'évolutivité. L'évolutivité n'est pas la performance. Vous pouvez avoir une application qui fonctionne très bien avec cinq utilisateurs, mais elle n'est évolutive que si elle fonctionne de la même manière avec 5,000 50,000, 500,000 5 ou XNUMX XNUMX utilisateurs. Ainsi, l'évolutivité est une performance vraiment élevée sous des charges de pointe. Si votre application ne fonctionne pas bien avec XNUMX utilisateurs, vous devez assister à d'autres discussions.

Évolutivité linéaire et évolutivité non linéaire

L'évolutivité linéaire relève davantage du concept de déploiement d'applications. Lorsque vous déployez votre application, si vous pouvez ajouter plus de serveurs au déploiement et en ajoutant plus de serveurs si vous pouvez augmenter la capacité de transaction de manière linéaire, alors votre architecture d'application est linéairement évolutive, sinon elle est non linéaire.

Cela signifie qu'après un certain nombre de serveurs, l'ajout de plus de serveurs aggrave les choses, cela signifie qu'il y a des goulots d'étranglement quelque part dans votre application qui ne sont pas résolus simplement en ajoutant plus de serveurs. Vous ne voulez certainement pas d'évolutivité non linéaire et vous voulez certainement une évolutivité linéaire dans votre application.

Quels types d'applications ont besoin d'évolutivité ?

Quels types d'applications ont besoin d'évolutivité ? Ce sont des applications ASP.NET. Ce sont des services Web. Ce sont des back-end IOT qui sont encore une fois principalement des services Web. Ce sont des applications de traitement de données volumineuses, qui ne sont pas si courantes dans .NET, de plus en plus d'entre elles sont réalisées en Java, mais ce sont néanmoins des applications qui ont également besoin d'évolutivité et de toute autre application serveur. Par exemple, vous pouvez avoir, vous travaillez peut-être pour une grande banque qui compte des millions de clients et eux, vous savez, les clients appellent pour faire des changements d'adresse ou peut-être veulent-ils qu'une nouvelle carte soit émise ou peut-être qu'ils transfèrent des fonds d'une compte à l'autre et toutes ces transactions doivent être traitées dans un délai prédéterminé à des fins de conformité. Ainsi, vous devez à nouveau gérer des millions de demandes dans un laps de temps que vous ne pourrez peut-être pas faire à partir d'un seul ordinateur. Donc, vous devez être capable d'évoluer même dans ce cas. Donc, si vous avez l'une de ces applications qui ont besoin d'évolutivité, alors c'est une bonne conversation, à laquelle vous êtes venu.

Le problème de l'évolutivité

Alors, définissons également le problème d'évolutivité. Quel est le problème d'évolutivité ? Eh bien, le niveau d'application évolue de manière linéaire. Vous pouvez avoir une application Web ASP.NET ou des services Web. Vous aurez un équilibreur de charge devant qui acheminera le trafic de manière uniforme vers tous les serveurs. Vous pouvez ajouter plus de serveurs, sans problème. Tout fonctionne parfaitement bien. Je parlais plus tôt à quelqu'un du fait que la base de données devenait un goulot d'étranglement et ils n'étaient pas d'accord avec moi. Donc, je pense que c'est une bonne occasion d'avoir cette discussion.

Ainsi, la base de données elle-même fonctionne très rapidement. Il n'y a aucun problème de performances. Les bases de données sont très intelligentes, elles font beaucoup de mise en cache en mémoire sur leur propre serveur, mais l'évolutivité est quelque chose qu'elles ne peuvent pas atteindre de par leur conception car vous pouvez ajouter, par exemple, vous pouvez ajouter 10, 20, 30, 40, 50 serveurs à ce étage. Nous avons des clients avec 50 serveurs ou plus dans leur niveau d'application parce qu'ils ont tellement d'utilisateurs. Imaginez que vous êtes une grande banque ou une compagnie aérienne. Vous avez des millions de personnes qui viennent sur votre site Web. Vous avez fait cette promotion majeure pour un billet pour Hawaï ou quelque chose comme ça. Tout le monde va venir, ils feront la recherche de vols, ils voudront acheter les billets. Vous pouvez ajouter plus de serveurs ici sans problème. La base de données fonctionnait très rapidement et le logiciel est excellent, mais de par sa conception, la base de données n'est pas une base de données distribuée. Il est conservé en un seul endroit. Vous pouvez peut-être avoir un cluster de deux serveurs, actif-actif, actif-passif, mais ils sont plus pour la fiabilité que pour l'évolutivité, vraiment.

Donc, vous ne pouvez pas vraiment avoir 10 serveurs ici, à moins qu'il ne s'agisse d'un NoSQL database, Ensuite vous pouvez. Mais, pour une base de données relationnelle, il peut s'agir de SQL Server, Oracle, Db2, MySQL, ils sont ultra-rapides. Ils peuvent même faire beaucoup de traitement en mémoire, mais ils deviendront le goulot d'étranglement car vous devrez évoluer de plus en plus. Et fondamentalement, lorsque vous avez mille utilisateurs simultanés ou plus, vous commencez à remarquer des problèmes de performances et à mesure que vous augmentez de 1,000 5,000 à 5,000 10,000, 1000 5,000 à 10,000 15,000, c'est là que vous commencez à en voir plus. Donc, ce que nous avons vu, vous savez, lorsque vous avez XNUMX XNUMX utilisateurs, vous pouvez ou non utiliser la mise en cache, mais à mesure que vous passez à XNUMX XNUMX, XNUMX XNUMX, XNUMX XNUMX utilisateurs, vous ressentez définitivement la douleur et vous vous retrouvez avec ces évolutivité les goulots d'étranglement.

Désormais, les bases de données relationnelles ou les anciennes bases de données mainframe ont ce problème. C'est une des raisons NoSQL databases mouvement a commencé était à cause de cela. Cependant, il a aussi d'autres avantages et nous avons un produit. Permettez-moi d'arriver rapidement à des fins de référence. Donc, nous avons un produit de mise en cache mais nous avons aussi un NoSQL base de données documentaire. Tout comme la base de données de documents, il s'agit d'une base de données open source.

Alors, NoSQL database n'a certainement pas les problèmes d'évolutivité. Mais, ce n'est pas toujours la réponse. Pourquoi donc? Car pour que ce soit une réponse, un NoSQL database veut que vous y stockiez toutes les données. Ainsi, à moins que vous ne stockiez vos données dans un NoSQL database ce qui signifie que vous arrêtez d'utiliser la base de données relationnelle pour au moins cette partie des données, cela ne résoudra pas votre problème. Ainsi, dans de nombreux cas, vous pouvez déplacer certaines des données, une grande partie des données dans un NoSQL database et c'est ce qui motive le NoSQL mouvement. Mais, les bases de données relationnelles, les données mainframe héritées, elles sont là pour rester. Ce n'est pas quelque chose que vous pouvez simplement souhaiter pour des raisons techniques et commerciales. Ainsi, quels que soient les problèmes d'évolutivité que vous devez résoudre, vous devez les résoudre avec des bases de données relationnelles dans l'image. Voilà pourquoi NoSQL database n'est pas toujours la réponse.

La solution : cache distribué en mémoire

Et, la façon dont vous résolvez ce problème, c'est une nouvelle meilleure pratique qui a émergé au cours des cinq à dix dernières années environ, qui est le cache distribué en mémoire. Certaines personnes appellent également cette grille de données en mémoire. Microsoft avait l'habitude d'appeler la fabrique de données. Bien qu'ils ne cessent de changer leurs définitions. Mais il s'agit d'un magasin clé-valeur distribué en mémoire et c'est désormais une partie essentielle de votre architecture. Si vous voulez une application évolutive, vous devez programmer, vous devez développer vos applications avec un cache distribué à l'esprit. Ainsi, vous pouvez vous assurer que l'application ne deviendra jamais un goulot d'étranglement.

Qu'est-ce qu'un cache distribué ? Il s'agit essentiellement de deux ou plusieurs serveurs à faible coût. Ce ne sont pas des serveurs de base de données haut de gamme, ce sont des boîtiers de type serveur Web. Habituellement, une configuration à double processeur et 8 cœurs est assez typique. 16 Go de RAM, c'est à peu près la moyenne. Nous voyons que 16 à 32 concerts sont comme le sweet spot de la mémoire. Plus de 64 gig, nous ne recommandons même pas à nos clients. Nous disons ajouter une autre boîte au lieu de rendre cette boîte plus solide. Parce que, si vous ajoutez plus de 64 Go, une application .NET a ce truc appelé ramasse-miettes qui prend beaucoup de puissance de traitement. Ainsi, plus vous avez de mémoire, plus le processeur doit être rapide pour que le ramasse-miettes puisse collecter toute cette mémoire.

Il est donc préférable d'avoir plus de serveurs que d'avoir peu de serveurs vraiment haut de gamme. Minimum 2 bien sûr, car vous voulez de la fiabilité. Au cas où un serveur tomberait en panne, mais après ce rapport de 4 à 1 ou 5 à 1, vous auriez généralement, disons, 2, 3, 4 ou 5 serveurs dans le niveau application. Le plus courant que nous voyons se situe entre 4 et 10 et bien sûr il y a beaucoup de clients qui utilisent plus de 10 mais 4 et 10 est à peu près ce que nous considérons comme ce sweet spot. Et, pour cela, vous utilisez un cluster de 2 serveurs. Au fur et à mesure que vous grandissez de plus de 10 ou 12, vous ajoutez un troisième ou un quatrième et ainsi de suite. Et, parce qu'un cache distribué est un magasin de valeurs clés, il est distribué. Il réplique les données sur plusieurs serveurs de manière intelligente, de sorte que vous obtenez la fiabilité mais en même temps vous ne passez pas beaucoup de temps à répliquer. Par exemple, si chaque élément de données devait être répliqué sur tous les serveurs, cela représente beaucoup de traitement supplémentaire dont vous n'avez pas besoin. C'est donc ce type de réplication intelligente qu'il doit faire. Parfois, vous avez besoin d'avoir une réplication de cette manière, mais ce sont des cas spécialisés. Ainsi, un cache distribué lorsque vous l'avez en place, vous y accéderez environ 80% du temps. Toutes les lectures vont être effectuées à partir de celui-ci et toutes les mises à jour et certaines des lectures vont être effectuées sur la base de données ainsi que sur le cache. Ainsi, si vous pouvez piéger environ 80 % du trafic de votre base de données dans votre cache, votre base de données est soudainement très légère. Il n'a pas grand-chose à faire. Ainsi, quoi qu'il ait à faire, il le fera beaucoup plus rapidement. Ainsi, les performances s'amélioreront ainsi que l'évolutivité.

Ce cache de distribution en mémoire, que ce soit NCache, que ce soit Redis du côté .NET, du côté Java, il y a plus de joueurs, quel que soit le produit que vous choisissez, le cache distribué est à peu près une bonne pratique donnée maintenant. Vous devez intégrer cela dans votre architecture.

Des questions à ce sujet jusqu'à présent, avant de passer à autre chose ? Donc, oui, un cache logique peut s'étendre sur plusieurs serveurs. En cas de NCache vous pouvez avoir plusieurs caches sur les mêmes serveurs. Ainsi, chaque cache devient son propre conteneur à des fins d'isolation, mais n'importe quel cache peut couvrir les cinq serveurs. Quand je dis étendue, cela signifie que certaines données se trouvent sur un serveur, d'autres sur les autres, vous savez, et que la réplication en est une partie distincte qui peut ou non être effectuée en fonction de vos préférences. Mais, oui, tous les serveurs sont utilisés pour stocker ce cache et le cache doit être cohérent. Il doit être toujours correct ou vous pouvez dire qu'il doit être éventuellement correct mais assez proche d'être toujours correct. Quoi que vous stockiez dans le cache, si vous mettez à jour, peu importe où se trouvent les données, vous ne savez probablement même pas où se trouvent les données. Tout ce que vous savez, c'est que ce cluster contient mes données et chaque fois que je les récupère, je les ai peut-être stockées sur ce serveur et j'essaie de les lire ici immédiatement après et je devrais pouvoir obtenir la même copie. Si je peux le faire, cela devient un cache cohérent ou cohérent. Donc, autant d'intégrité des données pour les mises à jour qu'il garantit toujours.

C'est votre préférence et j'y reviendrai plus en détail en termes d'utilisation réelle du cache. Donc, une chose que vous devriez… Je veux dire que l'objectif principal jusqu'à présent est de vous convaincre que si vous voulez de l'évolutivité, vous devez l'avoir dans votre architecture.

Utilisations courantes du cache distribué

Donc, maintenant que nous avons, disons, nous sommes d'accord sur le fait que vous avez besoin d'un cache distribué, la première question qui vous vient à l'esprit est comment l'utilisez-vous ? Où l'utilisez-vous ? Qu'utilisez vous pour ça? Quelles données y sont conservées et tous les problèmes liés à ces données.

Mise en cache des données d'application

Il existe donc trois cas d'utilisation de haut niveau. Premièrement, la mise en cache des données d'application, dont je parlais tout à l'heure, c'est-à-dire que vous avez des données dans la base de données, vous les récupérez et vous les mettez en cache. Donc, dans la mise en cache des données d'application, l'objectif est… mais je viens de mentionner que vous ne voulez pas autant accéder à la base de données, vous voulez réduire le trafic de cette base de données afin que votre application évolue. Mais, les données existent maintenant à deux endroits. Il existe dans le cache et il existe dans la base de données. Ainsi, chaque fois que des données existent à deux endroits, quelle est la première préoccupation qui vous vient à l'esprit ? Synchronisation entre les deux. Alors, est-ce cohérent ? Parce que, si les données ne sont pas cohérentes, vous serez limité à l'utilisation du cache pour les données en lecture seule. En fait, la plupart des gens, quand vous leur demandez, pourquoi utilisez-vous un cache ? La réaction instinctive est une donnée en lecture seule. Vous savez, je ne me sens pas à l'aise d'utiliser le cache pour des données qui vont vraiment changer, vous savez, en temps réel ou au moment de l'exécution. Mais, si vous ne pouvez pas utiliser le cache pour les données transactionnelles que j'utilise le terme pour les données qui changent fréquemment, ces données représentent probablement 80 % à 90 % de vos données. Donc, cela signifie bien 80% à 90% du temps que vous ne pouvez même pas utiliser le cache et si vous ne pouvez même pas utiliser le cache, cela devient comme un NoSQL database. Ce n'est pas toujours la réponse, tu sais. Et, vous voulez que ce soit la réponse, donc vous savez, donc un bon cache distribué doit vous donner l'assurance que tout ce que vous cachez sera cohérent avec la base de données. Si ce n'est pas le cas, ce cache n'est pas le bon cache pour vous. Donc, c'est la première chose, c'est le premier cas d'utilisation.

Mise en cache spécifique à ASP.NET

Le deuxième cas d'utilisation est, si vous avez des applications ASP.NET.

1. Mise en cache de session ASP.NET

   Vous pouvez stocker vos sessions dans le cache. Vous savez, les sessions sont quelque chose que presque toutes les applications ASP.NET ont. Ils sont soit conservés en mode In-Proc, soit en mode serveur SQL. Le serveur SQL n'est pas le bon endroit pour conserver des sessions pour deux raisons, l'une bien sûr, cette première raison qui est que plus vous conservez de données dans la base de données, plus vous avez un goulot d'étranglement d'évolutivité. La seconde est que les sessions sont conservées sous forme de blobs et que les bases de données relationnelles n'ont pas vraiment été conçues pour les blobs. Ils ont été conçus pour des données plus structurées que vous pouvez indexer et rechercher. Considérant que, un cache distribué la valeur clé, la valeur est toujours un blob. Ainsi, ces sessions s'intègrent très bien avec un cache distribué.

2. ASP.NET View State Cache haute performance

   Le deuxième type de données ASP.NET est, si vous n'utilisez pas le framework MVC que beaucoup d'applications ASP.NET existantes ne sont toujours pas, alors vous avez cette chose appelée un Afficher l'état et, un état d'affichage n'est rien d'autre qu'une chaîne cryptée qui est conservée et envoyée du serveur Web au navigateur, pour revenir ensuite au serveur Web et cela peut devenir assez volumineux. Cela peut facilement atteindre des centaines de kilo-octets et consomme donc beaucoup de bande passante supplémentaire. Il faut plus de temps pour voyager. Lorsque vous multipliez cela par des millions de requêtes que vous traitez, votre coût de consommation de bande passante augmente également un peu. C'est donc un cas idéal pour mettre en cache côté serveur et n'envoyer qu'une petite clé. Ainsi, la prochaine fois que l'état d'affichage est censé être utilisé, la clé est renvoyée et l'état d'affichage est extrait du cache.

3. Mise en cache de sortie ASP.NET

   Le troisième exemple de mise en cache spécifique à ASP.NET est la sortie de page. Il fait partie de l'ASP.NET framework s'appelle un cache de sortie qui vous permet de mettre en cache la sortie d'une page si elle ne change pas et vous pouvez utiliser un cache distribué pour la mettre en cache au lieu de la conserver séparément sur chaque serveur Web, ce qui devient alors plusieurs copies devant être synchronisées. Ainsi, ces trois cas d'utilisation ou trois exemples concernent le cas d'utilisation de la mise en cache spécifique à ASP.NET.

Maintenant, contrairement à la mise en cache des données d'application ici, la nature du problème est très différente. Ici, les données n'existent que dans le cache. Je veux dire que toutes ces données ne sont plus stockées nulle part ailleurs. Donc, il n'est pas stocké dans la base de données. Ainsi, vous n'avez plus ce problème de synchronisation entre la base de données et le cache. Mais, vous avez un autre problème maintenant. Si vous avez un cache en mémoire, c'est le seul magasin de vos données. Quelle est la plus grande préoccupation ? Qu'est-ce qui pourrait mal tourner avec ça ? Il disparaît. Oui, ça peut disparaître. Si un serveur tombe en panne et que les serveurs tombent en panne, y compris Windows. Ainsi, lorsqu'un serveur tombe en panne, vous perdez des données et en particulier certaines des, je veux dire pour l'état de la vue et l'état de la session, je veux dire le cache de sortie, même si vous le perdez, vous réexécutez simplement la page mais ces deux. Par exemple, Session State, vous venez d'avoir ce client de la compagnie aérienne qui a fait toutes sortes de recherches de vols et il est sur le point de passer la commande et le serveur plante et sa session est perdue, il doit se connecter réellement. Vous savez, vous risquez de perdre ce client. Donc, vous ne voulez certainement pas perdre. Donc, vous ne voulez pas que ces données disparaissent. Donc, dans ce domaine, la synchronisation était le gros problème ici, c'est la fiabilité.

Ainsi, la fiabilité est gérée par la réplication. Tout cache qui ne fait pas de réplication, vous ne pouvez pas y stocker de sessions. La bonne chose à propos de la mise en cache spécifique à ASP.NET est qu'aucune programmation n'est nécessaire. Il s'intègre parfaitement dans l'ASP.NET framework. Malheureusement, vous devez faire de la programmation pour la mise en cache des données de l'application. Du côté de Java, vous n'êtes pas obligé de le faire ou, en fait, ce sont davantage de normes qui émergent. Il existe un standard appelé JCache qui, si vous le programmez, n'importe lequel des caches tiers s'y connecte et vous n'avez pas à vous en tenir à un seul cache. Plus encore, si vous utilisez un moteur de mappage OR comme Hibernate ou dans le cas de .NET NHibernate, vous pouvez brancher un cache. Entity Framework jusqu'au noyau EF ou avant le noyau EF, il n'autorisait pas un cache tiers à se connecter automatiquement. Bien que nous ayons implémenté un fournisseur ADO .NET pour EF6. C'était plus de la mise en cache au niveau ADO.NET, donc, vous mettiez en cache des requêtes, ce qui est mieux que de ne pas mettre en cache, mais ce n'est pas aussi puissant que la mise en cache au niveau de l'entité où vous pouvez également suivre les mises à jour.

Entity Framework ou mise en cache EFCore

Le nouveau EF7 ou EF Core a une architecture beaucoup plus flexible. Il vous permet de brancher un cache tiers. Ainsi, lorsque vous passerez à EF Core, vous pourrez brancher un cache distribué comme NCache sans aucune programmation. Donc, vous faisiez juste votre programmation standard et vos plug-ins de cache. Mais à part ça, vous devez le faire. Mais, même dans ce plugin, vous ne pouvez pas utiliser toutes les fonctionnalités dont je vais parler. Dans ASP.NET spécifique au moins, c'est la victoire la plus facile. Lorsque vous apportez un cache, puisqu'il n'y a pas de programmation impliquée, il vous suffit de faire quelques tests de santé de base et votre application voit soudainement une augmentation majeure des performances et de l'évolutivité.

Des questions, avant que je continue ? Au niveau de l'application ou au niveau du cache ? En termes de cache. Un cache est comme une base de données. Tout comme vous appelez la base de données et que vous avez ensuite la gestion des exceptions. Si quelque chose ne va pas dans le cache, le cache lèvera une exception, vous l'attraperez et vous devrez alors prendre les mesures appropriées. Cependant, contrairement à une base de données où une mise à jour peut échouer sur l'intégrité des données car vous pouvez avoir des contraintes de vérification ou d'autres contraintes d'intégrité référentielle, aucune de ces contraintes n'existe dans le cache. Un cache acceptera toutes les données que vous lui donnerez. La seule fois où une mise à jour ou une opération de cache échouera, c'est quand quelque chose ne va pas avec le système. Ouais, quelque chose de catastrophique. Ainsi, vous n'avez pas à vous soucier du fait que le cache ne mette pas à jour vos données lors d'une opération normale.

Sécurité

Cela dépend donc du produit de cache que vous utilisez. NCache a toutes ces fonctionnalités intégrées. Vous pouvez activer sécurité, de sorte que chaque utilisateur qui utilise le cache doit être authentifié/autorisé. Il a également beaucoup d'autres sécurités comme le cryptage intégré. Ainsi, si l'application que vous avez est très sensible, vous pouvez crypter les données avant qu'elles ne soient mises en cache et tout cela est fait automatiquement par le cache sans que vous fassiez d'effort supplémentaire. Parce que, comme je l'ai dit, l'un des plus grands utilisateurs de NCache est le secteur des services financiers. Parce qu'ils ont beaucoup de services bancaires en ligne. Beaucoup d'affaires électroniques s'y déroulent et leurs données sont très sensibles. Donc, cela dépend du produit que vous choisissez.

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

Le troisième cas d'utilisation est partage de données d'exécution via des événements. Tout comme vous utilisez des files d'attente de messages, MSMQ en est un, RabbitMQ en est un autre. Ils ont beaucoup plus de fonctionnalités en termes de messagerie pour un environnement distribué dans plusieurs emplacements. Si votre application est dans un seul centre de données et que vous devez faire Pub / Sous-marin type de partage de données, un cache distribué est beaucoup plus évolutif que toute autre file d'attente de messages. Il n'a peut-être pas autant de fonctionnalités qu'eux, mais vous n'aurez peut-être pas besoin de toutes ces fonctionnalités. Mais, c'est beaucoup plus rapide et beaucoup plus évolutif et c'est vrai pour NCache cela est également vrai pour les autres caches distribués qui fournissent cette fonctionnalité. Parce que, encore une fois, tout ce cluster devient un bus de messages. Donc, vous savez, si vous faites beaucoup d'activité, les événements se propagent très rapidement car il y a plus d'un serveur pour gérer ces événements et vous pouvez ajouter plus de serveurs à mesure que la charge augmente.

Donc, beaucoup de ces applications serveur ont de nos jours des flux de travail intégrés, vous savez. Où une application fait quelque chose et une fois que c'est fait, les autres applications font autre chose. C'est donc là qu'intervient le Pub/Sub ou le concept de producteur/consommateur. Il y a des fonctionnalités de notification d'événement. NCache a cette fonctionnalité appelée requête continue qui est une fonctionnalité très puissante, qui existe également du côté Java, mais aucun des autres caches .NET ne l'a.

Ainsi, le partage de données d'exécution est également quelque chose que vous devriez fortement envisager de faire via un cache distribué, ce qui vous simplifie la vie au lieu d'incorporer plusieurs autres produits. Même ici, la nature du problème est généralement la même que celle-ci, à savoir que les données que vous essayez de partager n'existent que dans le cache. Il peut exister dans la base de données mais sous une forme différente, parce que vous l'avez construit, vous l'avez produit, vous savez, vous avez rassemblé beaucoup de données et sous cette forme finale ou intermédiaire vous partagez avec quelqu'un autre. Donc, si vous perdez ces données, vous devez tout refaire. Donc, bien que ce ne soit pas aussi mauvais que les sessions, cela a encore beaucoup d'implications sur les performances. Donc, vous ne voulez pas perdre ces données. Donc, là encore le souci est de s'assurer que le cache est fiable.

Ce sont donc les trois cas d'utilisation de haut niveau fournis par un cache distribué. Comme je l'ai dit, un cache distribué est essentiellement une base de données en mémoire distribuée, un magasin de valeurs clés.

Démonstration pratique

Avant d'entrer dans les détails sur la façon dont vous pouvez faire cela, je vais juste vous montrer rapidement à quoi ressemble un cache distribué ? Ainsi, vous pouvez voir comment ce sera si vous deviez l'utiliser dans votre application. Je vais bien sûr utiliser NCache comme exemple. NCache est un cache open source. Ainsi, vous pouvez l'utiliser sans l'acheter si vous n'avez pas l'argent ou si vous n'avez pas le budget. Si votre projet est plus sensible aux affaires, achetez bien sûr l'édition Enterprise. J'ai donc configuré des machines virtuelles dans Azure que je vais utiliser. Je vais utiliser un cluster de cache à 2 nœuds, donc j'ai 'demo1' et 'demo2' comme serveurs de cache et 'demo-client' est ma boîte de serveur d'applications. Donc, c'est votre boîte de serveur ASP.NET. Ainsi, un NCache client est vraiment votre serveur d'application.

Je suis connecté à, disons, un client de démonstration. Donc, la première chose que je vais faire est de créer un nouveau cache. Donc, je vais utiliser cet outil appelé NCache manager. C'est donc un outil de style explorateur. Je vais juste dire créer un nouveau cache en cluster. Dans NCache tous les caches sont nommés.

Je choisirai une stratégie de stockage ou de réplication.

Je vais juste aller de l'avant et spécifier mon premier serveur de cache ici. Précisez mon deuxième.

Je vais juste continuer et je dirai ici combien de mémoire mon serveur devrait consommer. Dans votre cas, ce sera beaucoup plus. Je viens de spécifier un concert.

Ainsi, si cette mémoire est consommée, vous pouvez spécifier des politiques d'éviction. Donc, disons, au moins une politique récemment utilisée signifie évincer certains des éléments les moins récemment utilisés.

Donc, je viens de recevoir ça. Je vais continuer et ajouter un nœud client, qui est ma boîte et je vais simplement continuer et démarrer le cache.

Alors, sur quelle machine l'installez-vous ? C'est un azur. Donc, ces deux sont ma démo1 et ma démo2. Donc, je suis en fait connecté à cette boîte et j'utilise NCache manager ici et je crée un cluster de demo1 et demo2 ici.

Donc, maintenant que j'ai commencé, je peux continuer et voir les statistiques. Donc, je peux voir une activité de compteur PerfMon. Je peux aussi lancer cet outil de suivi de NCache cela me permet de voir les choses, puis je vais exécuter rapidement cet outil appelé outil de test de stress. Il vous permet de tester rapidement le cache dans votre environnement pour voir comment il va fonctionner.

Donc, cet outil est comme votre application. Vous pouvez l'utiliser pour simuler différents types de charge, différents types d'opérations. Par exemple, je fais environ 600 requêtes par seconde ici et environ 700 à 800 chacune.

Permettez-moi d'exécuter une autre instance de l'outil de test de stress, ici. Ainsi, vous verrez que cette charge doublera tout simplement. Ainsi, au fur et à mesure que je continue d'ajouter de plus en plus d'instances de l'application, la charge sur le cache augmentera jusqu'à un point où ces deux serveurs vont atteindre leur maximum, puis vous n'en ajouterez qu'un troisième.

Et, vous pouvez faire tout cela au moment de l'exécution sans rien arrêter. Alors, tout à coup votre infrastructure… Pensez-y, si votre base de données commençait à s'étouffer, pouvez-vous vraiment ajouter un autre serveur et sortir de ce problème ? Vous ne pouvez pas. Parce que, de par la nature de cela et qu'il ne s'agit pas d'une base de données spécifique, ce sont toutes des bases de données relationnelles. Mais, dans le cas d'un cache, ajoutez simplement un autre serveur et maintenant le cache fonctionne.

Voici donc à quoi ressemble une cache. C'est aussi simple à utiliser et à configurer que vous pouvez le voir. Je veux dire, la seule chose que je n'ai pas faite, c'est de l'installer. Ce qui n'était qu'un programme d'installation de Windows qui, vous savez, ne prend pas beaucoup de temps. Donc, à part ça, pour comprendre un cluster à deux nœuds, il m'a fallu environ cinq minutes.

Et, maintenant que j'ai tout configuré, je peux en fait spécifier ce nom de cache sur les applications exécutées sur cette boîte. Donc, si j'avais plus de boîtes client, je continuerais à les ajouter ici.

Dans votre cas, pour ces deux, vous en avez probablement 8 ou 10. Donc, vous les ajouteriez tous, puis une fois que vous avez fait ce cache, le cache de démonstration est disponible là-bas, puis vous allez simplement mettre à jour votre truc.

Donc, maintenant que nous savons à quoi ressemble une cache, permettez-moi de passer rapidement au sujet suivant. Donc, comme je l'ai dit, la façon la plus simple d'utiliser le cache est de l'utiliser pour les sessions. Comment je fais ça? Donc, j'ai l'application ASP.NET. J'irais et j'ouvrirais le web.config et je ferai deux choses. Je vais d'abord ajouter l'assemblage.

...
<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=1448e8d1123e9096" />
    </assemblies>
</compilation>
...

En cas de NCache c'est l'assemblage qui implémente le Fournisseur d'état de session ASP.NET. Alors, c'est comme ça NCache se branche sur l'ASP.NET framework. Tout cache tiers devrait le faire. Donc, vous ajoutez simplement cette ligne dans les assemblages et deuxièmement, vous allez simplement à la balise sessions et vous spécifiez cela spécifique au cache distribué que vous choisissez.

...
<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>
...

En cas de NCache vous venez de copier ceci et il y a quelques choses dont vous devez vous assurer. Vous devez d'abord vous assurer que le mode est "personnalisé". Donc, parce que personnalisé signifie stockage tiers. Et, ensuite, 'timeout', assurez-vous que c'est ce que vous voulez qu'il soit et tout le reste que vous pouvez conserver par défaut et spécifiez simplement un nom de cache ici, juste là. Donc, ce devrait être juste 'demoCache'. Dès que vous apportez cette modification et que vous exécutez à nouveau l'application ou dès que vous l'enregistrez, vous savez que le processus de travail ASP.NET est recyclé. ça va ramasser NCache configuration et tout à coup vous verrez que chaque session sera un compte. Donc, tous ceux, vous savez, qui comptent que nous voyions dans NCache dans ce PerfMon ici.

Donc, ce serait 540 sessions stockées et bien sûr, à mesure que vous ajoutez plus de sessions, cela va augmenter le nombre.

Ainsi, avec ce petit effort, vous pouvez immédiatement donner un coup de pouce majeur à votre application. Il en va de même avec l'état d'affichage. Avec le cache de sortie, il y a un peu plus de configuration impliquée, mais l'état d'affichage et la session, vous pouvez les faire en quelques minutes, sans aucun effort et du coup les applications utilisent un énorme coup de pouce.

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

Alors maintenant, passons à la mise en cache des données d'application, qui est l'essentiel de cette discussion. Ainsi, si vous devez utiliser le cache pour la mise en cache des données d'application, vous devez programmer son API. C'est parce qu'il n'y a pas encore d'API standard. Donc, ce que nous avons fait, c'est que nous avons choisi notre API pour qu'elle soit aussi proche de l'objet de cache ASP.NET.

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");

NCache existe depuis 2005, donc ça fait presque 11 ans et demi maintenant. Mais, il ressemble beaucoup à l'objet de cache ASP.NET. Il y a quelques éléments supplémentaires, alors disons que vous vous connectez au cache par un nom de cache. Vous obtenez un handle de cache. Ensuite, ce handle de cache est ce que vous utilisez pour faire cache.Obtenir. Get contient Add, Insert, Remove et il en existe une version Async, ce qui signifie que n'attendez pas que le cache soit mis à jour et, bien sûr, lorsque vous appelez Async, vous pouvez spécifier un rappel. Ainsi, votre rappel est appelé en cas de problème.

Laissez-moi vous montrer à quoi cela ressemble dans un visuel, comme dans une application appropriée. Donc, si vous deviez avoir un… Il s'agit d'une application console standard. Vous auriez besoin de référencer l'assemblage de votre cache. En cas de NCache, il n'y a que ces deux assemblages, Alachisoft.NCache.Durée, Alachisoft.NCache.La toile. Vous spécifiez les mêmes espaces de noms ici, puis au début de l'application qui, dans le cas d'ASP.NET, ce sera probablement dans le global.asax dans la méthode Init ou la méthode de démarrage de l'application. Mais, disons ici, vous vous connectez au cache en fonction du nom du cache et du nom du cache, comme vous le savez, c'est comme ça, du moins dans NCache c'est ainsi que le cache est reconnu et que vous obtenez un descripteur de cache. Ensuite tu crées tes objets et tu fais un cache.Ajouter. Vous spécifiez la clé. Ce n'est pas une bonne clé. il devrait avoir plus d'unicité en elle. Mais, disons, que vous spécifiez la clé et voici votre valeur l'objet réel.

public static void Main(string[] args)
{
    try
    {
        //Initialize cache via 'initializeCache' using 'Cache Name'
        //to be initialized. 
        Cache cache = NCache.InitializeCache("demoCache");
        cache.Clear();

        //Another method to add item(s) to cache is via CacheItem  object
        Customer customer = new Customer();
        customer.Name = "David Johnes";
        customer.Age = 23;
        customer.Gender = "Male";
        customer.ContactNo = "12345-6789";
        customer.Address = "Silicon Valley, Santa Clara, California";

        DateTime calendar = new DateTime();
        calendar.AddMinutes(1);

        //Adding item with an absolute expiration of 1 minute
        cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
        Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
        ...

Expiration des données

Et, dans ce cas NCache fait cette chose appelée expiration absolue. Alors laissez-moi, en venir à cela. Nous avons donc parlé de la mise en cache des données d'application en voulant garder le cache à jour. Donc, si vous ne pouvez pas garder le cache à jour, vous forcez à l'utiliser pour les données en lecture seule. Alors, comment gardez-vous le cache à jour ? Il y a plus d'une façon. La première méthode, qui correspond à peu près à tous les caches, s'appelle l'expiration absolue. C'est ici que vous spécifiez combien de temps vous souhaitez conserver cela dans le cache. Donc, vous dites au cache que je ne me sens à l'aise que pendant une minute que je ne pense pas que ces données devraient rester dans le cache plus d'une minute parce que, je pense que si elles étaient conservées dans le cache plus d'une minute, quelqu'un d'autre va le mettre à jour et le cache deviendra obsolète. Donc, vous faites une supposition éclairée sur la durée pendant laquelle le cache doit contenir vos données. Et, bien sûr, toutes les données que vous mettez en cache doivent avoir une sorte d'expiration. À peu près… Je veux dire certaines données dont vous pouvez à peu près supposer qu'elles ne seront jamais expirées, donc vous pouvez dire qu'il n'y a pas d'expiration. Mais, 99 % des données ou quelque chose de plus de 90 % des données doivent avoir des expirations. Ainsi, l'expiration absolue est ce qui maintient le cache à jour sur la base d'une supposition éclairée.

Il y a une autre expiration appelée expiration glissante. Son objectif est totalement différent. Bien qu'il utilise le même nom d'expiration d'appel. L'expiration glissante dit expirer si personne ne touche cet objet pendant aussi longtemps, disons pendant 10 minutes, pendant 20 minutes. Et, ceci est utilisé pour plus de données transitoires. Donc, cela est utilisé pour plus de données spécifiques à ASP.NET, où vous ne faites que nettoyer. Vous dites, vous savez, que personne d'autre n'en a plus besoin. Donc, si un utilisateur n'utilise plus la session pendant 20 minutes, vous dites que cet utilisateur s'est déconnecté de toute façon, alors supprimez la session. Donc, c'est une expiration de nettoyage. Puis expiration absolue qui est un but de synchronisation. Le but de l'expiration absolue est la synchronisation. Et encore une fois, vous pouvez le faire, vous pouvez expirer les choses en 10 secondes, 15 secondes, 1 minute, 5 minutes, 10 minutes. L'expiration la plus courante sera probablement d'une minute ou deux minutes.

Mais il y a un problème avec l'expiration. C'est que vous faites une supposition. Vous dites que je pense que c'est normal de le mettre en cache aussi longtemps. Mais, il n'y a aucune garantie. Dans certains cas, il peut y en avoir, mais dans de nombreux cas, il n'y a aucune garantie. Et s'il y a une autre application qui accède également à la même base de données et qu'elle va mettre à jour ces données. Certains scripts peuvent être en cours d'exécution. Donc, chaque fois que quelque chose comme ça se produit, les expirations ne sont pas suffisantes. Et c'est là que vous avez besoin du cache pour pouvoir surveiller les changements dans la base de données.

Si vous pouvez spécifier une association entre tout ce qui se trouve dans le cache et les données correspondantes dans la base de données et vous pouvez dire au cache, veuillez surveiller cet ensemble de données. Si cet ensemble de données change, continuez et supprimez cet élément du cache.

Dépendance de la base de données

Laissez-moi vous montrer comment cela se fait. Donc, il y a une fonctionnalité appelée Dépendance SQL dans ADO.NET qui NCache les usages. Ce qui permet NCache devenir client de votre base de données. Et, cela pourrait être une base de données SQL, cela pourrait être Oracle. Et puis NCache indique à la base de données de l'avertir lorsque cet ensemble de données change et que cet ensemble de données est une instruction SQL que vous avez spécifiée. La plupart du temps, il correspondra à une ou plusieurs lignes d'une table qui ont été utilisées pour construire cet objet que vous avez mis en cache. Donc, par exemple, ici, donc, si je devais passer à la dépendance SQL, encore une fois la même chose. Vous avez un handle de cache, puis lorsque vous ajoutez, cela cache.Ajouter, vous spécifiez maintenant, en cas de NCache cette chose appelée élément de cache qui est une sorte de structure qui contient la valeur ainsi que d'autres métadonnées. L'une des métadonnées qu'il contient s'appelle une dépendance de cache SQL, qui est une NCache classe qui correspond à la dépendance de cache SQL ADO.NET côté serveur. Vous lui transmettez une chaîne de connexion et vous lui transmettez une 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);
    }

Donc, vous dites quelque chose comme "Sélectionnez des colonnes dans les produits où l'ID de produit est quelle que soit la valeur". Donc, c'est un produit auquel vous mappez cela. Donc, vous dites à NCache utilisez cette instruction SQL, utilisez cette chaîne de connexion et surveillez cet ensemble de données ou demandez au serveur SQL de surveiller cet ensemble de données. En fait, ce code s'exécute ici, à droite. Parce que c'est là que NCache est.

Ainsi, cela a ensuite parlé au cluster de cache et le serveur de cache effectue alors l'appel ADO.NET et le serveur de cache parle maintenant à la base de données et devient un client. Et, le serveur de cache est celui qui reçoit la notification. Et, le serveur de cache est celui qui supprime réellement cet élément du cache, si la base de données l'informe que ces données ont changé. Ainsi, en intégrant cette fonctionnalité, vous avez soudainement la possibilité de conserver des données dans le cache dont vous ne pouvez même pas prévoir quand elles pourraient changer, vous savez. Mais, vous savez juste que cela peut changer de manière imprévisible, vous pouvez donc utiliser une dépendance SQL spécifiée.

C'est une fonctionnalité vraiment puissante. Il s'agit de la fonctionnalité qui permet à un cache de vous permettre de mettre en cache des données transactionnelles. Même lorsque vous n'avez pas le contrôle sur les mises à jour tout le temps et à cause de cela, vous mettrez en cache toutes sortes de données car ce cache deviendra réellement utile. Et, cela peut être fait de plusieurs façons si la base de données sous-jacente prend en charge la notification de base de données, ce qui est le cas dans le cas du serveur SQL et d'Oracle, elle utilisera la dépendance SQL ou la fonction de dépendance Oracle, sinon, le NCache a au moins un mécanisme d'interrogation intégré où il peut également vous permettre de le spécifier. … Il existe un mécanisme où vous spécifiez une table spéciale NCache le surveille et toutes les lignes qui y changent, il y a un élément de cache correspondant qu'il supprime ensuite.

Et, une troisième option consiste à effectuer des appels de cache à partir d'une procédure CLR. Ainsi, chaque fois qu'une donnée change, il y a un déclencheur de base de données qui appelle la procédure, qui appelle le cache. Et cela peut ajouter des données, mettre à jour des données ou supprimer des données du cache. La seule chose avec la procédure CLR est que vous ne voulez pas faire… je veux dire que vous voulez faire des appels asynchrones. Parce que, quoi que vous ayez appelé, c'est en fait votre base de données qui est maintenant devenue un client du cache comme l'arrière, à droite. Donc, il essaie de mettre à jour quelque chose qui ira ici, puis il pourrait être reproduit. Donc, tout cela se passe dans une transaction de base de données et, comme vous le savez, les transactions de base de données expirent assez rapidement. Ainsi, en effectuant des appels asynchrones, vous pouvez immédiatement effectuer l'appel de cache, puis rendre le contrôle.

Ce sont donc les trois façons dont vous pouvez vous assurer qu'un cache est maintenu synchronisé avec votre base de données relationnelle. Bien sûr, la même logique s'applique au non relationnel. Et si vos données se trouvaient dans un cloud, quelque part ? Ou c'est dans le mainframe. Vous savez, vous avez un appel de méthode Web pour aller toujours le chercher. Ensuite, en cas de NCache au moins, vous pouvez avoir une fonctionnalité de dépendance personnalisée où votre code est enregistré sur le cluster de cache, NCache l'appelle toutes les, disons, 15 secondes et dit allez-y et veuillez vérifier votre source de données et voir si ces données ont changé. Si c'est le cas, déclenchez un événement, puis la même logique entre en jeu.

Donc encore garder le cache frais est la chose la plus importante dans un cache distribué. Si vous ne pouvez pas garder le cache à jour, son utilisation est alors très limitée.

Lecture et écriture immédiates

Il existe une autre fonctionnalité appelée Lecture et écriture immédiates. La lecture directe est une fonctionnalité qui est à nouveau une fonctionnalité très utile et très puissante. C'est essentiellement à nouveau votre code qui s'exécute sur le serveur de cache. Où est-ce? Ici. Donc, disons, vous implémentez une interface de lecture en cas de NCache. Désormais, la lecture / écriture est un concept mis en œuvre par NCache. Il est également implémenté par de nombreux lecteurs Java, mais du côté .NET NCache est le seul à l'avoir. Ainsi, l'interface de lecture est essentiellement votre code. Il a une méthode Init, une méthode Dispose, donc Connect et Disconnect puis Load.

...
// 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;
}
...

Il vous donne une clé et en fonction de la clé, vous êtes censé déterminer où aller et obtenir les données. Et, non seulement vous renvoyez les données, mais vous renvoyez également certaines des métadonnées, comme les expirations et d'autres choses avec. Quelle est la valeur de la lecture continue ? Donc, encore une fois, ce code est quelque chose que vous implémentez et que vous enregistrez sur le… Donc, c'est ce code qui s'exécute ici sur le serveur de cache. Nous avons donc parlé d'une dépendance personnalisée. Donc, si vous avez une source de données personnalisée, c'est un code qui s'exécute sur le serveur de cache et la lecture est également quelque chose qui s'exécute sur le serveur de cache.

A quoi sert la lecture continue ? Pourquoi devriez-vous utiliser une lecture intégrale ? Il y a deux ou trois avantages. Premièrement, vous consolidez tout votre code de persistance en un seul endroit. Donc, si vous avez plusieurs applications utilisant le cache, disons que vous avez plusieurs applications, vous savez, elles n'ont pas à implémenter ce code encore et encore. Ainsi, il est conservé dans le serveur de cache lui-même. C'est le premier avantage. Le deuxième avantage est que lorsque vous expirez quelque chose, disons, vous expirez quelque chose à cause des expirations ou à cause de la synchronisation de la base de données, au lieu de supprimer cet élément du cache, pourquoi ne pas simplement le recharger. Parce que, si vous le supprimez, la prochaine fois que l'application le voudra, il le rechargera de toute façon. Ainsi, vous pouvez faire mapper la lecture avec ceci et dire où le cache dit d'accord si cet élément expire ou s'il obtient… s'il s'agit d'une synchronisation automatique et que je dois le supprimer, j'appellerai simplement la lecture. Alors, pourquoi est-il bon d'appeler la lecture intégrale ? Je veux dire quel est le problème? Pourquoi ne pas simplement le recharger par l'application ? Eh bien, si vous avez une application à fort trafic, il y a de fortes chances que de nombreux utilisateurs demandent ces mêmes données. Vous avez des centaines de milliers de ces articles et ils expirent tous à leur propre rythme. Ainsi, pour chaque fois qu'un élément expire, vous auriez des centaines, voire des milliers de requêtes dans la base de données pour le même élément. Et tout ira et mettra à jour le cache à nouveau. Ainsi, beaucoup de trafic inutile va vers la base de données. Ce qui, si vous aviez une lecture intégrale, ne quitterait jamais le cache. Il restera toujours dans le cache et à un moment donné, il sera simplement mis à jour. Ainsi, le trafic vers la base de données ne se produit jamais.

La deuxième fonctionnalité est l'écriture continue qui fonctionne exactement comme la lecture continue, sauf bien sûr que c'est pour l'écriture. Alors, laissez-moi vous montrer ça. Par exemple, ici encore, vous avez l'Init, vous avez le Dispose, mais maintenant vous avez un Write et vous donne l'objet réel, puis l'écriture peut être soit ajouter, mettre à jour ou supprimer, à droite. Ainsi, tous les trois sont appelés écrire. Donc, en fonction de ce type d'opération, vous allez mettre à jour votre base de données ou votre source de données.

#region IWriteThruProvider Members
public OperationResult WriteToDataSource(WriteOperation operation)
{
    bool result = false;
    OperationResult operationResult = new OperationResult(operation, OperationResult.Status.Failure);
    Customer value = (Customer)operation.ProviderCacheItem.Value;
    if (value.GetType().Equals(typeof(Customer)))
    {
        result = sqlDatasource.SaveCustomer((Customer)value);
    }
    if (result) operationResult.DSOperationStatus = OperationResult.Status.Success;
    return operationResult;
}

public OperationResult[] WriteToDataSource(WriteOperation[] operation)
{
    throw new Exception("The method or operation is not implemented.");
}

Maintenant, l'écriture continue a un autre avantage. Il présente le même avantage que la lecture continue en termes de communité du code. Le deuxième avantage de l'écriture immédiate est appelé écriture différée. C'est-à-dire que vous pouvez mettre à jour. Il existe donc une fonctionnalité appelée écriture différée dans laquelle vous pouvez mettre à jour le cache immédiatement de manière synchrone, mais les mises à jour de la base de données se produisent de manière asynchrone. Pourquoi est-ce une bonne chose? Eh bien, parce que cette base de données est lente. Donc, si vous savez, si vous êtes sûr que la mise à jour de la base de données sera effectuée en temps opportun… il est prévisible, pourquoi ne pas simplement la mettre en file d'attente. Il est mis en file d'attente et le cache effectue cette opération en arrière-plan. Cette file d'attente est également répliquée sur plusieurs serveurs. Ainsi, si un serveur tombe en panne, la file d'attente n'est pas perdue.

Je pense que tout ce que vous avez à voir dans le contexte de l'évolutivité. Tout ce qui est rapide, même s'il s'agit d'une base de données en mémoire, tout est sur un seul serveur. Ainsi, plus de mises à jour sont envoyées, plus de lectures lui sont envoyées, plus la charge est chargée dans la base de données, plus elle devient lente. Tout comme le point de défaillance unique. C'est ça. C'est la vraie raison, pourquoi tout cela existe et dans le contexte de tout cela, vous obtenez tous les avantages supplémentaires. Si vous disposiez d'une fonctionnalité d'écriture différée, votre application n'a plus qu'à mettre à jour le cache de manière synchrone. Car, une fois le cache mis à jour, le cache se chargera de la mise à jour de la base de données de manière asynchrone. Et cette file d'attente a sa propre optimisation. Il peut faire des mises à jour en masse, il peut répliquer. Ainsi, l'écriture différée a les performances, la partie vitesse dont vous avez parlé est plus pertinente pour l'écriture et l'écriture différée que pour la lecture.

La lecture est également quelque chose qui, vous savez, peut être plus rapide dans certains cas que l'application qui y accède, mais en écriture derrière, c'est définitivement toujours plus rapide.

Des questions? Il ne me reste que quelques minutes. Je vais parler d'une autre fonctionnalité, puis j'irai à la fin. Ainsi, les personnes qui ont l'habitude de faire une mise en cache en mémoire In-Proc autonome, comme l'objet de cache ASP.NET, lorsqu'elles passent à un cache distribué, beaucoup de nos clients nous appellent et disent, vous savez, vous promettiez que le cache réellement améliorer mes performances. Mes performances ont en fait baissé. Pourquoi donc? Quelqu'un peut-il deviner? Pourquoi cela ralentit-il réellement, dès que vous passez à un cache distribué par rapport à un cache In-Proc. La latence du réseau. La latence du réseau en est une. Un problème plus important est la sérialisation et la désérialisation qui représentent un coût énorme.

Cache client ou Cache proche

Donc, ce que fait une partie du cache distribué, y compris NCache, ils mettent en œuvre ce qu'on appelle un cache client, certains l'appellent près du cache. C'est un sous-ensemble de ce cache, qui est conservé dans le serveur d'applications. Il peut même être In-Proc ou OutProc. Mais, la plupart du temps, c'est In-Proc. Ainsi, il vous offre le même avantage qu'un cache In-Proc autonome, sauf qu'il est synchronisé avec celui-ci.

Et, c'est un sous-ensemble plus petit, alors disons, cela pourrait être 16 gigaoctets par serveur, cela pourrait être juste un gigagramme. Et c'est une fenêtre mobile, n'est-ce pas ? Ainsi, tout ce que vous mettez en cache est conservé, puis au fur et à mesure que vous avancez, les éléments les plus anciens expirent ou sont expulsés, puis de nouvelles données sont mises en cache.

Ainsi, un cache client vous donne les vraies performances. Il conserve les données sous forme d'objet au sein du processus de candidature. Donc, si vous le récupérez des centaines ou des dizaines de fois, la première fois, bien sûr, vous devez le récupérer à partir du cache distribué. Peut-être que la première fois que vous le récupérerez dans la base de données. Il va dans le cache distribué puis dans le cache client, mais une fois que cela est fait, toutes les autres lectures sont effectuées dans votre propre tas, ce qui est ultra-rapide. Donc, c'est une fonctionnalité qui est vraiment puissante. Vous voulez certainement en profiter.

Donc, il y a quelques choses dont vous devez vous assurer. Un cache distribué, tout comme une base de données, s'exécute dans votre centre de données dans votre environnement de production. Ainsi, il doit répondre à certaines des exigences architecturales. Il doit avoir une haute disponibilité. Il doit assurer la fiabilité et l'évolutivité des données. Donc, il doit faire une réplication intelligente.

Je ne vais pas entrer dans les détails. Vous pouvez y jeter un coup d'œil. Vous pouvez faire la recherche en ligne. Par exemple, si vous avez plusieurs centres de données, vous vous attendez à ce que votre base de données se réplique, pourquoi pas le cache ? Tu sais. Pourquoi le cache ne devrait-il pas également être disponible de manière synchronisée sur plusieurs… Alors, oui, un bon cache devrait l'être.

Options de mise en cache distribuée .NET

Si vous faites des applications .NET, à ce moment, vous savez, il y a à peu près deux options que vous avez pour la mise en cache. L'un est Redis que Microsoft a mis sur Azure. L'autre est NCache. Du côté de Java, comme je l'ai dit, il y a un certain nombre de joueurs qui sont plutôt bons.

Donc, je veux juste faire une comparaison de très haut niveau.

NCache est le plus ancien cache .NET. Il est sur le marché depuis 2005. C'est .NET natif. Il est également open source, tout comme Redis. Il est également disponible sur Azure ou Amazon les deux. Redis … Donc, il existe deux versions de Redis, celui qui est développé par Redis Labs, qui ne fonctionne que sous Linux. En fait, Microsoft utilise cette version dans Azure. Et, la version que Microsoft a portée sur Windows, ils ne l'utilisent même pas eux-mêmes. En fait, nous avons entendu beaucoup de plaintes de clients. Ce n'est pas très stable. Mais, en dehors d'Azure, la seule version que vous avez pour Windows est celle que Microsoft a portée, la MS Open Tech. Mais, à part ça, si vous allez à Redis ils ne vous donneront que la version Linux. Sur Azure lui-même, il existe deux différences entre NCache et d'azur qui est celui NCache vous donne en fait un serveur de cache en tant que machine virtuelle. Ainsi, vous pouvez exécuter vous-même tout ce code côté serveur, surveiller les choses. Redis vous donne le cache en tant que service. Ainsi, le cache est une boîte noire. Vous n'avez qu'une API très simple que vous appelez. Et, la limitation de cela est que vous n'obtenez pas toutes les fonctionnalités dont nous venons de parler. Comment faites-vous la synchronisation de la base de données ? Lecture à travers l'écriture. En fait, je ne suis même pas allé dans la recherche SQL, car nous n'avions pas le temps. Donc, ce sont les deux façons dont vous pouvez le faire. Si vous voulez en savoir plus à ce sujet, vous pouvez visiter notre site Web et nous avons un document comparatif détaillé. Donc, si je devais entrer dans Redis vs NCache ici, vous pouvez voir un document complet. Vous pouvez également le télécharger. Il s'agit d'une comparaison fonctionnalité par fonctionnalité basée sur leur documentation et la nôtre, puis vous pouvez voir celle qui répond à vos besoins. Des questions? C'est la fin de mon exposé. Merci.

Existe-t-il une dépendance à .NET Core Framework ou pouvez-vous l'utiliser avec .NET 4.0 ? Bonne question. Alors, NCache le serveur prend en charge .NET frameworks. C'est 4.0 ou plus tard. Le NCache Le client par défaut est .NET framework bien sûr. Nous sommes sur le point de sortir le .NET…. Donc, nous soutenons ASP.NET Core. Alors le .NET Core qui peut fonctionner sous Linux, nous ne le prenons pas encore en charge car il a des limitations. Mais le .NET Core qui fonctionne sur ASP.NET framework, en dessous uniquement sur Windows, en particulier ASP.NET Core NCache le soutiendra. Merci beaucoup les gars.

Que faire ensuite?

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