DEVintersection 2016

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é

Vue d’ensemble

Bonjour tous le monde. 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. NCache est notre produit phare qui est un cache distribué et c'est mon sujet aujourd'hui. Mon sujet ne concerne pas NCache aujourd'hui, sa mise en cache en général. NosDB est un autre produit que nous avons, c'est une source ouverte NoSQL database pour .NET. Je vais utiliser Azure pour démontrer le cache distribué afin que vous puissiez voir comment il est réellement utilisé.

Ainsi, le sujet d'aujourd'hui est la mise à l'échelle des applications .NET pour la mise en cache distribuée. Je préfère avoir une discussion plus interactive. Donc, pendant que je parle, si vous avez une question, veuillez lever la main. Donc, nous pouvons en parler à ce moment-là au lieu d'attendre la fin. Je trouve que cela rend la conversation beaucoup plus significative.

Alors, laissez-moi commencer. D'accord! Nous allons donc passer en revue quelques définitions. Je suis sûr que la plupart d'entre vous le savent déjà, mais c'est à des fins d'achèvement.

Évolutivité

La première définition est l'évolutivité. L'évolutivité est une performance d'application élevée sous des charges de pointe. Donc, si vous avez, disons, une application ASP.NET ou n'importe quelle application .NET qui fonctionne très rapidement, avec, disons, cinq utilisateurs, ce n'est pas nécessairement évolutif. Bien sûr, s'il ne fonctionne pas rapidement avec cinq utilisateurs, vous rencontrez d'autres problèmes que celui-ci. Mais la plupart des applications fonctionnent très rapidement avec cinq utilisateurs, mais c'est lorsque vous passez à 5,000 50,000, 500,000 XNUMX ou XNUMX XNUMX utilisateurs que les choses commencent vraiment à s'effondrer. Ainsi, si vous souhaitez que votre application soit évolutive, elle doit fonctionner sous des charges de pointe.

Évolutivité linéaire

L'évolutivité linéaire signifie que votre architecture d'application, votre stratégie de déploiement, si elle est effectuée de manière à ce que l'ajout de serveurs vous donne une capacité incrémentielle de gérer plus de transactions que vous, est évolutive de manière linéaire.

Cela signifie que si vous aviez deux serveurs et si vous ajoutez, disons, un millier d'utilisateurs avec un serveur à trois, vous devriez avoir 1500 utilisateurs ou quelque chose comme ça.

Évolutivité non linéaire

Mais, si votre application si votre architecture ou votre déploiement n'est pas linéairement évolutif, cela ressemblera plus à une courbe logarithmique qui monte et descend, ce qui signifie qu'après un certain point, cela n'a pas vraiment d'importance si vous ajoutez plus de serveurs.

Cela ralentira les choses. Si vous avez plus de transactions, vous ne pouvez tout simplement pas sortir. Vous ne pouvez pas vous racheter de ce problème. Donc, vous voulez non seulement une évolutivité, mais une évolutivité linéaire.

Quelles applications ont besoin d'évolutivité ?

Les applications suivantes sont celles qui ont généralement ces types de problèmes. Ce sont des applications Web ASP.NET, ce sont des services Web, ce sont des back-end Internet IOT qui sont généralement aussi des services Web, vous pouvez avoir un traitement de données volumineuses qui n'est généralement pas si courant dans .NET, mais le traitement de données volumineuses est aussi quelque chose qui doit évoluer ou toute autre application serveur. Vous pouvez être une institution financière qui a une exigence de conformité pour traiter un certain nombre de transactions.

Ainsi, vous pouvez avoir une application serveur qui a une exigence de conformité pour, disons, si vous êtes une application de virement bancaire, vous devez virer les fonds pour le jour ouvrable suivant ou à une certaine heure. Vous devez donc être en mesure de traiter de plus en plus de transactions. Donc, si vous avez l'une de ces applications, vous êtes au bon endroit.

Le problème de l'évolutivité

Alors, définissons le problème d'évolutivité. La plupart d'entre vous savent que vos architectures d'application aujourd'hui, si vous avez une application ASP.NET ou de services Web, l'architecture des échelles de niveau d'application varient de manière linéaire. Ainsi, vous pouvez ajouter plus de serveurs, il n'y a généralement pas de problème. Le problème est vraiment avec votre stockage de données et, quand j'utilise le mot stockage de données, je veux dire les bases de données relationnelles et l'ordinateur central. Il existe des données héritées. Tout magasin de données que vous utilisiez traditionnellement et qui devient un goulot d'étranglement et lorsqu'il devient un goulot d'étranglement, vous avez ce problème. Le NoSQL databases, j'étais censé dire qu'ils ne sont pas toujours la réponse. Mais NoSQL mouvement a commencé en partie à cause de cela. Comme les bases de données relationnelles n'étaient pas évolutives, NoSQL databaseLes s sont évolutifs, mais ils ne conviennent pas à toutes les situations car, vous savez, ils vous obligent à déplacer toutes vos données de votre base de données existante vers une NoSQL database ce que vous pouvez faire pour beaucoup de nouvelles données, mais les données commerciales traditionnelles, vos clients, leurs comptes, toutes ces données doivent rester relationnelles à la fois pour des raisons commerciales et pour des raisons techniques. Les raisons techniques sont bien sûr qu'une base de données relationnelle a un écosystème qui n'est égalé par aucun NoSQL database et les raisons professionnelles sont bien entendu de même nature.

Ainsi, le NoSQL database n'est pas toujours la réponse et même si nous avons NoSQL database produit que nous vendons s'appelle NosDB, qui est utilisé uniquement comme une extension des bases de données relationnelles. Donc, vous ne pouvez pas sortir des bases de données relationnelles. Les bases de données relationnelles sont là pour rester. Donc, vous devez vivre avec cette réalité. Vous devez donc résoudre l'évolutivité avec des bases de données relationnelles toujours présentes.

La solution d'évolutivité

La solution est bien sûr que vous devez utiliser un cache distribué en mémoire. NCache est une de ces solutions. C'est un cache distribué open source. Nous sommes le plus ancien cache distribué .NET du marché. Nous existons depuis 10 ans, en fait 11 maintenant. Et nous sommes le seul cache .NET vraiment natif.

La plupart d'entre vous ont entendu parler Redis, à droite? Donc, il y a plus de 2 ans, nous n'avions jamais entendu parler de Redis parce qu'ils n'étaient vraiment pas concentrés là-dessus. Ce n'est que lorsque Microsoft a conclu un partenariat avec eux pour Azure.

Déploiement de cache distribué

L'avantage d'un cache distribué en mémoire est que vous pouvez l'utiliser avec vos bases de données existantes. Ainsi, vous pouvez résoudre ce problème que vos bases de données relationnelles vous fournissent via un cache distribué en mémoire. Alors, comment résolvez-vous ce problème? Vous résolvez ce problème en, voyons cette image ici.

Ainsi, vous avez un niveau d'application qui comprend vos applications Web, votre service Web, toute autre application serveur et vous pouvez ajouter plus de serveurs ici. Pour les applications Web et les services Web, il existe généralement un équilibreur de charge que je n'ai pas dessiné ici. Ainsi, vous pouvez ajouter plus de serveurs à cette couche. Vous ne pouvez pas ajouter d'autres serveurs au niveau de la couche de base de données. Oui! Vous pouvez ajouter d'autres serveurs dans le NoSQL couche, mais, comme je l'ai dit, ce n'est pas toujours la réponse. Donc, vous devez résoudre ces deux cases. Ainsi, vous placez un cache distribué en mémoire entre le niveau application et la base de données.

Le cache distribué forme généralement un cluster. Ainsi, tous les caches distribués ne forment pas un cluster. Memcached n'a jamais formé de cluster même s'il s'agissait d'un cache distribué. Redis forme un cluster, NCache forment définitivement un cluster. Un cache distribué forme ici un cluster de deux serveurs ou plus. La raison pour laquelle je dis deux est à des fins de redondance et de réplication et pour beaucoup d'autres et aussi à des fins d'évolutivité. Si vous n'avez besoin que d'un seul serveur de cache, vous n'avez probablement pas besoin d'un cache distribué. Donc, vous devriez avoir un minimum de deux serveurs de cache ici et ce cluster de cache regroupe en fait la mémoire et les ressources CPU de tous les serveurs de cache en une seule capacité logique. Cela signifie que lorsque vous ajoutez plus de serveurs, vous obtenez plus de mémoire, plus de traitement CPU et plus de capacité de carte réseau. Ce sont les trois goulots d'étranglement à l'évolutivité ; mémoire, CPU et carte réseau. La carte réseau de nos jours est… un gigabit ou dix gigabits est à peu près standard. C'est assez difficile pour un maximum d'une carte gigabit ou dix gigabits à moins que la taille de vos objets ne soit grande. Mais, si la taille de vos objets est grande, grande signifie des centaines de kilo-octets par objet, il est alors assez facile de maximiser une carte réseau si vous avez beaucoup de trafic. Mais, si vous avez plus de serveurs et bien sûr plus de cartes réseau, la mémoire est la même.

La raison pour laquelle il s'agit d'un cache distribué en mémoire est que la mémoire est beaucoup plus rapide que le disque et c'est ce qui ajoute vraiment de la valeur. C'est plus rapide, c'est plus évolutif. Ainsi, l'objectif ici est de capturer environ 80 % de l'accès aux applications allant au cache distribué. Donc, il ne restera que 20% pour aller dans la base de données.

Beaucoup de gens ont d'abord vu la mise en cache comme une amélioration des performances. Oui! C'est une amélioration des performances car la mémoire est plus rapide que cela. Mais plus important encore, c'est un besoin d'évolutivité car vous ne pouvez pas évoluer sans quelque chose comme ça dans votre infrastructure. En fait, de plus en plus d'entreprises en font presque une norme, tout comme elles auront une base de données dans leur environnement d'application, elles auront également un cache distribué. Certaines personnes l'appellent grille de données en mémoire qui est du côté Java, c'est un terme. Certaines personnes l'appellent un peu de Data Fabric, mais le cache distribué est le nom le plus courant pour l'écosystème .NET. C'est donc une infrastructure. Une fois que vous l'avez en place, vous pouvez l'utiliser comme un outil vraiment puissant. Le rapport entre les serveurs d'applications et le niveau de mise en cache est généralement d'environ 4:1, 5:1, en supposant qu'il s'agit de serveurs assez chargés en termes de transactions. Vous pouvez aller plus de 5:1 également en fonction de la nature de ceux-ci. Et, un serveur de cache typique est d'environ 16 Go à 32 Go de mémoire et de type de configuration quadricœur à double processeur. Donc, pas une box très haut de gamme. En fait, vous ne voulez pas une boîte très haut de gamme dans cette couche. Vous voulez plus de boîtes que quelques boîtes très haut de gamme. Si vous ajoutez plus de mémoire, vous pouvez aller jusqu'à 128 ou 256 Go de mémoire, mais plus de mémoire signifie que vous devez disposer d'un processeur plus puissant. Pourquoi donc? Parce que, si vous avez plus de mémoire, votre tas est plus grand, votre récupération de place va être une tâche beaucoup plus importante et la récupération de place n'est pas la chose la plus rapide dans .NET et elle consommera votre CPU. Ainsi, vous ressemblez de plus en plus à une base de données. Donc, il est préférable d'avoir 16 à 32 Go, c'est un assez bon sweet spot par serveur de cache. Une question jusqu'à présent ?

NCache Chiffres d'évolutivité

Voici les chiffres d'évolutivité de NCache. Différents caches auraient des numéros différents, mais l'objectif est de rendre cela aussi évolutif. Ainsi, les lectures s'échelonnent de cette manière, les écritures s'échelonnent. Les lectures sont plus lentes que les écritures car la réplication se produit avec les lectures. Je vais parler de ces capacités.

La raison pour laquelle vous avez besoin de réplication est que la mémoire est volatile. Ainsi, si un serveur tombe en panne, vous perdrez ces données. Donc, vous ne voulez pas perdre ces données dans de nombreux cas.

Utilisations courantes du cache distribué

Jusqu'à présent, le but de la discussion était de vous montrer pourquoi vous avez besoin d'une mise en cache distribuée. Et, maintenant que nous avons établi ce cas, parlons de ce pour quoi vous allez utiliser un cache distribué.

Mise en cache des données d'application

Le cas d'utilisation le plus courant est ce dont je parlais, à savoir la mise en cache des données d'application. Vous cachez les données qui existent dans votre base de données, ici même. Ainsi, vous en cachez autant que vous le pouvez, puis vous améliorez vos performances et votre évolutivité.

La principale chose à remarquer dans le cas d'utilisation de la mise en cache des données d'application est que les données existent à deux endroits. Un dans la base de données, un dans le cache. Chaque fois que cela se produit, quelle est la première préoccupation qui vous vient à l'esprit, qu'est-ce qui pourrait mal tourner s'il existait à deux endroits ? Oui, cohérence !

Il est donc très important qu'un bon cache distribué gère cela. Parce que, si un cache n'est pas capable de gérer le fait que les données doivent être cohérentes aux deux endroits, vous êtes obligé de mettre en cache plus de données en lecture seule. Les données en lecture seule représentent environ 10 % à 15 % ou 20 % des données. La majorité des données sont ce que j'appelle des données transactionnelles. Ce sont vos clients vos comptes. Ce sont des données qui changent. Il peut changer toutes les quelques secondes, bien que la plupart du temps, il puisse changer toutes les deux minutes. Ainsi, même si vous pouviez le mettre en cache pendant une minute ou 30 secondes, vous bénéficieriez toujours du fait que vous le lirez plusieurs fois et si vous multipliez cela par le nombre total de transactions qui se produisent au cours d'une journée donnée, vous avez des millions de transactions. qui ne vont plus dans la base de données. Il est donc très important que pour la mise en cache des données d'application, un bon cache distribué gère cette cohérence et je passerai en revue les fonctionnalités qui sont vraiment importantes pour avoir cette cohérence. Ainsi, la mise en cache des données d'application met en cache les données permanentes. Les données permanentes signifient qu'elles existent en permanence dans votre base de données.

Mise en cache spécifique à ASP.NET

Le deuxième cas d'utilisation est que si vous avez une application ASP.NET, cela s'applique bien sûr également à d'autres applications Web, mais je me concentre sur .NET. Vous pouvez mettre en cache votre état de session, votre état d'affichage, si vous n'utilisez pas le framework MVC et vous pouvez mettre en cache votre sortie, la sortie de la page. Toutes ces données sont de nature temporaire. Ce n'est pas permanent. Toute donnée qui n'est pas permanente ne devrait pas vraiment exister dans la base de données. C'est une donnée transitoire.

Lorsque les données sont transitoires, lorsqu'elles sont temporaires et qu'elles n'existent pas dans la base de données, elles n'existent que dans le cache, quelle est la plus grande préoccupation qui vous vient à l'esprit et qu'est-ce qui pourrait mal tourner ? Persévérance… Ou absence de persistance. Donc, si vous ne persistez pas, vous perdez des données. Que se passe-t-il si ce serveur de cache tombe en panne et que vous avez ce panier ou quoi que ce soit et disons que vous êtes une compagnie aérienne et que votre client vient de faire cette recherche de vol et qu'il va acheter 10 billets ou quatre billets d'une valeur d'au moins 5,000 XNUMX $ et la dernière page qu'ils disent soumettre ou quelle que soit la dernière page et tout à coup la session est terminée parce que le serveur de cache est tombé en panne et ils doivent tout recommencer. Toute l'activité est perdue. Vous risquez de perdre ce client. Pas une très bonne expérience.

Ainsi, tout ce que vous cachez qui est transitoire, le cache doit être répliqué. Tout cache qui ne fait pas de réplication n'est pas un cache viable. Et, la réplication a un coût, donc le cache doit faire une réplication efficace et efficiente. L'état de session est un cas d'utilisation très courant pour un cache distribué car les sessions sont très courantes dans ASP.NET.

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

Le troisième cas d'utilisation courant ou troisième qui n'est en fait pas très connu est appelé partage de données d'exécution. C'est, si vous avez plusieurs applications qui doivent partager. Une application produit quelque chose ou met à jour quelque chose, qu'une autre application ou une autre instance de cette application doit utiliser. Habituellement, vous utiliseriez traditionnellement des files d'attente de messages pour cela ou vous placeriez simplement ces données dans la base de données et l'autre application les extraira. Mais, un cache distribué est très bon pour ce cas d'utilisation. Il n'est pas là pour remplacer les files d'attente de messages. Les files d'attente de messages ont leur autre utilisation, mais si votre application s'exécute dans le même centre de données, toutes les instances et elles doivent partager des données, il s'agit d'une plate-forme de données ou de partage de données beaucoup plus évolutive car toutes les applications sont connectées à la même plate-forme et cela la plate-forme peut déclencher des événements, dans un modèle Pub/Sub. Pub signifie qu'une application est l'éditeur, ils publient quelque chose et déclenchent un événement. Tous les abonnés en seront informés et ils consommeront ces données.

Il existe également d'autres types de notifications. Lorsque certains éléments sont modifiés, votre candidature peut montrer de l'intérêt pour certains éléments et si cet élément change, prévenez-moi. Ou il y a un requête continue caractéristique qui NCache a qui est comme un Dépendance SQL fonctionnalité dans SQL Server, où NCache vous permet de dire un type de requête SQL qui dit SELECTS Clients WHERE Clients.Ville = "New York". Ainsi, si un client avec ce critère a déjà ajouté, mis à jour ou supprimé du cache, notifié.

C'est donc un moyen beaucoup plus intelligent de surveiller les modifications apportées au cache. Ainsi, toutes ces choses vous permettent de partager des données entre les applications de manière très rapide et évolutive lors de l'exécution. Et, ce sont aussi des données transitoires, bien que beaucoup de ces données existent dans la base de données, mais la forme sous laquelle vous les partagez n'existe probablement pas. Donc, c'est transitoire. Donc, cela doit également être reproduit. Des questions jusqu'à présent ? Soit vous connaissez déjà complètement ce genre de choses, soit je suis super bon.

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

Alors, passons en revue et voyons du code source en termes de comment… quelles sont les fonctionnalités que vous devez utiliser et comment les utiliser. je vais utiliser NCache comme exemple, mais comme je l'ai dit, je me concentre davantage sur les fonctionnalités réelles.

Voici une manière typique d'utiliser n'importe quel cache.

Customer Load(string customerId)
{
    // Key format: Customer:PK:1000
    string key = "Customers:CustomerID:" + customerId;
    
    Customer cust = (Customer) _cache[key];
    
    if (cust == null)
    {
        // Item not in cache so load from db
        LoadCustomerFromDb(cust);
        // Add item to cache for future reference
        _cache. Insert(key, cust);
    }
    return cust;
}

Vous chargeriez un client à partir d'une base de données. Avant d'accéder à la base de données, vous vérifierez le cache et vous utiliserez la clé, une clé basée sur une chaîne. Disons Clients : ID client et l'ID client réel est peut-être 1000 ou quelque chose et vous dites vérifier le cache. Si vous l'avez dans le cache, pas besoin d'aller dans la base de données, vous l'avez. Si vous ne l'avez pas dans le cache, vous allez dans la base de données, vous chargez ce client et vous le mettez dans le cache. Lorsque vous le mettez dans la cache, la prochaine fois que vous venez, vous ou quelqu'un d'autre venez, vous le trouverez dans la cache. Donc, c'est un paradigme très simple. Une fois que vous avez fait cela, tout le monde peut trouver des choses qui valent plus que la cache.

Bien sûr, il existe de nombreuses autres fonctionnalités que vous pouvez pré-remplir dans le cache avec de nombreuses données dont vous pensez qu'elles sont nécessaires de toute façon. Ainsi, vous économiserez une grande partie des accès à la base de données à l'avance, puis vous continuerez à ajouter progressivement des données au cache qui ne se trouvent pas dans le cache. Par exemple, voici un projet de studio visuel. Si vous deviez utiliser NCache vous relieriez deux de ces assemblages. L'un est NCache.Durée et l'un est NCache.La toile. Vous utiliserez ici deux des espaces de noms de la même manière NCache.Durée ainsi que NCache.Web.Caching. Nous avons nommé nos espaces de noms pour qu'ils soient assez proches du cache ASP.NET. Donc, que vous savez, quand NCache est sorti le cache ASP.NET était le seul cache disponible. Donc, vous avez ceci et au début de votre application, il s'agit bien sûr d'une application console, la vôtre sera différente. Vous vous connecterez au cache et vous obtiendrez un handle de cache. Chaque cache est nommé et vous avez un handle de cache, puis vous ajoutez vos objets au cache. Alors, disons, vous venez d'ajouter, vous faites cache.Ajouter ici. Vous spécifiez votre clé. Bien que cela ne devrait probablement pas être David Jones, il devrait s'agir d'un identifiant client quelconque, puis vous avez l'objet réel, puis vous avez spécifié des expirations. Et, vous spécifiez les expirations absolues d'une minute. Vous dites qu'après une minute, expirez cet élément du cache. Tout le reste que vous venez de conserver par défaut. Et, plus tard, vous pouvez faire cache.Obtenir et obtenir ce même client d'un autre endroit. Donc, juste de simples opérations de cache.

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

Démonstration pratique

En cas de NCache, tous les caches sont nommés. Je vais maintenant vous montrer rapidement à quoi ressemble un cache puis nous reviendrons sur le code. J'ai configuré un tas de machines virtuelles dans Azure. Ainsi, vous pouvez courir NCache dans Azure, dans Amazon, sur site. Dans tous les cas, les serveurs de cache eux-mêmes ne sont que des VM. Il ne s'agit que de machines virtuelles Windows 2008, 2012. Le client de cache dans Azure peut être soit une machine virtuelle, soit un rôle Web, soit un rôle de travail, soit un site Web.

Créer un cache en cluster

Je me suis connecté au client de démonstration, ici. Je vais maintenant aller vite et créer un cache. Donc, je peux montrer à quoi ressemble le cache. Utilisez cet outil appelé le NCache manager, outil graphique et vous permet… Je vais venir ici et dire qu'il crée un « nouveau cache groupé ».

Toutes les caches dans NCache sont nommés. Donc, je vais juste nommer ma cache. Je vais prendre tout le reste par défaut pour le moment.

Je vais choisir une topologie pour la réplique partitionnée. J'y reviendrai rapidement à la fin de cet exposé. Réplique partitionnée est ma topologie.

Je vais utiliser la réplication asynchrone.

Je vais choisir mon premier serveur de cache qui est demo2. Donc, ce sont deux de mes nœuds de cache.

Je vais cliquer sur Suivant. Je vais prendre toutes les valeurs par défaut. Je vais spécifier la quantité de mémoire que je veux allouer à ce cache. Ainsi, de cette façon, le cache ne consommera pas plus de mémoire que cela. Je viens de donner un concert mais bien sûr le vôtre va être beaucoup plus important. C'est la taille d'une partition.

Ainsi, une fois que le cache utilise autant de mémoire, le cache est plein. Donc, soit il rejettera tout nouvel élément, soit il expulsera certains des éléments existants. Donc, je vais dire, évincez 5% du cache à ce sujet et je dirai que l'utilisation la moins récente est l'algorithme à utiliser et je viens de créer le cache.

Je vais continuer et ajouter un client à cela.

Donc, je viens de créer un cache et nous allons démarrer le cache.

Simuler le stress et surveiller les statistiques du cache

Je vais choisir les statistiques, donc je peux utiliser des statistiques PerfMon. Je vais également surveiller le cluster. Donc, je viens de démarrer le cache. Ce cache est appelé cache de démonstration. Je vais juste tester rapidement. Donc, je viens d'exécuter un outil de test de résistance fourni avec NCache et vous permet de tester rapidement le cache dans votre propre environnement.

Donc, ce cache fonctionne maintenant. Donc, ce qui se passe, c'est que, sur la boîte du client, et le client signifie leur boîte de serveur d'applications, j'ai un fichier de configuration, juste ici. Donc, je viens de créer un cache et il sait maintenant quels sont les serveurs de cache. Maintenant, laissez-moi revenir au code. Donc, quand j'ai choisi ce nom de cache, c'est ce qui s'est réellement passé, mon application s'est maintenant connectée à tous les serveurs de cache du cluster et m'a donné un descripteur de cache, de sorte que lorsque je fais un cache.Ajouter, il va en fait l'ajouter à l'endroit approprié dans le cache et également faire la réplication pour moi, tout cela est fait.

Ainsi, l'API cache tous ces détails, mais je voulais vous montrer à quoi ressemble ce cache dans les coulisses et, à quel point il est facile d'utiliser le NCache dans cette situation. Alors, revenons à notre principal. Voici à quoi ressemblerait l'API.

• Connexion au cache

  ICache cache = CacheManager.GetCache(“myDistributedCache”);
  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");

tu fais un cache.Get, cache.Contient, cache.Ajouter, Insérer, Supprimer. Insérer signifie ajouter s'il n'existe pas sinon mettre à jour.

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

OK, maintenant que nous avons une idée de ce à quoi ressemble un cache, qu'est-ce qu'une simple API. Venons-en à la fonctionnalité dont nous avons parlé. Ce qui est important pour un cache distribué.

Gardez le cache frais

Donc, la première chose que nous avions dite est qu'un cache distribué doit garder les données fraîches, le cache frais. Donc, il y a quatre façons de le faire. Le numéro un est expiration, dont beaucoup de caches ont presque tous les caches, vous permet d'expirer des choses.

Donc, il y a un Expiration absolue et il y a un Expiration glissante. L'expiration absolue est ce que je viens de vous montrer, c'est-à-dire qu'il est dit d'expirer cet élément, disons dans cinq minutes, peu importe ce qui se passe. Et, la raison pour laquelle je dis cela est parce que, comme je l'ai dit, ces données existent dans la base de données et je ne peux lui faire confiance que pendant cinq minutes qu'elles ne seront pas modifiées dans la base de données. Je ne veux pas le conserver plus longtemps dans le cache car il pourrait changer dans la base de données. Donc, vous faites une supposition sur la nature des données. Certaines données peuvent être mises en cache pendant des heures et des jours. Vous savez, cela peut être vos tables de consultation. Peut-être que vos prix changent une fois par jour ou quelque chose comme ça. Ainsi, vous pouvez le mettre en cache pendant 24 heures.

Les autres données sont vos données transactionnelles. Vous ne pouvez le mettre en cache que pendant peut-être 30 secondes ou une minute, car c'est aussi longtemps que vous vous sentez à l'aise. Ainsi, l'expiration absolue concerne les données permanentes et c'est une façon d'estimer ou de deviner combien de temps est-il sûr de conserver les données dans le cache. C'est très important. Distinction que je veux faire entre les expirations absolues et le glissement.

L'expiration glissante indique essentiellement de supprimer cet élément du cache lorsque personne ne le touche plus, pendant cet intervalle. Toucher signifie récupérer ou mettre à jour. Ainsi, par exemple, un état de session. Lorsque vous vous déconnectez, un état de session n'est plus touché par personne. Ainsi, après environ 20 minutes, il doit être supprimé du cache.

L'expiration glissante est généralement utilisée pour les données transitoires. Il s'agit plutôt d'une opération de nettoyage. Cela n'a rien à voir avec la mise à jour des données. Il s'agit simplement de s'en débarrasser parce que vous n'en avez plus besoin. Mais l'expiration absolue est ce dont vous avez besoin pour garder les données à jour. Deuxièmement, vous savez, les expirations sont une chose très importante. Chaque cache doit l'avoir et la plupart d'entre elles l'ont, en fait je pense que toutes, au moins l'expiration absolue.

Synchroniser le cache avec la base de données

La deuxième caractéristique est quelque chose que la plupart d'entre eux ne font pas. Et c'est là que vous souhaitez synchroniser le cache avec la base de données.

Utilisation des dépendances de base de données

Vous dites, vous savez, je ne peux vraiment pas prédire à quelle fréquence ou quand cela va être mis à jour dans la base de données. Je ne sais pas quand les données seront mises à jour dans la base de données. Parce que j'ai plusieurs applications qui le mettent à jour. Peut-être que d'autres personnes touchent directement les données. Donc, je veux juste que le cache surveille la base de données. Ainsi, le cache doit être conscient de ce changement dans la base de données. C'est une caractéristique qui NCache possède. C'est ce qu'on appelle la dépendance SQL. En fait, il utilise une fonctionnalité de serveur SQL appelée dépendance SQL, où NCache devient client de la base de données.

Laissez-moi vous montrer rapidement à quoi cela ressemble. Donc, si j'ai une cache ici. Donc, encore une fois, de la même manière que nous avons fait les bibliothèques, puis vous vous connectez au cache. Maintenant, lorsque vous ajoutez l'élément au cache, ici. Si je viens ici et que je dis 'AddProductToCacheWithDependency', aller à la définition. Donc, ici, vous dites à ce cache, voici mon instruction SQL.

private static void AddProductToCacheWithDependency (Product product)
{
// Any change to the resulset 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.ProductID);

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

private static string GenerateCacheKey (Product product)
{
string cacheKey = "Product#" + product.productID;
return cachekey;
}

Ainsi, votre instruction SQL reflète généralement cette ligne dans la table. Donc, si vous ajoutez un produit, cette instruction SQL avec l'ID de produit devrait être égale à ceci. Donc, vous créez cette instruction SQL pour SQL Server. Parce que c'est ce que vous transmettez dans le cadre de la dépendance SQL à SQL Server. Vous le passerez à NCache. Donc, vous sur la boîte client transmettez ceci à NCache. Donc, vous spécifiez ceci comme votre instruction SQL. Vous créez un objet 'cache Item' et dans l'élément de cache, vous spécifiez la 'SQLServer Dependency'. Alors, SQLCacheDependency est une classe de NCache, réellement. Ce n'est pas la même chose que la dépendance du serveur SQL. Cela a la sorte du même nom à l'exception de la dépendance du cache SQL. Cela conserve cette instruction SQL, vous le spécifiez et vous ajoutez l'élément au cache. Donc, vous avez fait cela et vous êtes en ce moment assis sur cette boîte, juste ici.

Donc, vous transmettez ceci à NCache. Il va à l'un des serveurs de cache. Ce serveur de cache devient maintenant un client de la base de données. Parce que vous avez également spécifié des informations sur la chaîne de connexion. Quelque part ici, vous spécifiez la chaîne de connexion. Alors, NCache serveur devient un client de votre base de données. Maintenant, cette base de données pourrait être un serveur SQL, cela pourrait être Oracle et NCache établira une connexion de dépendance SQL. Le serveur SQL créera une structure de données dans le serveur SQL qui surveillera l'ensemble de données.

Alors, tout comme NCache avait cette fonctionnalité de requête continue dont j'ai parlé pour le partage de données d'exécution, où NCache surveillait tous les clients, où Client. Ville = "New York". Maintenant, le serveur SQL surveille ce jeu de données dans le serveur SQL et si une ligne correspondant à ce critère est ajoutée, mise à jour ou supprimée de la base de données SQL, le serveur SQL en informe le serveur de cache. Le serveur de cache sait maintenant que ces données ont changé dans la base de données. Donc, il a deux options. Il peut soit le supprimer du cache, ce qui est le comportement par défaut, soit recharger une nouvelle copie.

Utilisation de la lecture/écriture immédiate

La façon dont il rechargera une nouvelle copie est, si vous utilisez un autre futur de NCache appelé lire à travers. Je vais sauter ceci et je devrai y revenir. Donc, il y a une fonctionnalité appelée lecture qui est votre code. Vous implémentez un gestionnaire de lecture et je vais vous montrer le gestionnaire de lecture. Alors, voici un IReadThroughFourni.

{
    // <summary>
    // Contains methods used to read an object by its key from the master data source.
    // </summary>

    public class SqlReadThruProvider : Alachisoft.Ncache.Runtime.DatasourceProviders. IReadThruProvider
    {
        private SqlDatasource sqlDatasource;
        // <summary>
        // Responsible for loading the object from the external data source.
        // Key is passed as parameter.
        // <param name="key">item identifier; probably a primary key</param>
        // <param name="exh">Current expiration hint; you can modify the value and attach a new hint</param>
        // <param name="evh">Current eviction hint; you can modify the value and attach a new hint</param>
        // <returns></returns

        public void LoadFromSource(string key, out ProviderCacheItem cacheItem)
        {
            cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
            cacheItem.ResyncItemonExpiration = true;
            cacheItem.ResyncProviderName = sqlDatasource.ConnString;
        }
        // <summary>
        // Perform tasks like allocating resources or acquiring connections
        // </summary>
        ...

Vous mettez cela en œuvre. Il a une méthode Init qui l'initialise. Une méthode Dispose et en fait comme une méthode Get. Ainsi, le get vous passe la clé et vous lui rendez l'élément de cache. Ainsi, vous accédez à votre source de données et vous chargez cet élément, vous spécifiez l'expiration ou toute autre chose et vous le renvoyez à NCache. Votre code s'exécute sur le serveur de cache. C'est une chose importante à garder à l'esprit.

Ainsi, la lecture s'exécute en fait sur le serveur de cache lui-même. En fait, j'ai un autre schéma.

Ainsi, la lecture s'exécute sur le serveur de cache lui-même. Donc, le serveur de cache doit être développé en .NET pour que votre code .NET s'exécute dessus, n'est-ce pas ? Donc, si votre boutique .NET, si votre application est en .NET, la raison pour laquelle j'ai dit que toute votre pile devrait être .NET pour tous ces avantages.

Ainsi, en venant, par exemple Redis, Redis est un cache basé sur Linux. Donc, c'est un excellent cache, je n'ai rien contre eux mais si vous êtes une boutique .NET, vous devez faire toutes ces choses et votre code doit s'exécuter sur le serveur de cache pour que le cache puisse se synchroniser avec la base de données et recharger automatiquement cet élément à partir de la base de données. Ainsi, votre gestionnaire de lecture est ce qui est appelé lorsqu'une dépendance SQL se déclenche, si vous le souhaitez. Si vous ne le souhaitez pas, il supprimera simplement cet élément du cache. Et, lorsqu'il est supprimé du cache, la prochaine fois que votre application le cherchera, il ne le trouvera pas et il ira le chercher dans la base de données. Maintenant, dans certains cas, par exemple, c'est un catalogue de produits que vous avez mis en cache et dont vous venez de mettre à jour le prix. Pourquoi supprimer le produit du cache, vous venez de mettre à jour le prix ? Parce que, maintenant, l'application doit avoir la logique pour aller l'obtenir à partir de la base de données. Il vaut mieux recharger automatiquement.

Ainsi, une grande partie des données si vous pensez qu'elles seront nécessaires encore et encore, soit à l'expiration, soit lorsque la synchronisation de la base de données se produit, il est préférable de la recharger plutôt que de la supprimer. Parce qu'alors l'application n'a pas à le faire. Plus le cache en fait, plus l'application devient facile. Donc, une autre façon pour le cache de se synchroniser avec la base de données. Donc, si vous n'avez pas de serveur SQL ou Oracle, disons que vous avez MySQL ou DB2, alors ces deux fonctionnalités existent, vous pouvez utiliser la dépendance DB, qui est une autre fonctionnalité de NCache là où NCache regroupe une table spécifique et vous modifiez les déclencheurs de votre base de données pour mettre à jour l'indicateur sur cette ligne. NCache le ramasse et dit que cet article a changé. Donc, j'ai besoin que vous le supprimiez ou le rechargez.

Utilisation des procédures stockées CLR

Les procédures CLR sont un autre moyen de synchroniser le cache avec la base de données. Où vous écrivez réellement un Procédure CLR. Vous l'appelez à partir de votre déclencheur de table. Donc, disons, si vous avez un déclencheur d'ajout ou de mise à jour ou un déclencheur de suppression. Vous appelez cette procédure CLR, elle appelle NCache ou il appelle le cache.

En cas de procédure CLR, vous devez vous assurer que le cache prend en charge les méthodes asynchrones qui NCache Est-ce que. Ainsi, vous pouvez faire dans un cache comme un appel d'insertion asynchrone et le contrôle vous revient immédiatement. Parce que, si vous ne faites pas l'appel asynchrone, vos transactions de base de données commencent alors à expirer. Parce que, vous mettez à jour plusieurs serveurs dans le cache, vous traversez le réseau, ce qui n'est pas ce qu'une transaction de base de données est conçue pour eux. Donc, vous devez avoir un appel asynchrone.

Ce sont donc les trois façons de synchroniser le cache. Ainsi, tout cache que vous avez payé doit vous assurer que vous pouvez conserver les données à jour. Ce sont les deux façons.

Synchroniser le cache avec le non relationnel

De la même manière si vous avez une source de données non relationnelle, disons que vous avez vos données dans le cloud ou à n'importe quel autre endroit. Vous pouvez même vouloir faire un appel de méthode Web. Vous pouvez en fait implémenter une dépendance personnalisée qui est à nouveau votre code qui s'enregistre et s'exécute sur les serveurs de cache et NCache l'appelle et dit s'il vous plaît allez vérifier votre source de données si elle a changé ou non. Vous vérifiez la source de données, si elle a changé, vous le notifiez NCache ces données et la source de données ont changé. Alors, NCache pouvez soit le supprimer, soit le recharger.

Donc, encore une fois avec une base de données relationnelle NCache fait tout pour vous. En cas de non relationnel, vous devez créer une dépendance personnalisée.

Gérer les données relationnelles

Le dernier aspect de la mise à jour de leur cache concerne les fonctionnalités de dépendance. Disons, si vous avez une relation un-à-plusieurs entre un client et une commande et que vous les mettez tous les deux en cache. Que se passe-t-il si l'objet client est supprimé du cache ? Les commandes doivent-elles rester dans le cache ou non ? Et si vous supprimiez réellement le client de la base de données. Eh bien, vous ne supprimez généralement pas les clients, quand je dis un à plusieurs. Disons, que se passe-t-il si le côté que vous supprimez du cache signifie vraiment que vous l'avez peut-être également supprimé de la base de données. Cela signifie que le côté plusieurs n'est plus valide. Alors, qui devrait garder une trace de tout cela ? Si la cache peut le faire pour vous, cela vous simplifie la vie.

Par exemple, l'objet de cache ASP.NET a cette fonctionnalité appelée dépendance de cache. NCache l'a implémenté et pour autant que je sache, aucun autre cache .NET ne possède cette fonctionnalité. Mais, fondamentalement, vous enregistrez la relation entre les éléments et dites que cela dépend de cet élément, si cet élément est mis à jour ou supprimé, veuillez supprimer automatiquement cet élément. Ainsi, le cache fait le nettoyage pour vous.

Plus le cache en fait pour vous, mieux c'est pour vous, car vous pouvez être assuré que vos données seront fraîches. Une fois que vous avez cette confiance, vous pouvez mettre en cache à peu près toutes les données. C'est juste une question de stratégie que vous utiliserez pour garder les données à jour.

Trouver des données

Donc, maintenant que vous avez la certitude que les données sont fraîches, vous allez commencer à mettre en cache beaucoup de données. Eh bien, une fois que vous avez commencé à mettre en cache toutes les données, la prochaine chose qui vient est que le cache commence maintenant à ressembler de plus en plus à une base de données. Ce n'est pas une base de données, c'est toujours un magasin temporaire. Mais, en particulier une grande partie de ces données de référence, vous stockez à peu près l'intégralité de l'ensemble de données dans le cache. Lorsque cela se produit, vous voulez pouvoir effectuer une recherche dessus. Au lieu de toujours le trouver en fonction des clés, c'est très gênant. Trouver n'importe quel élément basé sur la clé n'est pas toujours pratique. Vous voulez être en mesure de rechercher cela par d'autres moyens.

Une façon est de faire un Recherche SQL. Encore, SELECT Clients WHERE clients.Ville = "New York". Tout comme vous feriez ou vous diriez donnez-moi tous mes produits de cette catégorie. Ainsi, vous récupérerez une collection de ces objets à partir du cache, et non de la base de données. Venir du cache signifie bien sûr que la base de données n'a plus à prendre ce coup et tout est en mémoire. C'est beaucoup plus rapide car il provient de plusieurs serveurs en même temps.

Donc, toutes ces requêtes sont parallèles. Et, pour que vous puissiez le faire, le cache doit prendre en charge l'indexation, ce qui NCache Est-ce que. Je ne suis pas sûr que d'autres produits le fassent ou non, mais assurez-vous que le cache prend en charge l'indexation. Sinon, ce seront des requêtes vraiment très lentes.

Regroupement de données

Une chose que vous ne pouvez pas faire dans un cache est de joindre plusieurs objets ou plusieurs tables, ce que vous pouvez faire dans une base de données relationnelle. Donc, il existe des moyens de contourner cela, c'est-à-dire que vous pouvez regrouper des éléments, vous pouvez les étiqueter de certaines manières afin de les récupérer et de cette façon, vous pouvez récupérer des données en fonction d'associations logiques ou de regroupements qui se trouvent dans le cache. Alors, disons que si vous cachez tout, je vais vous donner un exemple. Par exemple, disons que vous avez récupéré une collection de clients. Donc, j'ai une collection de balises d'objets et je veux mettre en cache chaque objet séparément dans le cache. Mais, plus tard, je veux pouvoir tout récupérer en un seul appel.

//Caching Query Results (Collection)
//Cache Collection Objects Separately
static void CacheSupplierProducts(NorthwindEntities context, int supplierId)
{
    Tag[] productTags = new Tag[1];
    productTags[0] = new Tag("SupplierProducts:" + supplierId);
    
    IQueryable<Product> products = context.Products;
    
    var result = from product in products
                  where product.SupplierID == supplierId
                  select product;
                  
    foreach (Product p in result)
    {
        String key = "Products:ProductId:" + p.ProductID;
        _cache.Insert(key, p, productTags);
    }
}
...
ICollection productList = _cache.GetByAnyTag(productTags).Values;

Donc, soit j'émets la même requête, requête SQL et je dis me rendre toutes les choses. Mais, j'ai obtenu ces objets de la base de données, je ne les ai pas obtenus du cache. Et, ils ne sont pas un ensemble de données complet. Disons, quel que soit l'ensemble que je voulais récupérer à ce moment-là. J'ai donc mis en cache chaque objet individuellement auquel je pourrais avoir besoin d'accéder individuellement. Mais je veux pouvoir tout récupérer en une seule collection. J'utilise donc le concept de balise. Je les ai tous marqués avec la même étiquette. Et, cette balise pourrait être n'importe quelle chaîne unique et je dis donnez-moi tous les éléments qui ont cette balise. Ainsi, en un seul appel, je peux récupérer toute cette collection. Donc, c'est ce genre de choses que vous pouvez faire avec des balises, qui compensent le manque de jointures dans le cache.

Ainsi, vous pouvez faire des regroupements. Le groupes et sous-groupes. Tu peux faire étiquettes. Vous pouvez faire des balises nommées. Balises nommées sont essentiellement vous avez une clé, puis une valeur. Si vous mettez en cache, par exemple, du texte, du texte libre. Il n'y a aucun moyen d'indexer ce texte par lui-même car c'est du texte. Donc, vous devez créer les balises vous-même et la balise elle-même peut ne pas suffire. Vous voulez pouvoir nommer chaque balise.

Donc, tout comme un objet a des noms d'attributs. Ainsi, la balise de nom est comme les attributs d'un objet. Ainsi, le nom pourrait être ville et la valeur dans ce texte pourrait être New York ou Las Vegas. Donc, vous pouvez faire tout cela, puis récupérer ces choses plus tard et en cas de NCache au moins vous pouvez utiliser si vous spécifiez tout cela via l'API ou via le Requête SQL. Ainsi, lorsque vous récupérez quelque chose basé sur SQL…

Première question, super ! Peut-on utiliser des taxonomies hiérarchiques ? Ce que vous pouvez faire en fait, c'est que… les groupes et sous-groupes ne vous donnent qu'un seul niveau de hiérarchie. Ainsi, au sein d'un groupe, vous pouvez avoir plusieurs sous-groupes, mais vous ne pouvez pas aller au-delà.

Vous pouvez utiliser différents types de balises pour représenter, car vous pouvez attribuer plusieurs balises à un élément. Ainsi, par exemple, si vous aviez plusieurs hiérarchies, vous pouvez attribuer pour chaque niveau que vous descendez, vous pouvez attribuer tous les niveaux supérieurs en tant que balise distincte.

Encore une question. Pouvons-nous contrôler la représentation interne du cache ? Les index sont construits sur la base d'une combinaison de table de hachage, en cas de NCache, et arbres noirs rouges. Vous pouvez choisir les index mais vous ne choisissez pas la structure de données qui sera utilisée en interne. Mais, les index sont construits en fonction de la nature de l'utilisation. Ainsi, par exemple, les tables de hachage conviennent à certains types d'accès et si vous effectuez des recherches de type plage, les arbres rouges et noirs sont bien meilleurs. Alors le NCache le fait. Je ne sais pas ce que font les autres produits mais NCache indexe un peu les choses.

Lecture et écriture

Permettez-moi de passer rapidement en revue lecture continue, écriture continue. Alors, pourquoi voulez-vous lire et écrire? En lisant, nous en avons vu un exemple, à savoir que vous pouvez recharger automatiquement des éléments.

Un autre avantage de la lecture est bien sûr que vous consolidez autant d'accès à vos données dans le cache lui-même. Plus vous accédez… plus cela va dans le cache ou la couche de mise en cache, moins il y en a dans votre application et l'application devient plus simple. L'application ne fait qu'un cache.Obtenir et bien sûr, l'autre avantage était que vous pouviez charger automatiquement des éléments.

L'écriture continue est de la même manière. L'un des avantages est que vous avez la consolidation de toutes les écritures. Le deuxième avantage est que vous pouvez réellement accélérer vos écritures. Ainsi, par exemple, l'écriture différée est une fonctionnalité dans laquelle vous mettez à jour le cache de manière synchrone et le cache met à jour la base de données de manière asynchrone. Ainsi, si les mises à jour de la base de données ne sont pas aussi rapides que le cache, ce qui est vrai, les performances de votre application s'améliorent soudainement car vous ne mettrez à jour que le cache et la base de données des mises à jour du cache.

Ainsi, la lecture, l'écriture et l'écriture derrière sont des fonctionnalités vraiment très puissantes dont vous devriez tirer parti. C'est aussi du code côté serveur que vous écrivez qui s'exécute sur le cluster de cache et qui vous simplifie la vie. Ainsi, votre application peut avoir plus de données dans le cache et également les mettre à jour via le cache.

Permettez-moi de le parcourir rapidement et de parler de quelque chose. Je ne vais pas entrer dans le détail de Mise en cache de l'état de la session ASP.NET. Sachez simplement que vous pouvez simplement le brancher sans aucun changement de code et simplement apporter des modifications à web.config et il s'en occupe automatiquement et la même chose va avec afficher l'état ainsi que mise en cache de sortie.

Haute disponibilité (100 % de disponibilité)

Je vais passer rapidement en revue quelques points. Je voulais d'abord parler de… Tout cache que vous utilisez, parce que, c'est comme une base de données, c'est une base de données en mémoire en production. Ainsi, un cache doit être hautement disponible. Vous devez disposer d'un cache hautement disponible.

Cluster de cache dynamique

NCache est hautement disponible grâce à deux ou trois choses qu'il fait. Il a d'abord un cluster de cache dynamique. Vous pouvez ajouter ou supprimer des serveurs au moment de l'exécution et réajuster automatiquement le cluster. Vous n'avez pas besoin de coder en dur les noms de serveur dans la configuration, les clients automatiquement. Une fois qu'un client communique avec un serveur de cache, il obtient des informations sur l'appartenance au cluster. Si l'adhésion change au moment de l'exécution, disons que vous ajoutez un nouveau nœud ou que vous supprimez un nœud, l'adhésion mise à jour est propagée au client.

Donc, c'est la première partie qui doit être là. Il est vraiment important que vous le voyiez ainsi.

Topologies de mise en cache

La seconde est la topologie de mise en cache. Ainsi, il existe différentes manières de NCache, par exemple, vous donnera quatre topologies de mise en cache. Le premier s'appelle un Cache en miroir. C'est un 2 nœuds actif/passif.

La seconde s'appelle Cache répliqué, où chaque serveur du cache dispose d'une copie de l'intégralité du cache. Ainsi, plus vous avez de serveurs, plus vous avez de copies de cache. Il est évolutif pour la lecture, pas évolutif pour les mises à jour. Mais, il a sa propre utilisation avec des cas.

La troisième topologie est appelée Cache partitionné, où l'intégralité du cache est divisée en partitions. Chaque serveur est une partition. Et, ces partitions sont créées automatiquement.

Ainsi, par exemple, en cas de NCache chaque partition contient un certain nombre de compartiments. Ainsi, le cluster total compte 1,000 XNUMX buckets. Donc, si vous avez trois partitions, elles ont un tiers, un tiers de compartiments.

Réplique partitionnée est la même avec la partition mais chaque partition est sauvegardée sur le serveur différent et tout cela est fait automatiquement pour vous. Ainsi, lorsque vous créez un cluster à deux nœuds, vous allez avoir deux partitions, les deux répliques. Lorsque vous ajoutez un troisième serveur, automatiquement, une troisième partition est créée et lorsqu'une troisième partition est créée, certains compartiments doivent être déplacés de la partition existante.

Ainsi, tout cela est fait automatiquement pour vous. Une nouvelle réplique est automatiquement créée. En fait, si vous le voyez à partir de ceci, laissez-moi juste vous montrer cela, ici. Disons que si vous aviez une partition à deux serveurs… mais disons que si vous n'avez qu'un clustering à deux serveurs, vous avez deux partitions. La partition 1 était ici et la réplique 1. La partition 2, la réplique 2. Maintenant, vous avez ajouté un troisième serveur, tout à coup vous devez avoir une troisième partition et cela obtiendra certains des compartiments d'ici, d'autres d'ici, c'est une chose. Deuxièmement, la réplique 2 ne sera plus ici, elle va déménager ici car maintenant, la réplique de la partition 3 doit être ici.

Ainsi, tout cet ajustement est automatiquement effectué pour vous par NCache. Donc, c'est une chose. Deuxièmement, il y a une fonctionnalité appelée Cache Client certaines personnes l'appellent Near Cache, qui est vraiment puissant que vous devez utiliser. Fondamentalement, il s'agit d'un cache local au sein de votre application cliente. Mais, il y a une chose spéciale à ce sujet, c'est que ce cache local n'est pas déconnecté du cluster de cache. Il est connecté au cluster de cache. Il se maintient synchronisé.

Ainsi, en cas de NCache, par exemple, le cache client se connecte automatiquement en arrière-plan à une configuration. Quoi que vous récupériez de chacune de ces applications, les serveurs sont automatiquement conservés dans le cache client. Ainsi, la prochaine fois que vous en aurez besoin, vous le trouverez dans le cache du client. Et le cluster de cache sait quelles données se trouvent dans quel cache client. Donc, si ces données changent par, disons, un autre client, le cluster notifie à tous les caches clients qui ont ces données d'aller se mettre à jour. Ainsi, le cache client reste connecté mais il s'agit d'un cache local. Il peut même être In-Proc. In-Proc signifie dans le cadre de votre processus de candidature. Donc, cela accélère vraiment vos performances, mais en même temps, vous faites partie du cache distribué connecté global.

Réplication WAN

Je vais sauter beaucoup de choses, nous n'avons pas le temps. Donc, il y a aussi Réplication WAN. Si vous avez plusieurs centres de données, vous devriez pouvoir faire en sorte que le cache se réplique sur le WAN et vous ne pouvez pas créer de cluster sur le WAN. Cela va juste mourir parce que ces sockets se cassent, la latence est juste très élevée. Il doit donc exister un moyen de connecter les caches entre deux centres de données.

En cas de NCache nous avons cette chose appelée topologie de pont qui relie plusieurs centres de données. Vous pouvez maintenant avoir des centres de centres de données actifs-actifs, actifs-passifs ou même plus de deux. Et, tout cela est fait de manière asynchrone et il y a aussi une résolution de conflit faite pour vous. Ainsi, comme vous pouvez le constater, un cache n'est pas qu'un simple magasin de valeurs clés. Donc, il y a beaucoup de choses que vous devriez garder à l'esprit dans les coulisses.

NCache vs. Redis

Une chose que je voulais rapidement couvrir était NCache vs. Redis, juste un haut niveau, je voulais en parler. NCache est le cache .NET natif. Il fonctionne sous Windows et vous pouvez effectuer à la fois la mise en cache côté client et côté serveur, c'est un avantage. Alors que, Redis est principalement un cache basé sur Linux. Avant que Microsoft ne s'associe à eux, vous savez, la plupart des gens du côté .NET ne savaient même pas qu'ils existaient, même s'ils étaient un cache très populaire sur Unix, PHP et d'autres environnements.

Deuxièmement, la version Linux de NCache est disponible sur Azure, en tant que cache en tant que service. Ainsi, la raison pour laquelle le cache est un service est que pour les applications .NET, vous ne pouvez pas vraiment exécuter de code côté serveur sur un cache basé sur Linux. Vous devez disposer d'un cache basé sur .NET pour que vous puissiez l'exécuter. Donc, c'est une énorme limitation que vous obtiendrez.

Troisièmement, si vous comptez faire quoi que ce soit en dehors d'Azure, Redis est uniquement disponible en tant que cache basé sur Linux. Le support de fenêtre que Microsoft a fait est quelque chose qu'ils n'utilisent pas eux-mêmes. Même sur Azure, ils ne choisissent pas de l'utiliser sur les fenêtres. Ce n'est pas très stable. Il y a aussi plus de détails si vous voulez voir un plus détaillé comparaison entre NCache ainsi que Redis, vous pouvez venir ici puis voir les comparaisons. Donc, nous avons comparaisons avec tout le monde, parce que nous avons tellement confiance en nous.

Donc, comme vous pouvez le voir, il s'agit d'une comparaison complète. Passez par là. Si vous envisagez d'utiliser un cache distribué, ce que vous devriez faire, vous avez tous ces besoins d'évolutivité. Faites vos devoirs, assurez-vous que tout ce que vous utilisez correspond à vos besoins. Et, dans la mesure où NCache est concernée, nous vous faciliterons la comparaison NCache avec les autres. Vous pouvez venir sur notre site et download NCache. C'est open source. Ainsi, vous pouvez télécharger soit l'édition Enterprise ou l'édition Open Source ici ou vous pouvez aller sur GitHub et vous aurez NCache ici.

C'est la fin de ma présentation. Des questions? Vous pouvez passer un appel de procédure stockée. Il doit s'agir uniquement de SQL, comme les éléments de transaction SQL qui s'exécuteront dans le serveur SQL lui-même.

Oui. Ainsi, le cache peut être sur le même serveur que l'application. Nous ne le recommandons pas. Ce n'est pas une bonne stratégie de déploiement mais si vous avez une petite configuration, oui, bien sûr.

Lorsque vous effectuez le partitionnement, tout le partitionnement est fait pour vous. Donc, l'idée est que chaque partition doit être égale en poids, en termes de taille de données, en termes de transactions.

Vous ne contrôlez pas les partitions, vous savez juste qu'elles existent.

Lorsque vous mettez à jour la table des éléments, vous pouvez choisir de mettre à jour le cache à partir de la base de données elle-même, si vous disposez d'une procédure CLR qui peut effectuer un appel directement de la base de données vers le cache. Vous pouvez également écrire du code séparé qui peut mettre à jour le cache et tout cela dépend de la quantité que vous êtes et conservez dans le cache.

Donc, tu sais, je peux parler de plus hors ligne si tu veux. Mais, je veux dire, il existe plusieurs façons de vous assurer que toutes les données auxquelles vous avez besoin d'accéder sont conservées dans le cache.

Oui, en fait, je vais mettre les diapositives à disposition. C'est la raison pour laquelle nous avons scanné les e-mails de tout le monde. Donc, nous pouvons le faire et nous aurons également la vidéo enregistrée et téléchargée. Ainsi, vous pouvez regarder et aussi vos collègues peuvent le regarder.

En fait, par application ou … En fait sur plusieurs applications. Donc, tout dépend de la charge de transaction. Vous pouvez avoir au moins 2 serveurs de cache juste pour avoir le cluster, puis le nombre de serveurs dépend du nombre de serveurs d'applications dont vous disposez ou de la quantité d'activité que vous avez en gros ? Combien de données vont mettre en cache ? Combien de lectures et d'écritures faites-vous ?

C'est pas grave, ouais. Oui, tout continuera à fonctionner. Merci les gars.

Que faire ensuite?

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