Camp de code des villes jumelles
Mise à l'échelle des applications .NET avec la mise en cache distribuée
Par Iqbal Khan
Président et évangéliste de la technologie
Regardez cette démonstration pratique d'un cache distribué et découvrez les meilleures pratiques d'utilisation d'un cache .NET dans divers environnements. 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
Merci à tous d'être venus. Je m'appelle Iqbal Khan. C'est une belle journée dehors. Je viens de Tampa. Donc, température beaucoup plus agréable ici. Je m'attendais à un temps beaucoup plus frais que ce que nous avons ici. Alors, merci de rester à l'intérieur. Je suis un évangéliste de la technologie dans cette entreprise appelée Alachisoft. Nous sommes les fabricants de NCache. Juste les une ou deux prochaines minutes vont être une déclaration de marketing. Nous avons donc deux produits pour l'espace .NET. L'un est notre principal produit phare appelé NCache qui est un cache distribué pour .NET. C'est l'expertise que nous avons. Donc, nous sommes dans cet espace depuis environ 10 ans et c'est ainsi que nous avons développé une expertise dans ce sujet spécifique.
Nous avons un autre produit appelé NosDB c'est quelque chose que nous avons lancé à la fin de l'année dernière. C'est une source ouverte NoSQL database pour .NET. C'est comme des fonctionnalités de niveau MongoDB mais .NET natif et encore une fois tout open source. NCache est également open source et, tout comme NosDB. Veuillez jeter un coup d'œil à nos produits.
Donc, je préférerais avoir une discussion plus interactive. Nous allons passer par une combinaison de discussion conceptuelle architecturale et de code source. Ainsi, nous pouvons réellement voir comment vous procéderiez pour utiliser un cache pour votre application. Alors, commençons.
Évolutivité
Éliminons quelques définitions. Le numéro un est; qu'est-ce que l'évolutivité. L'évolutivité n'est pas la performance. Ainsi, si votre application fonctionne rapidement avec 5 utilisateurs, elle n'est pas évolutive à moins que vous ne puissiez avoir les mêmes bonnes performances sous 5000 50,000, 500,000 5 ou XNUMX XNUMX utilisateurs. Bien sûr, si votre application ne fonctionne pas rapidement avec XNUMX utilisateurs, vous devez examiner d'autres aspects que ceux dont nous allons parler.
Évolutivité linéaire
L'évolutivité linéaire est davantage une terminologie d'architecture de déploiement. Si votre application est architecturée de telle manière que vous pouvez ajouter plus de serveurs pour augmenter votre capacité, votre capacité de transaction, d'ailleurs quand j'utilise le mot évolutivité je parle principalement de capacité de transaction, je ne parle pas de beaucoup de données. Donc, nous ne parlons pas de téraoctets de données en termes d'évolutivité. Nous parlons de pouvoir gérer beaucoup de transactions, beaucoup d'activité. Ainsi, une évolutivité linéaire signifie que vous pouvez augmenter votre capacité de transaction simplement en ajoutant des serveurs et qu'il n'y a pas de goulots d'étranglement et c'est ce que nous voulons réaliser.
Évolutivité non linéaire
Bien sûr, la non-linéarité n'est pas quelque chose que nous voulons atteindre. Cela signifie que peu importe le nombre de serveurs que vous ajoutez, vos performances vont baisser après un certain point, car il existe un goulot d'étranglement fondamental dans l'architecture de votre application dans votre déploiement, qui vous empêche de pouvoir évoluer.
Quelles applications ont besoin d'évolutivité ?
Quels types d'applications ont besoin d'évolutivité ? Ce sont généralement des applications de type serveur, ASP.NET, ASP.NET Core maintenant, les services Web qui sont généralement WCF, le backend IoT qui est généralement des services Web, bien qu'ils ne soient pas obligés de l'être. Applications de traitement de données volumineuses. Celles-ci sont généralement effectuées en Java, mais si vous le faisiez dans .NET, vous auriez le même problème que dans Java et dans toute autre application serveur nécessitant de traiter de nombreuses transactions. Vous pourriez être, par exemple, une banque ou une société de services financiers avec des millions de clients. Ils vous appellent pour changer d'adresse, peut-être transférer des fonds et la nuit, vous devez traiter tout cela pour la conformité ou pour d'autres raisons de SLA. Donc, même si vous avez, vous savez, ce sont davantage des traitements par lots, des traitements back-end, ce sont vos autres applications serveur qui devront toujours pouvoir traiter autant d'informations et si elles ne le peuvent pas, vous sachez que vous avez beaucoup de problèmes.
Le problème de l'évolutivité
Si vous avez ces applications, elles auront probablement besoin d'évolutivité. Alors, parlons maintenant d'où est ce problème? Où est le problème d'évolutivité, que nous allons essayer de résoudre ? Le problème d'évolutivité n'est vraiment pas au niveau de l'application. Votre application, toutes celles dont j'ai parlé, sont généralement conçues de manière à ce que vous puissiez ajouter plus de serveurs et il n'y a aucun problème. Le problème vient de votre stockage de données. Ce que je veux dire par là, c'est où résident vos données d'application, vos bases de données relationnelles. Cela pourrait être un serveur SQL, Oracle, MySQL. Ce n'est pas un fournisseur en particulier. Le concept de bases de données relationnelles par conception ne peut pas évoluer. En fait, ils ne peuvent pas non plus évoluer en termes de quantité de données. Voilà pourquoi NoSQL databases sont devenus si populaires, mais, surtout du côté des transactions et, de même si vous avez des données héritées du mainframe. De nombreuses applications doivent accéder à des données héritées. Donc, c'est là que se produit le goulot d'étranglement et, si vous avez ce goulot d'étranglement, peu importe si ce niveau est évolutif, vous ne pourrez pas évoluer.
NoSQL databases sont devenus populaires pour cette raison précise qu'ils offrent une évolutivité. Et, vous savez, et nous avons aussi un NoSQL database produit, mais la plupart du temps, ils ne règlent pas le problème. Ils ne peuvent pas résoudre le problème car, pour une combinaison de raisons techniques et commerciales, vous ne pouvez pas les utiliser. Pour utiliser un NoSQL database vous devez y mettre des données et non dans votre base de données relationnelle. Certaines données que vous pouvez faire. Vous pouvez certainement mettre dans le NoSQL database mais une grande partie de vos données commerciales traditionnelles resteront dans des bases de données relationnelles. Donc, si vous ne pouvez pas déplacer vos données vers NoSQL databases, ils ne sont pas bons. Donc, vous devez résoudre ce problème, en gardant à l'esprit que vous allez continuer à vivre avec des bases de données relationnelles, même si vous mettez un NoSQL database dans le mélange, ce n'est qu'un sous-ensemble des données. Ce n'est généralement pas un remplacement des bases de données relationnelles. Et, étant un NoSQL database entreprise, vous savez, je suis très honnête avec vous, lorsque nous parlons à nos clients, nous ne disons pas d'arrêter d'utiliser le relationnel, cela n'arrivera jamais. Nous disons, utilisez-le comme une augmentation du relationnel. Donc, si vous devez rester avec le relationnel, vous devez résoudre ce problème avec, vous savez, avec cela dans le mélange et c'est là qu'un cache distribué entre en jeu, c'est pourquoi nous avons cette conversation.
Déploiement de cache distribué (NCache)
Un cache distribué, permettez-moi de définir cela un peu. Un cache distribué est distribué. Il vit sur deux serveurs ou plus, ici. C'est un niveau de mise en cache séparé, logiquement parlant. Physiquement, il peut se trouver sur le même boîtier que l'application, mais logiquement, il s'agit d'un niveau de mise en cache distinct. Deux serveurs ou plus et un cache distribué forment généralement un cluster. Ainsi, il s'agit généralement d'un cluster de ceux-ci, les clusters basés sur TCP étant les plus courants. NCache utilise définitivement TCP pour le clustering. Et, ce cluster signifie que toutes les ressources, tous ces serveurs, le CPU, la mémoire, les cartes réseau, sont tous regroupés. Et c'est ainsi que cela devient évolutif. Parce que vous pouvez ajouter plus de serveurs, car vous devez augmenter la capacité.
C'est quelque chose que vous pouvez faire ici aussi. Mais, vous ne pouvez pas faire ici. Comme je l'ai dit, vous pouvez ajouter une autre base de données SQL dans le mélange, mais, vous savez, vous devez l'avoir dans l'image. Dès que vous avez cela dans l'image, vous aurez besoin de quelque chose comme ça dans votre mix.
Un cache distribué vit sur des serveurs peu coûteux. Il ne s'agit pas de configurations de type de serveur Web typique de base de données haut de gamme. La plupart de nos clients ont une boîte à 8 cœurs, c'est comme s'il s'agissait d'un double processeur, maintenant nous utilisons simplement le mot 8 cœurs et un 64 bits avec juste beaucoup de mémoire. Beaucoup signifie que 16 à 32 concerts sont à peu près la moyenne par serveur que nous voyons. Nous ne recommandons même pas plus de 64 Go sur chaque boîte. Parce que, si vous avez plus de 64 Go de mémoire, .NET nécessite une récupération de place. Le GC lui-même est une tâche qui prend beaucoup de temps et commence à devenir un goulot d'étranglement en soi. Il est donc préférable d'avoir plus de serveurs que d'avoir peu de serveurs haut de gamme. Parce que, vous savez, même si le cache est distribué par conception, maintenant le goulot d'étranglement commence à devenir un ramasse-miettes. Et, nous avons appris cela à travers de nombreuses expériences douloureuses au fil des ans. Vous savez, nous avions des clients qui montaient jusqu'à 128 concerts et tout à coup, il y avait beaucoup de pression sur le processeur. Ils ont donc dû augmenter un peu leur puissance de traitement et cela a commencé à ressembler davantage à une base de données. Donc, alors vous savez, nous avons recommandé de le faire tomber.
Vous mettez en cache les données qui résident dans la base de données. Et, 80 % du temps, vous irez essentiellement au niveau de mise en cache, 20 % du temps, vous irez à la base de données. Le cache est ultra-rapide en mémoire, beaucoup plus rapide que n'importe quelle base de données, y compris NoSQL database, y compris plus rapide que le nôtre NoSQL database. NCache est au moins un ordre de grandeur plus rapide que n'importe quelle base de données. Parce que, vous savez, les bases de données doivent aller sur le disque. Mais, toutes les mises à jour doivent bien sûr aller dans la base de données réelle. Donc, c'est là que viennent les 20% plus bien sûr certaines des lectures.
Maintenant, si vous faites cela, tout à coup toute la pression est retirée de la base de données. Maintenant, il fonctionne. Vos lectures sont beaucoup plus rapides et les mises à jour sont également beaucoup plus rapides. Ainsi, vous êtes en mesure d'atteindre cette évolutivité, mais vous êtes également en mesure, non seulement l'application est évolutive maintenant, mais elle est soudainement plus rapide. Bien que la principale raison d'utiliser un cache ne soit pas d'améliorer les performances, ce qui est encore une fois un peu à l'opposé de ce que les gens ont traditionnellement pensé, vous savez, que le cache est là pour améliorer les performances. C'est, dans une situation autonome, oui, c'est le cas. Même les bases de données utilisent la mise en cache en mémoire. Notre NosDB utilise également la mise en cache intégrée, mais c'est vraiment pour l'évolutivité, là où vous devez pouvoir le faire, car c'est un problème que vous ne pouvez pas vous racheter. Vous ne pouvez pas acheter du matériel plus cher pour obtenir l'évolutivité. Vous devez concevoir l'application et utiliser la bonne infrastructure, ou les bons composants dans le cadre de votre architecture, si vous voulez avoir une application évolutive.
Côté Java, cela s'appelle une grille de données en mémoire. Du côté .NET, cela s'appelle un cache distribué. Un autre mot pour cela est un en mémoire NoSQL magasin de valeur clé. Donc, je veux dire qu'il y a trois façons différentes de voir les choses. Ceci n'est pas un NoSQL database c'est un NoSQL stockage en mémoire de la valeur clé. Car, il ne fait aucune persistance, il n'a pas de magasin permanent.
Donc, quand vous avez une image comme celle-ci, je veux que vous soyez convaincus sur le plan architectural que vous aurez maintenant une application qui n'aura jamais de goulots d'étranglement. Si vous concevez votre application pour l'utiliser comme pour votre infrastructure. Toutes les questions, jusqu'à présent avant que je passe à plus de profondeur.
Je suppose que cela dépend des détails, comment savez-vous si le cache est périmé ou si vous mettez à jour quelque chose hors du boîtier ? Permettez-moi d'en venir là. Bonne question.
Utilisations courantes du cache distribué
Donc, disons que nous sommes convaincus que nous avons besoin d'un cache distribué dans le cadre de notre architecture d'application, la prochaine question qui nous vient à l'esprit est de savoir comment l'utiliser ? Où utilisez-vous le cache et quelles sont les problématiques liées à chaque type d'utilisation ? Donc, en tant que développeur .NET, et encore une fois, je me concentre sur .NET, mais les mêmes concepts s'appliquent également à d'autres applications.
Mise en cache des données d'application
Le cas d'utilisation le plus courant est la mise en cache des données d'application, c'est ce dont je parlais jusqu'à présent, où vous avez une base de données et vous ne faites que mettre en cache les données ici. Ainsi, l'objectif est de ne pas consulter la base de données aussi fréquemment. Et, vous obtenez tous les avantages dont j'ai parlé. Dès que vous faites cela, il y a un problème qui survient, et c'est ce dont vous venez de parler. Les données existent désormais à deux endroits. L'un est le magasin principal permanent, qui est votre base de données, où vous devez toujours le faire et le second est le cache. Et, en fait, dans la cache, il existe à plus d'un endroit et j'en parlerai aussi.
Ainsi, lorsque les données existent à plusieurs endroits, qu'est-ce qui pourrait mal tourner ? Vous savez, cela pourrait se désynchroniser. Ainsi, si un cache distribué ne peut pas gérer cette situation, vous êtes obligé de mettre en cache les données en lecture seule. En fait, la plupart des gens, lorsqu'ils pensent au cache, réagissent comme un réflexe, c'est uniquement pour les données en lecture seule. Parce que, si je mets en cache des données qui changent, ce que j'appelle des données transactionnelles. Ensuite, il va se désynchroniser. Et, si vous savez, que ce problème classique de retirer un million de dollars deux fois du même compte bancaire, il vient ici. Donc, vous savez, si un cache ne résout pas ce problème, vous êtes limité à un très petit sous-ensemble. Environ 10 à 15 % des données sont tout ce que vous pouvez mettre en cache et ce n'est pas suffisant. Donc, un bon cache distribué doit résoudre ce problème et je vais en parler.
Mise en cache spécifique à ASP.NET
Le deuxième cas d'utilisation est que si vous avez une application ASP.NET, vous pouvez y stocker trois éléments différents. Bien sûr, cela change à mesure que de nouveaux frameworks arrivent. Ainsi, le plus courant est l'état de session ASP.NET, qui est présent à la fois dans l'ASP..NET core et le framework ASP traditionnel. Les sessions sont quelque chose que vous stockez par défaut soit In-Proc, soit vous les stockez dans le serveur SQL. Les deux ont des problèmes d'évolutivité. SQL a également des problèmes de performances. Et, parce que les bases de données relationnelles n'ont pas été conçues pour stocker des blobs et que les sessions sont stockées sous forme de blobs. Et deuxièmement, vous savez, pour la même raison que vous voudriez mettre en cache les données d'application et ne pas aller dans la base de données, vous ne voulez pas non plus conserver les sessions dans la base de données. Il s'agit donc d'un cas d'utilisation très très idéal pour les applications ASP.NET. Et, vous savez, c'est la première chose que la plupart de nos clients utilisent. Vous savez, si vous avez une application existante et que vous souhaitez incorporer un cache distribué, le moindre effort requis pour l'incorporer est les sessions. Parce que, ASP.NET framework permet à un cache tiers de se brancher. Aucune programmation n'est nécessaire. Vous venez de modifier le fichier web.config. En fait, permettez-moi de vous le montrer rapidement. Je vais juste sauter d'avant en arrière.
Ainsi, par exemple, j'ai cette petite application ASP.NET et j'ai un web.config ici et je vais bien sûr utiliser NCache comme exemple mais, disons, pour utiliser NCache en tant que fournisseur d'état de session, vous devez mettre ces assemblys. Donc, balise "ajouter un assemblage". Ainsi, cette assemblée de NCache a implémenté l'interface du fournisseur d'état de session ASP.NET.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<machineKey validationKey="A01D6E0D1A5D2A22E0854CA612FE5C5EC4AECF24" decryptionKey="ACD8EBF87C4C8937" validation="SHA1" />
<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>
<customErrors mode="RemoteOnly" />
<authentication mode="None" />
<authorization>
<allow users="*" />
</authorization>
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
<!-- For NCache Developer Edition replace 'myPartitionedCache' with 'myCache' or any other local-cache-->
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="1">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" exceptionsEnabled="true" enableSessionLocking="true" emptySessionWhenLocked="false" sessionLockingRetry="-1" sessionAppId="NCacheTest" useInProc="false" enableLogs="false" cacheName="myPartitionedCache" writeExceptionsToEventLog="false" AsyncSession="false" />
</providers>
</sessionState>
<!-- GLOBALIZATION
This section sets the globalization settings of the application.
-->
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<xhtmlConformance mode="Legacy" />
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" />
</system.web>
<system.webServer>
<directoryBrowse enabled="true" showFlags="Date, Time, Size, Extension, LongDate" />
</system.webServer>
</configuration>Donc, c'est comme ça qu'il est conforme à l'ASP.NET framework spec comme cache tiers. Donc, c'est la première chose que vous faites et ensuite vous changez l'espace de nom. En fait, vous utilisez simplement cette balise. Donc, vous vous assurez que le mode est personnalisé et que le délai d'attente n'est certainement pas d'une minute. Ça devrait être 20. Et, j'y reviendrai. C'est le nom du cache.
En cas de NCache, tous les caches sont nommés. Je reviendrai là-dessus. Donc, c'est tout ce que vous faites et votre application commence à stocker les sessions dans un cache. Et, vous verrez immédiatement une amélioration des performances, car il est en mémoire, beaucoup plus rapide que SQL. Pas plus rapide que In-Proc mais plus rapide que SQL mais plus évolutif dans les deux cas.
Le deuxième cas d'utilisation d'ASP.NET est l'état d'affichage. Si vous n'utilisez pas le framework MVC, s'il est toujours dans l'ancien ASP.NET, vous avez un état d'affichage, que vous pouvez ou non connaître. Un état d'affichage, pour ceux d'entre vous qui ne le savent pas, c'est une chaîne cryptée qui est envoyée par le serveur Web au navigateur uniquement pour revenir lorsqu'il y a un message. Ainsi, cela pourrait atteindre des centaines de kilo-octets. Multipliez cela par des millions de requêtes que votre application doit traiter et il y a deux mauvaises choses qui se produisent, une elle consomme beaucoup de bande passante et la bande passante n'est pas gratuite. Lorsque vous hébergez votre application, vous devez payer pour la bande passante. Deuxièmement, le temps de réponse est plus lent car il s'agit d'une charge utile beaucoup plus lourde. Donc, si vous pouviez mettre cela en cache sur un serveur, cela éliminerait simplement tout cela et rendrait l'application plus rapide.
Le cache de sortie est un ASP.NET framework qui vous permet de mettre en cache la sortie de la page, de sorte que, si la sortie de la page ne change pas, elle la prendra simplement à partir de la dernière exécution. Là encore, il est préférable de brancher un cache distribué dans une ferme Web plutôt que de conserver des copies séparées de ce cache de sortie dans chaque serveur Web. Ce que vous voulez faire en réalité, c'est rendre ces serveurs Web totalement sans état du point de vue de la gestion des applications. S'ils sont sans état, vous pouvez faire tous les correctifs, vous pouvez, vous savez, toutes les corrections de bogues, toutes les mises à niveau de votre application, sont beaucoup plus fréquentes que toutes les mises à niveau du cache en termes de mises à niveau logicielles. Donc, s'il n'y a pas d'état maintenu ici, vous pouvez supprimer n'importe laquelle de ces boîtes de la ferme Web, l'utilisateur ne le remarquera même pas. Parce que tout l'état est maintenu ici ou dans la base de données et ce n'est pas quelque chose que vous touchez fréquemment, alors encore une fois, mettez cela en cache.
Maintenant, en cas de mise en cache spécifique à ASP.NET, il y a une bonne chose que tout cela ne nécessite aucune programmation. Ainsi, il vous suffit de les brancher immédiatement sans aucun effort. La seule chose que vous faites bien sûr est un test de santé mentale. Par exemple, l'état de session ASP.NET, si vous le branchez et que vous utilisiez des sessions In-Proc, vous découvrirez peut-être que tous vos objets ne sont pas sérialisables. Et, vous ne le saviez pas et tout à coup, votre application commencera à lancer des exceptions. Donc, je veux dire, vous savez, ce niveau de test que vous devez faire. Mais, maintenant, il y a un autre problème particulier, contrairement à celui-ci où vous avez deux copies des données, maintenant les données n'existent que dans le cache.
Ainsi, lorsqu'un magasin en mémoire est votre magasin principal, qu'est-ce qui pourrait mal tourner ? La machine tombe en panne. Oui, vous savez, si un serveur tombe en panne, vous perdez des données et vous ne voulez perdre aucune de ces données, surtout pas les sessions. Donc, un bon cache distribué doit résoudre ce problème et cela se fait généralement par la réplication que les mêmes données existent au moins à deux endroits et si cela ne se produit pas, veuillez ne pas mettre de sessions dans ce cache, à moins que vous ne le fassiez pas, ce n'est pas vraiment… peu importe si vos utilisateurs utilisent cette session, ce qui n'est pas le cas dans la plupart des situations.
Partage de données d'exécution
Le troisième cas d'utilisation est partage de données d'exécution à travers les événements. C'est quelque chose que les gens faisaient généralement avec les files d'attente de messages, vous savez, ils ont leur propre place et un cache distribué n'est pas là pour les remplacer mais un cache distribué est beaucoup plus rapide plus évolutif et si les messages ou s'il y a le partage de données est se fait au même endroit, dans le même centre de données, vous pouvez utiliser un cache distribué dans un Pub / Sous-marin manière, vous pouvez le faire. Il existe également d'autres types d'événements où vous pouvez, vous le savez, montrer de l'intérêt pour certains éléments. Dites, si cet élément change, veuillez m'en informer. Ou en cas de NCache il y a une fonctionnalité appelée requête continue où vous pouvez également faire une instruction SQL et dire, 'SÉLECTIONNER LES CLIENTS OÙ CLIENT.VILLE = NEW YORK'. Si cet ensemble de données est mis à jour, supprimé ou si un nouvel objet est ajouté, mis à jour ou supprimé, veuillez m'en informer. Donc, si ce type de surveillance que l'application peut faire et c'est ainsi que les consommateurs peuvent être beaucoup plus intelligents sur ce dont ils veulent être informés. Et, les producteurs peuvent continuer à mettre à jour le cache.
C'est donc le troisième cas d'utilisation que beaucoup de gens ne connaissent pas, mais il devient de plus en plus évident que le cache est un très bon endroit pour le faire. Parce que vous utilisez déjà le cache pour ces deux raisons. Alors, pourquoi ne pas l'inclure et c'est très simple à intégrer dans votre application. Des questions, avant d'entrer dans les détails de ceux-ci?
Démo
Donc, je vais d'abord vous montrer à quoi ressemble une cache. Donc, alors nous pouvons mettre cela dans le contexte de tout ce dont nous parlons. j'utiliserai NCache comme exemple. Donc, j'ai un tas de machines virtuelles dans Azure. Donc, j'ai une démo1, une démo2 et un client de démonstration. Demo1 et Demo2 sont mes machines virtuelles de serveur de cache. Le client de démonstration est la boîte du serveur d'application. Donc, c'est le client de cache. Donc, j'ai tout ça.
Je vais y aller et je suis connecté, disons, je suis connecté au client de démonstration. Je vais continuer et créer un cache. Alors, je vais utiliser NCache manager, l'outil graphique. Je vais continuer et dire "Créer un nouveau cache de cluster".
En cas de NCache, tous les caches sont nommés. Je ne vais pas expliquer tous les détails. Je vais juste donner un nom à chaque cache.
Je vais choisir une topologie du cache. topologie est en fait une stratégie de stockage et de réplication. Ainsi, une topologie, en cas de NCache, disons qu'il existe une topologie appelée réplique de partition. Donc, ces deux sont des serveurs de cache ici et chaque serveur a une partition. Alors, disons en cas de NCache, NCache crée une partition pour chaque serveur et chaque serveur contient une réplique de la partition d'un autre serveur. Chaque partition contient un nième du nombre total de compartiments. En cas de NCache il y a 1000 compartiments par cache.
Donc, disons, s'il s'agit d'un cluster à deux nœuds, ce sont les 500 compartiments chacun, s'il s'agit d'un cluster à trois nœuds, c'est un tiers, un tiers, un tiers.
Réplique de partition, les partitions sont actives, les répliques ne sont pas actives, elles sont passives. Ainsi, le client ne parle qu'aux partitions et disons que si un client met à jour un élément ici, la partition continue et le réplique sur la réplique et que la réplication par défaut est asynchrone. Parce que, pour obtenir une véritable évolutivité, vous devez vous rendre à ce modèle de cohérence éventuel. Mais, dans certains cas, vos données sont très sensibles. Vous savez, vous avez beaucoup de sociétés de services financiers comme les banques qui utilisent NCache et leurs données sont en fait de l'argent. Donc, ils ne peuvent pas faire de cohérence éventuelle dans ce cas. Donc, là, vous devez faire une réplication synchrone, ce qui signifie que l'application attend que les données soient mises à jour aux deux endroits. Si un serveur tombe en panne, disons, si vous aviez un cluster à trois nœuds et que le serveur 3 tombe en panne, la partition 3 est en panne, la réplique 3 deviendra immédiatement active.
Donc, c'est ainsi que vous obtenez la haute disponibilité et maintenant, une fois qu'il est actif, il se rendra compte qu'il n'y a que deux serveurs, puis trois partitions, ce qui n'est pas le cas. Ainsi, il se fusionnera avec les partitions 1 et 2 et une fois cela fait, une réplique pour la partition 2 sera créée ici.
Tout cela en cas de NCache se fait au moment de l'exécution sans même que votre application s'en rende compte. De même, vous pouvez avoir un cluster à 2 nœuds et ajouter un troisième serveur et encore une fois toute la carte changera automatiquement d'ici à ici. Donc, c'est ce que signifiait ce choix.
Alors, je vais juste choisir réplique de partition comme topologie.
Je garderai la réplication asynchrone.
Je choisirai mon premier serveur qui est la démo 1, le deuxième serveur qui est la démo 2.
Je vais prendre toutes les valeurs par défaut. Je vais spécifier, je dirai, c'est seulement 1 Gig, je vais spécifier la taille de la partition.
Dans votre cas, si vous avez une machine de 16 Go, vous devez laisser environ 2 à 2.5 Go pour le système d'exploitation et les autres processus et consommer tout le reste pour le cache et quelle que soit la mémoire qu'il vous reste, la moitié doit être une partition active, la moitié c'est pour la réplique.
Lorsque vous faites votre planification de capacité, il est vraiment important que vous allouiez suffisamment de mémoire pour qu'en cas de sessions, les sessions aient suffisamment de mémoire pour rester, sinon lorsque le cache a épuisé toute cette mémoire, alors le cache est considéré comme plein et, alors une seule des deux choses se produira, soit le cache rejettera toute nouvelle entrée, soit il expulsera certaines des entrées existantes. NCache vous fournit trois algorithmes. Vous savez, le plus courant est le moins récemment utilisé.
Alors, NCache expulsera immédiatement 5 % du cache, lorsque le cache est considéré comme plein. Donc, maintenant que j'ai créé ceci, je vais continuer et ajouter un nœud client qui, dans ce cas, est un client de démonstration et je vais continuer et dire démarrer le cache.
Ainsi, lorsque je démarre la cache, il se passe beaucoup de choses dans les coulisses. Un nouveau cluster est en train de se former. L'appartenance au cluster est en cours de formation et propagée au client. Alors, que le client sait ce qu'est l'appartenance au cluster ? Quelle est la carte de distribution ? Donc, une fois que tout cela est fait, tout est en place. Donc, maintenant, je vais dire des statistiques. Je veux voir du PerfMon. Et, je veux exécuter rapidement cet outil appelé outil de test de stress, qui s'exécute rapidement. Il teste rapidement le cache dans votre environnement.
Donc, de cette façon, vous n'avez pas à faire de programmation pour le faire. Donc, voici à quoi ressemble le cache. Vous allez installer quelque chose comme ça. Disons que vous installez NCache. Il ne faut que ce temps pour obtenir un cluster à 2 nœuds avec un serveur d'applications configuré. Dans votre cas, vous aurez bien sûr plus d'un client. La configuration la plus courante est d'environ 5 à 8 clients et un cluster de cache de 2 à 3 nœuds. Et puis, vous savez, plus vous ajoutez de clients, plus vous ajoutez de serveurs.
Donc, maintenant que vous avez ce cache en cours d'exécution, revenons maintenant à nos sujets actuels. Donc, maintenant, tout ce que nous faisons, vous devez garder à l'esprit la façon dont nous avons créé ce cache nommé. Et je vous ai déjà montré l'état de session spécifique à ASP.NET.
Présentation de la mise en cache des données d'application (API)
Passons maintenant à la mise en cache des données applicatives qui est la richesse de ma présentation aujourd'hui. Ainsi, dans le cas d'une mise en cache des données d'application, il existe une API sur laquelle vous devez programmer. Parce que, ASP.NET core a maintenant une interface appelée IDistributed Cache que vous pouvez appeler cette API, puis derrière la scène, vous pouvez brancher un cache tiers. Du côté Java, ils ont une API très puissante en standard appelée JCache, mais du côté .NET, il n'y a rien. Ainsi, dans la plupart des cas, vous devrez programmer l'API de cache elle-même. Mais l'API est très simple.
- Connexion au cache
ICache cache = CacheManager.GetCache("myCache"); cache.Dispose(); - Récupération des données
Employee employee = cache.Get<Employee>("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); Employee employee = (Employee) cache.Remove("Employee:1000"); cache.RemoveAsync("Employee:1000");
En cas de NCache cela ressemble beaucoup à l'objet de cache ASP.NET, si vous le remarquez. Donc, ce que vous faites essentiellement, vous faites un cache.Get, vous obtenez l'objet, vous savez, le point de cache Ajouter, Insérer, Supprimer ou et il existe également des versions asynchrones de celui-ci. Asynchrone signifie ne pas attendre que le cache soit mis à jour mais, vous savez, renvoyer le contrôle et vous pouvez spécifier un rappel dans ce cas.
Laissez-moi vous montrer rapidement à quoi ressemble une application. Donc, j'ai cette application console très simple qui utilise NCache.
using System;
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.sample.data;
namespace BasicOperations
{
public class BasicOperations
{
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");
...
Donc, la première chose que vous devez faire est de vous assurer que vous référencez les assemblages de cache qui, en cas de NCache sont deux. Il y a NCache.Durée, NCache.La toile puis vous devez utiliser les espaces de noms qui sont à nouveau deux en cas de NCache. NCache.Durée, NCache.Web.Caching. Et, puis au début de votre application, qui en cas de console est juste là. Dans le cas d'une application ASP.NET, il s'agit probablement de votre global.asax. Vous devez vous connecter au cache et c'est là que votre nom de cache entre en jeu, quel que soit le nom que vous avez donné à votre cache. C'est ce qui vient ici. Et, maintenant que vous avez un handle de cache, vous pouvez continuer avec l'application, vous pouvez créer vos objets et vous pouvez faire cache.Ajouter. Vous spécifiez une clé basée sur une chaîne et la clé doit être unique. Ce n'est pas une bonne clé d'ailleurs. Votre clé doit être beaucoup plus précise et voici votre objet. Et, je veux dire, c'est comme ça et plus tard tu peux faire cache.Obtenir et vous pouvez récupérer votre objet dans le cache.
Maintenant, cet appel que vous avez fait a en fait abouti en cas de NCache, alors, quand tu l'as fait cache.Ajouter, il est allé essentiellement, à partir de là, il est allé à votre partition dans laquelle les données étaient censées entrer. Donc, il a mis en cache. Ajoutez-y et cette partition a ensuite répliqué ces données sur sa réplique. S'il s'agissait d'une application asynchrone, seule cette partition a été mise à jour et le contrôle est revenu. Si vous avez effectué un appel asynchrone, même cette partition et même vous n'avez même pas attendu que la partition soit mise à jour. Mais, juste celui-là cache.Ajouter appel a abouti à la réalisation de tout ce travail.
Et, de même quand vous faites un cache.Obtenir le client va directement là où se trouvent les données. Ainsi, il utilise la carte de distribution ci-dessous pour savoir où se trouvent les données et va directement où et les obtient. Disons que si vous vouliez l'article numéro 3, vous iriez le chercher tout de suite à partir de là.
Donc, ce code est derrière la scène, c'est ce qui se passe vraiment. Vers la base de données. Quel est votre. C'est juste le cache. En fait, j'en parlerai un peu aussi. Alors, vous sérialisez/désérialisez automatiquement les données ? Oui, en fait même plus que ça. Ainsi, avant que les données ne soient envoyées d'ici à ici, l'objet doit être sérialisé. En cas de NCache, NCache le conserve sous une forme sérialisée, dans le cache. Et, lorsque vous faites un cache.Get, il revient puis est désérialisé dans le client lui-même. Et, au moment où vous l'obtenez, tout est désérialisé. Ainsi, l'API vous semble très simple, mais il y a beaucoup de travail en cours.
Fonctionnalités de mise en cache des données d'application
Maintenant, à propos de la mise en cache des données d'application, la plus grande préoccupation était que les données existent à deux endroits, n'est-ce pas ? Et, si un cache ne répond pas à ce problème, cela va vraiment limiter ses avantages. Alors, comment un cache répond-il à cette préoccupation ?
Expirations absolues
Le numéro un s'appelle Expiration et il y a le Expiration absolue ce qui signifie expirer cet objet, disons dans 10 minutes. Ainsi, vous en faites une estimation éclairée pour chaque objet en termes de durée pendant laquelle il est sûr de conserver cet objet dans le cache. Et, à la fin de ce temps, le cache supprime automatiquement cet objet.
Laissez-moi vous montrer à quoi cela ressemble dans le code. Ainsi, en cas de NCache si vous regardez le même appel cache.Add, le troisième argument est un argument date/heure qui a la valeur d'une minute à partir de maintenant.
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");
...Donc, il dit essentiellement au cache d'expirer cet objet dans une minute. Peu importe que vous en ayez besoin ou non après une minute, cet objet sera supprimé du cache. Pourquoi? Parce que vous ne vous sentez pas à l'aise de le garder dans le cache plus d'une minute. Et pourquoi ne vous sentez-vous pas à l'aise ? Parce que, vous pensez que ça va changer dans la base de données. Il n'est pas sûr de le garder dans le cache.
Expirations glissantes
Il existe un autre type d'expiration appelé Expiration glissante, qui sert un objectif totalement différent. Ce n'est pas pour garder le cache frais, c'est plus pour le nettoyer. Ainsi, en cas de sessions, par exemple, NCache utilise une expiration glissante, qui dit essentiellement, vous spécifiez un intervalle et dites 10 minutes, 20 minutes, 5 minutes, vous dites. Donc, pendant ce temps si personne ne touche cet objet NCache supprime cet élément du cache.
Ainsi, l'expiration glissante, bien que le nom soit toujours expiration, sert un objectif totalement différent. C'est l'expiration absolue dont vous avez besoin pour la mise en cache des données d'application afin de garder le cache à jour. Presque chaque cache a l'expiration absolue. Y compris Redis, tout le monde l'a.
Synchroniser le cache avec la base de données
Mais le problème avec l'expiration absolue est que vous ne faites qu'une supposition. Et si cette supposition est fausse et que les données changent réellement dans la base de données. Alors que se passe-t-il ? Il faut trouver un mécanisme. Donc, vous savez, si vous avez la capacité de synchroniser le cache avec la base de données où vous pouvez indiquer au cache de surveiller la base de données pour les modifications de cet ensemble de données très spécifique, quel qu'il soit.
NCache, par exemple, utilise cette fonctionnalité de dépendance de cache SQL ADO.NET. Où, si vous le précisez, si vous utilisez cette fonctionnalité, laissez-moi vous montrer comment elle est utilisée. Si vous utilisez cette fonctionnalité, alors NCache surveille la base de données et il demande à la base de données de notifier NCache lorsque ces données changent. Donc, disons, j'ai l'exemple de dépendance SQL. Donc, encore une fois, je fais le même cache.Add, ici. Donc, je fais le même cache.Add. J'ai une clé. Maintenant, au lieu d'avoir l'objet, j'ai un élément de cache qui est une structure qui contient l'objet réel ainsi que quelques autres éléments. Ainsi, par exemple, il contient une instruction SQL d'une seule ligne dans la table product. Depuis, je mets en cache un produit dans une base de données Northwind, cette instruction SQL, NCache puis utilisez-le.
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, il y a un SQLCacheDependency classe dans NCache qui est notre propre classe mais dans les coulisses, il est ensuite mappé à la dépendance de cache SQL ADO.NET. Maintenant, vous faites cet appel sur le réel et donc, vous faites l'appel, vous devez appeler ici. Et cet appel arrive sur les serveurs de cache et le serveur de cache effectue maintenant l'appel ADO.NET sur votre base de données de serveur SQL. Et maintenant, le serveur de cache devient un client de votre base de données. Et, il dit à la base de données, il dit, s'il vous plaît, informez-moi si cet ensemble de données change.
Et, le serveur SQL a le type de mécanisme de notification de base de données d'Oracle. Au moins contre ces deux bases de données, vous pouvez utiliser cette fonctionnalité. Et, la dépendance au cache SQL vous permet essentiellement de vous assurer que si vous ne pouvez pas vous deviner, vous pouvez toujours être assuré que vos données resteront cohérentes avec la base de données.
Des questions à ce sujet ? Donc, vous avez des composants de framework. Alors, NCache a également un plugin pour EF, EF6 et maintenant EF Core également, jusqu'à EF Core. Avant EF Core, EF n'avait pas vraiment d'architecture enfichable. Nous avons donc dû implémenter un fournisseur ADO.NET personnalisé et mettre en cache les requêtes SQL.
SQL Core est une architecture beaucoup plus flexible. Nous sommes donc maintenant en mesure de fournir un cache L2. NHibernate, ce qui existe depuis longtemps. NHibernate a cette architecture depuis très longtemps. NCache a fourni le cache L2 pour NHibernate et également pour Hibernate pour le client Java. Mais maintenant, EF Core a cette architecture. Ainsi, l'avantage d'EF Core est que vous n'avez pas à passer ces appels. L'inconvénient est bien sûr qu'il s'agit d'un très petit sous-ensemble du cache que vous utilisez, en termes de fonctionnalités. Parce que toutes ces autres choses, par exemple, la partie dépendance SQL est quelque chose qui NCache fournit et vous pouvez le configurer via les fichiers de configuration, mais également de nombreuses autres fonctionnalités dont je parlerai et que vous devez utiliser. Si vous passez simplement par une architecture enfichable, ils doivent passer par l'approche du dénominateur le plus commun. Ainsi, leur API, quoi qu'ils utilisent, ne peut pas utiliser beaucoup de fonctionnalités sophistiquées, mais maintenant tous les caches les fournissent. Donc, et ils doivent être flexibles pour tout le monde. Alors que, si vous voulez profiter, par exemple, du côté Java, presque tous les caches ont toutes ces fonctionnalités dont je parle. Du côté .NET, presque aucun d'entre eux n'a d'autre que NCache. Donc, ce n'est pas vraiment un NCacheC'est le fait que, vous savez, .NET n'est pas aussi avancé ou aussi mature que la communauté Java dans l'utilisation de ces meilleures pratiques. Donc, ça devient de plus en plus. Le fait que maintenant .NET Core a traversé un si grand changement, est une assez bonne indication de la façon dont les choses vont s'améliorer.
Mais, à ce jour, si vous voulez garder le cache synchronisé avec les expirations de la base de données, ce n'est pas suffisant. Vous devez aller au-delà des expirations. Vous devez synchroniser le cache avec la base de données. Et, si la base de données ne prend pas en charge les notifications, vous pouvez passer en revue l'approche d'interrogation qui est quelque chose qui NCache a mis en place.
Il existe une troisième approche qui consiste à utiliser une procédure stockée CLR pour ajouter directement les données de la base de données au cache. Donc, tout comme vous inversez tout le paradigme. Maintenant, la base de données alimente le cache. Alors, vous savez, par exemple, vous avez un déclencheur qui peut faire que le... Je vais accélérer, sinon je ne pourrai pas terminer tous les sujets. Il s'agit donc d'une fonctionnalité très importante sans laquelle vous ne pouvez vraiment pas bénéficier et vous pouvez également synchroniser le cache avec des sources de données non relationnelles. Par exemple, en cas de NCache il y a une fonction de dépendance personnalisée qui est votre code qui peut passer des appels. Disons que vos sources de données sont un cloud et qu'il s'agit d'une méthode Web appelée à chaque fois, pour savoir réellement quelles sont les données. Ensuite, rien de tout cela ne fonctionne et cette dépendance personnalisée est quelque chose qui fonctionne. Ainsi, la dépendance personnalisée est votre code qui vit sur le cache et est appelé par le cache pour vérifier la source de données.
Ainsi, une fois que vous avez atteint cet objectif, vous pouvez commencer à mettre en cache de plus en plus de données et en tirer vraiment profit. Dépendance DB, parce que je travaille actuellement avec le mainframe, la dépendance SQL ou la dépendance Oracle ne fonctionne pas. Donc, à quelle fréquence une interrogation devrait-elle être, car je travaille avec des données de production avec plusieurs millions de transactions d'enregistrements en une minute. Alors, combien de fois. Alors, comment savez-vous, comme à quelle fréquence l'interrogez-vous ? Le polling est un intervalle paramétrable et c'est votre code qui sera appelé. Ainsi, vous déterminez ensuite dans chaque sondage, la quantité de données que vous allez examiner. Parce que, en cas de dépendance personnalisée, vous allez en fait vérifier une clé spécifique et voir si cette clé a été mise à jour dans votre ordinateur central hérité ou non. Donc, c'est essentiellement pour chaque clé quand ça va comme OK, vérifiez cette clé, vérifiez cette clé. En cas de dépendance personnalisée. En cas de dépendance à la base de données, ce n'est pas une clé, c'est l'ensemble de données complet et nous avons une autre fonctionnalité dans NCache appelé mise à jour des données. Il y a un cache loader, c'est un cache updater qui est un autre service où vit votre code. Donc, il y a une fonctionnalité appelée chargeur de cache dans NCache, dont je n'ai pas réellement mentionné toutes ces fonctionnalités ici, mais il existe une fonctionnalité appelée chargeur de cache qui est votre code qui peut, lorsque vous démarrez le cache, charger le cache, précharger le cache à partir de votre source de données. Donc, cela pourrait être votre ordinateur central. Mais, il existe également une fonctionnalité appelée mise à jour du cache qui appelle automatiquement votre code à chaque intervalle configurable et ce code peut ensuite aller vérifier l'intégralité de la source de données et rechercher des mises à jour en fonction de votre logique personnalisée et des données modifiées ou des nouvelles données s'est produit ou quelles que soient les données supprimées, vous pouvez également mettre à jour le cache. Ainsi, le cache reste synchronisé avec votre source de données. Par défaut, ceux-ci sont appelés à environ 15 secondes d'intervalle. Mais, cela peut être plus rapide. Cela peut être plus fréquent ou moins fréquent, cela dépend de vos besoins. Ai-je répondu à votre question ? J'en ai plus mais je vais sauter ça. On pourra en parler plus tard.
Lecture et écriture
Ainsi, une fois que vous aurez atteint cet objectif, vous commencerez à mettre en cache de plus en plus de données. Ensuite, la prochaine chose est, d'accord, maintenant que vous avez, quels autres avantages pouvez-vous obtenir ? La prochaine chose la plus importante est la lecture continue, écriture continue. Qu'est-ce que la lecture continue ? C'est encore votre code qui se trouve sur le serveur de cache. Donc, quand vous faites un cache.Get, donc, disons, une lecture est votre code, en cas de NCache vous implémentez cette interface appelée IReadThruProvider. Il a trois méthodes.
...
// 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 y a un Init qui est appelé lorsque le cache est démarré, supprimé lorsque le cache s'arrête, mais le plus important est cette charge. Ainsi, la charge s'appelle qu'elle passe. Ainsi, le cache vous appelle cette méthode. NCache appelle cette méthode et passe votre clé. Et, sur la base de cette clé, vous accédez à votre base de données et vous récupérez cet élément. Ainsi, lorsque vous faites cela maintenant, l'effet net sur le client, l'application est, chaque fois que vous faites un cache.Obtenir, le cache contient toujours les données. Bien sûr, si vous ne voulez pas que la lecture soit appelée, vous pouvez également le faire, vous pouvez avoir des détails. Mais, le cache contient toujours les données. Donc, c'est un avantage. Ainsi, vous consolidez votre couche de persistance dans un niveau de mise en cache. Ainsi, si vous avez plusieurs applications utilisant le même niveau de mise en cache, vous savez, l'application devient plus simple car elles n'ont pas à conserver le même code de persistance. Ils font juste un cache.Obtenir et ils obtiennent l'objet domaine ou l'objet entité du cache. Ainsi, le cache ressemble beaucoup plus à un EF maintenant. La lecture elle-même peut être basée sur EF.
L'autre chose que vous pouvez faire avec la lecture est que vous pouvez combiner cela avec les expirations et la synchronisation de la base de données. Alors, que lorsque ces deux choses se produisent au lieu de supprimer ces données du cache, pourquoi ne pas les recharger ? Car, lorsque vous le supprimerez, l'application devra de toute façon le recharger, la prochaine fois qu'elle le voudra. Et, dans de nombreux cas, ces données peuvent être très très fréquemment utilisées. Donc, vous voulez vraiment le recharger dans le cache. Ainsi, une lecture continue non seulement consolide le code, mais améliore également vos performances car votre base de données n'est pas touchée. Dans de nombreuses situations de commerce électronique, les mêmes données peuvent être consultées si fréquemment que dès que vous les supprimez du cache, des milliers de requêtes seront désormais envoyées à la base de données pour les mêmes données et nous avons vu des clients s'en plaindre. Cela se produit si fréquemment car il y a des millions d'éléments de données à mesure que chaque élément de données expire, la base de données est touchée. Donc, dans l'ensemble, même après avoir eu le cache, ils voyaient beaucoup de résultats sur la base de données. Donc, la réponse à cela était de recharger au lieu d'expirer. Ainsi, le rechargement signifie que les données ne quittent jamais le cache, elles sont simplement mises à jour. Ainsi, la base de données n'est jamais touchée, sauf par un appel de base de données effectué par le cache. Ainsi, la lecture est super importante de cette façon.
L'autre est l'écriture continue qui fonctionne exactement comme la lecture continue sauf qu'elle s'occupe de l'écriture. Et, l'écriture signifie qu'il peut s'agir d'un ajout, d'une mise à jour ou d'une suppression. Maintenant, l'écriture a une autre fonctionnalité. L'un des avantages de l'écriture directe est le même que celui de la lecture directe, qui est la consolidation du code.
Écriture derrière
Le deuxième avantage est appelé écriture différée. Vous savez, les mises à jour de la base de données, tout comme les lectures de la base de données, ne sont pas rapides. Les mises à jour de la base de données ne sont pas non plus rapides. Donc, si vos données ne sont pas si sensibles, si ce n'est pas quelque chose que vous devez attendre que la base de données soit mise à jour, vous pouvez simplement mettre à jour le cache. Ainsi, toutes les instances d'application ont maintenant les mêmes données et laissent le cache mettre à jour les données dans la base de données de manière asynchrone. Et, soudainement, les performances de votre application s'améliorent car vous n'attendez pas que le cache soit mis à jour. Donc, écrire derrière a cet avantage supplémentaire. Ainsi, il construit la file d'attente. En cas de NCache cette file d'attente est répliquée sur plusieurs serveurs, mais encore une fois, la lecture en écriture est une fonctionnalité très importante. Et, c'est aussi quelque chose qui est votre code qui vit sur le serveur de cache.
Je veux que vous gardiez cela à l'esprit tout ce chargeur de cache, le programme de mise à jour, la dépendance personnalisée, la lecture, l'écriture, tout ce qui est du code serveur qui y vit. Ce qui est quelque chose qui… encore une fois, ces fonctionnalités existent également du côté Java. Donc, ce n'est pas seulement quelque chose qui NCache inventé mais vous n'obtiendrez ces fonctionnalités dans aucun des autres caches de base .NET.
Donc, une fois que vous avez commencé, une fois que vous avez tout cela, une fois que vous faites cela, maintenant vous mettez beaucoup de données dans le cache. Commence vraiment à en profiter. Et, si un cache n'est qu'un accès à la valeur clé, vous savez, ce n'est pas très très convivial. Ainsi, un cache doit permettre des moyens conviviaux de récupérer des données.
Regroupement de données
Ainsi, en cas de NCache il y a beaucoup de données que vous pouvez faire vous pouvez faire groupe et sous-groupe, étiquettes, étiquettes de nom. Vous pouvez également effectuer une recherche basée sur SQL ou LINQ. Donc, vous pouvez faire quelque chose comme, 'SÉLECTIONNER LES CLIENTS OÙ CLIENT.VILLE = NEW YORK'. Et, maintenant, soudainement, beaucoup de vos ensembles de données, en particulier les données de référence que vous devez lire encore et encore de manière plus filtrée, vous pouvez les récupérer directement à partir du cache. Et, maintenant, vous avez l'avantage que les données que vous souhaitez faire.
Une chose à garder à l'esprit, chaque fois que vous effectuez une recherche SQL, l'ensemble de données complet doit exister dans le cache. Parce que cela n'ira pas dans la base de données. Ainsi, il ne recherchera que le cache. Disons, si vous avez dit donnez-moi tous les clients basés à New York. Si tous les clients ne sont pas dans le cache, si tous les clients de New York ne sont pas dans le cache, le NCache ou tout cache ne vous donnera pas les données correctes. Donc, c'est une chose importante à garder à l'esprit que les gens confondent souvent bien si je cherche, si je m'attends, si ce n'est pas dans le cache, nous irons le chercher dans la base de données. Mais les requêtes SQL ne sont pas les requêtes SQL de la base de données. Ce sont les propres requêtes du cache.
Maintenant, beaucoup de données, vous pouvez conserver l'ensemble des données dans le cache, en particulier les données de référence et c'est là que vous les utiliseriez. Mais, au moins dans les données transactionnelles également, il existe des sous-ensembles qui peuvent être entièrement conservés dans le cache. Alors, c'est comme ça que vous attendez. Donc, en gardant tout cela à l'esprit, vous commencez maintenant à bénéficier du cache.
Cache Client
Je vais entrer dans une autre chose qui est cette fonctionnalité appelée Cache Client. L'une des choses qui choquent vraiment les gens lorsqu'ils commencent à utiliser un cache distribué, c'est que s'ils utilisaient auparavant un cache In-Proc, c'est-à-dire autonome, c'est que leurs performances chutent. Ainsi, de nombreux clients nous appellent et disent, vous savez, vous disiez cela, les performances vont augmenter, l'évolutivité va s'améliorer, nos performances ont en fait chuté. Et la raison en est qu'au départ, ils n'avaient qu'un cache autonome. Il était limité en taille mais le cache était sous forme d'objet, les objets étaient conservés sur votre tas et maintenant ils doivent aller dans un cluster de cache, il y a une sérialisation, une désérialisation, il y a eu un voyage réseau, c'est beaucoup plus lent.
Donc, pour résoudre ce problème, de nombreux caches, encore une fois, j'utilise le mot beaucoup parce que tous les caches côté Java l'ont, le côté .NET NCache a-t-il. Ils ont cette fonctionnalité appelée cache client. Du côté Java, cela s'appelle le cache proche. Il s'agit du même cache autonome que vous aviez auparavant, même signifie similaire, mais il est maintenant conscient du fait qu'il fait partie de ce cache en cluster. Ainsi, quelles que soient les données qu'il conserve, il les synchronise avec le cluster de cache. Ainsi, il se branche simplement sans que vous ne fassiez de programmation.
Ainsi, avec l'aide d'un cache client, vous pouvez obtenir ces performances de cache autonome In-Proc et c'est vraiment bon pour beaucoup de données où vous faites beaucoup plus de lectures que d'écritures. Vous ne voulez pas l'utiliser pour quelque chose comme des sessions. Parce que, dans les sessions, vous faites une lecture et une écriture. Donc, vous devez faire beaucoup plus de lectures que d'écritures pour en bénéficier.
Cluster de cache dynamique
Donc, sur le plan architectural, vous savez, vous devez voir que le cache est comme la base de données maintenant. Il vit dans votre datacenter, votre environnement de production et si votre application a un besoin de haute disponibilité alors le cache doit également être hautement disponible, sinon vous savez, vous avez un problème. Et, la seule façon de le faire est que le cache garantisse une disponibilité à 100 %. Donc, une bonne cache, en cas de NCache il a une cluster de cache dynamique. C'est une architecture peer-to-peer. Vous pouvez ajouter ou supprimer n'importe quel serveur et tout va bien, rien ne s'arrête. Le cache ne s'arrête pas, l'application ne s'arrête pas.
Évolutivité linéaire avec réplication
Donc, nous avons parlé de la partition et ensuite de la topologies déjà. La réplication doit être faite intelligemment. Ainsi, en cas de réplique de partition, il ne fait qu'une seule copie. Ainsi, les données n'existent qu'à deux endroits et pas plus de deux car chaque fois que vous faites des copies, cela coûte plus de temps ou d'efforts. Cela ralentit les choses.
Réplication WAN du cache distribué
Il existe également une fonctionnalité appelée Réplication WAN. Beaucoup de gens ont maintenant plusieurs centres de données. Si vous vous attendez à ce que votre base de données puisse gérer plusieurs centres de données, pourquoi pas le cache ? C'est une fonctionnalité que la plupart des caches Java ont, NCache l'a aussi mais seulement du côté .NET.
NCache vs. Redis
Juste rapidement une dernière chose qui est, puisque, du côté de .NET, vous savez, il n'y a vraiment que deux options. L'un est NCache, l'un est Redis. Redis en fait, il s'agit plutôt d'un cache basé sur Linux, mais depuis que Microsoft s'est associé à eux sur Azure, ils sont certainement devenus beaucoup plus populaires. Donc, je voulais donner comme une comparaison juste.
Soit dit en passant, si vous allez simplement sur notre site Web et que vous allez à la pages de comparaisons et aller à comparaison détaillée fonction par fonction sur la base de leur documentation et de notre documentation et voir tout le contenu. Et, ce n'est pas un, vous savez, nous ne crachons pas ça du tout et vous pouvez en être un bon juge vous-même. C'est juste pour faciliter la préparation de votre travail.
Mais, ils sont tous les deux open source mais NCache est natif .NET pour les personnes .NET, vous savez, toute votre pile est .NET. NCache vous permet d'avoir du code .NET côté serveur que vous ne pouvez pas faire avec Redis. Et, vous savez, si vous êtes sur Azure, Redis est disponible uniquement en tant que cache en tant que service, alors que nous n'avons intentionnellement pas choisi ce modèle. Car, dans le cache as a service, le cache est une boîte noire. Ainsi, vous ne disposez d'aucune des fonctionnalités côté serveur dont nous venons de parler. Et avec le modèle VM, vous avez un contrôle total.
La plupart de nos clients sont des entreprises haut de gamme qui ne veulent vraiment pas abandonner leur contrôle. C'est comme la base de données SQL contre le serveur SQL. Donc avec NCache, vous savez, vous contrôlerez tout votre environnement et comme vous l'avez vu, c'est assez simple à faire. Mais, vous obtenez toutes ces fonctionnalités côté serveur avec NCache, ce que vous ne faites pas car avec Redis parce que vous n'avez aucun accès.
Donc, encore une fois, décidez-vous, mais utilisez au minimum un cache distribué dans votre architecture. Assurez-vous qu'il est prêt à être mis à l'échelle. C'est tout l'objectif. Merci beaucoup.