Camp de code du sud de la Floride 2017
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é
Aujourd'hui, je vais parler de la façon dont vous pouvez faire évoluer les applications .NET avec la mise en cache distribuée. Ce discours ne concerne pas NCache. Bien que je me réfère à NCache mais le but principal est de vous expliquer quels sont les problèmes et comment vous pouvez les résoudre avec la mise en cache.
Qu'est-ce que l'évolutivité
D'accord! Juste à des fins d'exhaustivité, passons en revue quelques-unes des définitions que je suis sûr que vous connaissez déjà, mais définissons d'abord ce qu'est l'évolutivité. L'évolutivité n'est pas synonyme de haute performance. La haute performance serait quelque chose si vous aviez cinq utilisateurs, vous avez un très bon temps de réponse, c'est une haute performance. L'évolutivité, c'est si vous pouvez maintenir les mêmes performances élevées sous des charges de pointe. Donc, si votre application n'a pas de hautes performances avec cinq utilisateurs, vous avez d'autres problèmes. Plus que nous ne pouvons y résoudre.
Évolutivité linéaire
Deuxièmement, qu'est-ce que l'évolutivité linéaire. L'évolutivité linéaire est davantage une définition de déploiement.
Lorsque vous déployez votre application dans un environnement multiserveur, disons, si vous avez un environnement à charge équilibrée, votre application est évolutive linéairement si vous pouvez simplement ajouter plus de serveurs pour obtenir une capacité de transaction supplémentaire. Donc, si vous aviez mille utilisateurs avec deux serveurs, vous aviez un troisième serveur, disons, 1500 utilisateurs, puis à mesure que vous ajoutez plus de serveurs, vous obtenez 500 utilisateurs chacun. Je dis juste hypothétiquement mais c'est une évolutivité linéaire. Si vous pouvez y parvenir, alors c'est l'objectif parce qu'alors vous ne rencontrez jamais de problèmes, pour lesquels je suis sûr que vous étiez ici pour les résoudre.
Évolutivité non linéaire
L'évolutivité non linéaire est tout le contraire de ce qui est que vous avez une architecture d'application où vous ne pouvez tout simplement pas acheter du matériel plus cher ou plus de serveurs pour résoudre ce problème.
Vous avez des goulots d'étranglement fondamentaux, donc à mesure que vous ajoutez plus de serveurs, votre application, pendant un certain temps, les performances ou la capacité de transaction augmentent mais, après cela, elle ralentit même si vous ajoutez plus de serveurs. Donc, vous ne voulez certainement pas d'évolutivité non linéaire.
Quels types d'applications ont besoin d'évolutivité ?
Ce sont généralement des applications côté serveur.
Ce sont des applications Web, ASP.NET, il peut s'agir de services Web WCF, il peut s'agir du back-end de toutes les applications IOT. Nous avons beaucoup d'appareils IOT différents qui communiquent avec une sorte de back-end. Il peut s'agir d'applications de traitement de données volumineuses, bien que le traitement de données volumineuses soit davantage une activité Java. En raison de Hadoop, .NET n'est pas un très gros traitement de données volumineuses, mais si vous faisiez du traitement de données volumineuses, vous auriez certainement besoin d'évoluer et de toutes les autres applications serveur qui ne rentrent pas dans cette catégorie. Je veux dire que vous pouvez avoir beaucoup de traitement par lots, si vous êtes une grande entreprise, vous devrez peut-être mettre à jour un certain nombre de choses avant minuit ou avant le jour ouvrable suivant et, comme vous avez de plus en plus de clients, vous avez des millions et des millions de clients, vous devez bien sûr faire évoluer cela.
Ainsi, même ces applications back-end, un bon exemple pourrait être que les clients sont, votre banque et les clients transfèrent des fonds d'un compte à un autre, ce qui est généralement traité dans le back-end en mode batch la nuit. Donc, vous devez contractuellement le faire dans un certain délai. Donc, toutes ces applications, si elles n'ont pas d'évolutivité, vous avez des problèmes majeurs.
Quel est le problème d'évolutivité ?
Le niveau d'application n'est heureusement pas là où se situe le problème. Si vous avez la plupart de ces applications, le niveau d'application vous permet d'ajouter plus de serveurs, ce n'est pas grave. C'est le stockage des données qui pose problème. Et, quand j'utilise le mot stockage de données, je veux dire des bases de données relationnelles, des données héritées du mainframe. C'est là que résident la plupart de vos données et ce sont elles qui ne peuvent pas évoluer de la même manière que les applications. À présent, NoSQL databases existent pour l'un des cas d'utilisation est à l'échelle, mais, le problème avec NoSQL databases, et encore une fois, nous avons un NoSQL database de notre propre appelé NosDB. C'est une base de données open source. Ainsi, la limitation de NoSQL database est que vous ne pouvez tout simplement pas y déplacer toutes les données car elles vous obligent à déplacer les données de votre ordinateur central ou de vos bases de données relationnelles, ce que, pour diverses raisons, peut-être techniques, peut-être commerciales, vous ne pourrez peut-être pas faire.
Ainsi, les bases de données relationnelles continueront d'être votre principale source de données de référence. Il y a beaucoup de cas d'utilisation où vous pouvez mettre beaucoup de nouvelles données dans NoSQL databases et lorsque vous le faites, ils résolvent le goulot d'étranglement de l'évolutivité. Mais, dans la majorité des cas, vous ne pouvez le faire que pour un sous-ensemble de vos données. La majorité des données doivent encore rester dans vos bases de données relationnelles ou dans vos anciennes sources de données mainframe. Donc, quel que soit le problème que vous avez à résoudre, cette évolutivité, vous devez le résoudre tout en continuant à travailler avec des bases de données relationnelles ou avec votre ancien mainframe. Et c'est là qu'un cache distribué résout réellement ce problème. Il vous permet de continuer à utiliser les données mainframe de vos bases de données relationnelles tout en supprimant tout ce goulot d'étranglement.
Déploiement de cache distribué
Donc, voici une image, si vous aviez, s'il s'agit de vos données héritées de bases de données relationnelles, vous pouvez mettre une couche de mise en cache entre l'application et la base de données.
Lorsque vous faites cela, vous commencez à mettre en cache les données que vous allez utiliser fréquemment. Et, environ 80 % du temps, vous n'avez même pas besoin d'accéder à la base de données. Et, le cache, parce que c'est un cache distribué, vous pouvez ajouter de plus en plus de serveurs, il évolue de la même manière que le niveau application. Ainsi, vous disposez ici d'au moins deux serveurs de cache, puis vous maintenez un rapport de quatre pour un ou de cinq pour un entre le niveau d'application et le niveau de mise en cache. Maintenant, ce ratio peut changer selon la nature de vos opérations. Si chacun de vous, disons, si vous aviez une application Web, pour chaque clic d'utilisateur, vous faites des centaines d'appels de cache, alors, bien sûr, le ratio changerait mais, la plupart du temps, vous ne faites pas des centaines d'appels de cache.
Un serveur de cache typique n'est qu'un serveur à faible coût. Il s'agit d'un type de serveur Web d'une configuration, d'un processeur double, d'un boîtier de type quadricœur, il a juste beaucoup de mémoire. Beaucoup de mémoire signifie que 16 à 32 gig sont assez standard, plus de 32 gig que vous n'avez généralement pas à faire. Bien que nous ayons de nombreux clients qui vont jusqu'à 64 Go, nous recommandons qu'au lieu d'avoir beaucoup plus de mémoire dans chaque boîte, il suffit d'ajouter plus de boîtes. Et, la raison en est que plus vous avez de mémoire dans chaque boîtier, plus vous devez avoir un processeur puissant et votre boîtier commence à ressembler de plus en plus à une base de données, ce qui n'est pas l'intention. Vous voulez garder ce coût aussi bas que possible.
Maintenant, un cache distribué est une infrastructure que vous souhaitez mettre pour toutes vos applications. Ainsi, tout comme vous avez une base de données qui est à peu près une infrastructure commune, la nouvelle meilleure pratique consiste à disposer d'un cache distribué en mémoire. C'est aussi appelé en mémoire NoSQL magasin de valeur clé. Et, ayez cela dans le cadre de vos applications d'infrastructure et d'architecture afin que vous alliez toujours dans ce magasin. Donc, vous vérifiez le magasin avant d'aller dans la base de données. Une fois que vous avez cette infrastructure, toutes vos applications deviennent automatiquement évolutives. Ainsi, vous n'avez jamais à vous soucier que les bases de données deviennent un goulot d'étranglement. Et, le plus gros problème avec l'évolutivité ou l'impossibilité d'évoluer est que c'est à ce moment-là que votre entreprise fait beaucoup d'activités.
Disons que vous êtes une compagnie aérienne et que vous venez de faire une promotion spéciale pour Hawaï. Tout le monde se connecte à votre site Web mercredi, je ne sais pas, pour commencer à acheter des billets. Donc, ils vont chercher des vols et ils vont acheter des billets et, vous avez environ cinq fois plus de trafic qu'auparavant et tout à coup le site ralentit, peut-être qu'il plante et il peut planter, bien sûr , si votre base de données est saturée mais, même si elle ralentit au-delà des limites acceptables, votre coût pour l'entreprise est très élevé car les gens partiront tout simplement. Donc, vous devez vraiment vous assurer que vous planifiez une évolutivité que vous n'aurez jamais cette situation où votre entreprise veut faire plus d'activité, elle est capable de générer des affaires mais vous n'êtes pas en mesure de traiter dans l'application. Et, si vous avez la bonne infrastructure, vous n'aurez jamais ce problème.
Je ne fais que mettre en place le cas sur pourquoi vous devriez utiliser une mise en cache distribuée ? Quel problème est résolu, puis nous entrerons dans les détails de la façon dont vous l'utilisez réellement. En plus d'avoir plus de mémoire, vous avez généralement, comme je l'ai dit, une double CPU, une configuration quad core, 2 cartes réseau d'un gigabit ou plus chacune. En cas de NCache ce sont des boîtes Windows, en cas de Redis ce sont des boîtiers Linux, selon que vous avez une application .NET ou Java. Je me concentre ici sur .NET, mais pour Java, vous avez également des caches distribués. Ils les appellent grille de données en mémoire, du côté .NET, cela s'appelle un cache distribué.
Cas d'utilisation courants du cache distribué
D'accord! Donc, maintenant que nous avons en quelque sorte expliqué pourquoi vous avez besoin d'un cache distribué dans le cadre de votre infrastructure de meilleures pratiques, à la fois d'un point de vue informatique mais surtout d'un point de vue de développement, vous souhaitez concevoir l'application. La première question qui me vient également à l'esprit, comment utiliser ce cache ? Quels sont les cas d'utilisation ? Où est-ce que je les utilise ? Je veux dire que je sais quel type d'applications je vais les utiliser mais quel type de données je vais mettre en cache ?
Ainsi, il existe trois catégories principales. Le premier est ce que tout le monde comprend, à savoir la mise en cache des données d'application.
Mise en cache des données d'application
Ainsi, dans la mise en cache des données d'application, vous mettez en cache des données qui existent dans votre base de données, vous les mettez en cache, c'est ce dont nous venons de parler. Ainsi, lorsque vous faites cela, vous créez en fait deux copies des données. L'un est dans la base de données du maître et l'autre dans le cache qui est la copie temporaire. Lorsque cela se produit, quelle est la principale préoccupation ? Qu'est-ce qui pourrait mal tourner lorsque vous avez deux copies ? Ils pourraient se désynchroniser. En fait, c'est une telle crainte majeure dans l'esprit des gens que la plupart des gens, lorsque vous leur demandez à quoi servent la mise en cache, ils disent bien pour les données en lecture seule, je ne peux pas prendre de risque avec mes données transactionnelles, avec des données qui changements parce que si cela tourne mal. Que se passe-t-il si mon client retire cet argent deux fois de ce même compte, que va-t-il se passer ?
Eh bien, si vous ne pouvez pas mettre en cache les données transactionnelles, la valeur d'un cache distribué diminue un peu car les données de référence ne représentent que vingt ou trente pour cent des données. 80 % ou 70 à 80 % des données sont vos clients, vos comptes, vos activités, vos données transactionnelles, les données qui changent toutes les 30 secondes, toutes les minutes, les données que vous pouvez conserver dans le cache pendant un temps très très court. Donc, si vous n'êtes pas en mesure d'utiliser un cache pour les données transactionnelles, vous vous êtes vraiment limité. Ainsi, un bon cache distribué doit garantir que le cache et la base de données sont toujours synchronisés. Ainsi, une fois que vous avez la certitude que le cache est toujours synchronisé avec la base de données, vous pouvez pratiquement tout mettre en cache et lorsque vous le faites, vous voyez vraiment beaucoup de jeux.
Et, je vais entrer dans beaucoup plus de détails à ce sujet.
Mise en cache spécifique à ASP.NET
Le deuxième cas d'utilisation est lorsque vous avez une application ASP.NET, vous pouvez mettre en cache certains éléments spécifiques à ASP.NET. Et, la bonne chose à propos de cette catégorie est qu'aucune programmation n'est nécessaire de votre part, car Microsoft dispose d'un cadre dans lequel un cache se branche simplement. Le premier est l'état de la session. Chaque application ASP.NET doit avoir un état de session, à peu près. Certaines personnes sont spécialement programmées pour ne pas l'utiliser, ce qui n'est pas une bonne idée. Vous devriez utiliser une session qui vous rend la vie beaucoup plus facile.
Une session est un très bon candidat pour la mise en cache car si vous stockez une session dans la base de données, vous rencontrez les mêmes problèmes que les bases de données ne sont pas conçues pour stocker des blobs, ce qu'est une session. Ainsi, les performances sont vraiment lentes et, plus important encore, l'évolutivité disparaît. Pour la même raison que vous souhaitez mettre en cache les données d'application, vous souhaitez également mettre les sessions hors de la base de données. Vous voulez les mettre dans le cache distribué.
Le second est un état d'affichage. Si vous n'utilisez pas le framework MVC, si vous êtes toujours sur l'ancien ASP.NET framework puis afficher l'état. Pour ceux d'entre vous qui ne savent pas ce qu'est un état d'affichage, un état d'affichage est une chaîne cryptée qui peut être aussi petite qu'une centaine d'octets ou des centaines de kilo-octets qui est générée et envoyée au navigateur uniquement pour revenir quand vous faites un post en retour. Donc, c'est un voyage assez cher. Bien sûr, cela ralentit vos performances car beaucoup plus de données sont transférées. Et cela augmente également vos coûts de bande passante car lorsque vous hébergez votre application, le tuyau au-dessus n'est pas gratuit. Ainsi, lorsque vos clients accèdent à votre application Web, vous payez ici la bande passante. Ainsi, un état de vue, lorsque vous multipliez cela par les millions et les millions de demandes ou les transactions que vos utilisateurs ou clients vont effectuer, cela représente beaucoup de coûts supplémentaires que vous ne voulez pas engager. C'est donc un très bon candidat pour la mise en cache. Donc, vous l'avez mis en cache sur le serveur et envoyez simplement une petite clé pour que la prochaine fois qu'un message incorrect se produise, la clé revienne et avant que la page ne soit exécutée, l'état d'affichage est extrait du cache.
Le troisième est le cache de sortie qui est une autre partie d'ASP.NET framework que si la sortie de votre page ne change pas, pourquoi l'exécuter la prochaine fois ? Parce que chaque fois que vous exécutez la page, cela va consommer du CPU, de la mémoire et toutes les autres ressources, y compris vos bases de données. Il est donc préférable de simplement renvoyer la sortie de la dernière exécution qui pourrait être la page entière ou une partie de la page. Donc, pour tous ces trois, il vous suffit de brancher un cache distribué sans aucune programmation. Maintenant je vais vous montrer ça. Mais, la nature de ce problème est très différente de l'application.
Dans les données d'application, nous avions deux copies des données, n'est-ce pas ? Donc, le problème était la synchronisation. Ici, vous n'avez qu'une seule copie et celle-ci est conservée dans un magasin en mémoire. Alors, quelle est la plus grande préoccupation lorsque vous conservez quelque chose comme ça dans un magasin en mémoire et que c'est la seule copie. Cela aussi! Ou, si un serveur tombe en panne, vous venez de perdre ce cache. Donc, pour que tout cela soit stocké dans le cache. Imaginez simplement cette même compagnie aérienne que je viens de traverser et j'ai passé une demi-heure à trouver la combinaison de compagnies aériennes parfaite et je suis sur le point de cliquer sur Soumettre et la session est perdue, ce n'est pas une bonne expérience car le serveur Web vient de tomber en panne.
Alors, pour cela, comment résolvez-vous ce problème lorsque vous avez un in-memory et que vous avez ce souci ? Vous avez une redondance. Vous disposez de plusieurs copies des données. Ainsi, un bon cache distribué doit vous permettre de faire de la réplication de données. Sans réplication des données de manière intelligente et performante, votre cache redevient beaucoup moins utile.
Partage de données d'exécution via des événements
Le troisième cas d'utilisation est quelque chose que la plupart des gens ne connaissent pas ou qui commence à devenir plus populaire, c'est que vous pouvez utiliser, vous avez cette infrastructure en mémoire très évolutive. Vous pouvez l'utiliser pour le partage de données d'exécution via des événements, il dit un peu comme une messagerie mais une version très simplifiée de celui-ci et c'est dans un seul type de centre de données d'un environnement où vous pouvez avoir plusieurs applications utilisent le cache comme moyen de faire Type Pub/Sub d'un partage de données. Ainsi, une application met quelque chose dans le cache, déclenche un événement et les consommateurs intéressés par ces données reçoivent cet événement et ils peuvent aller consommer ces données.
Ainsi, au lieu de mettre cela dans la base de données ou de le mettre dans une file d'attente MSM, tapez une situation qui a son propre objectif. Un cache n'est pas là pour remplacer la file d'attente MSM mais, dans de nombreuses situations, c'est une infrastructure beaucoup plus simple et surtout beaucoup plus rapide et évolutive pour faire du partage de données basé sur des événements. Donc, si vous avez besoin de plusieurs applications qui doivent partager des données entre elles lors de l'exécution, vous devez absolument considérer cela comme une fonctionnalité, une fonctionnalité très importante.
Mise en cache spécifique à ASP.NET
Je vais juste vous montrer rapidement la mise en cache ASP.NET, comment vous faites cela. C'est très très simple et je vais en fait utiliser… Donc, j'ai un exemple de code. Ainsi, par exemple, si je devais… Donc, j'ai cette application ASP.NET. Tout ce que vous avez à faire est d'aller dans le web.config, en cas de NCache et encore une fois, ce sera à peu près la même chose pour tous les caches. La première chose que vous devez faire est d'ajouter un assemblage. Ainsi, cet assembly est le fournisseur d'état de session. Alors, ASP.NET framework a une interface de fournisseur d'état de session qu'un cache distribué doit implémenter. NCache l'a implémenté et cela charge l'assembly dans votre application.
Donc, une fois que vous avez fait cela, la prochaine chose que vous devez faire est d'aller à la balise d'état de session. En fait, et assurez-vous que le mode est personnalisé et que le délai d'expiration est celui que vous souhaitez. En cas de NCache alors vous venez de mettre cette ligne. D'autres caches ont un type d'informations similaire. Donc, vous avez juste .. En cas de NCache tout ce que vous avez à faire est de vous assurer que votre cache est nommé et je vais vous montrer ce que cela signifie. Mais, avec autant de changements dans votre application, vous pouvez essentiellement commencer à stocker vos sessions. Donc, vous apportez cette modification dans chaque web.config du niveau application, bien sûr, vous vous assurez qu'un cache existe. Et puis, une fois que vous avez fait cela, vous pouvez réellement commencer à mettre des sessions dans le cache.
Démonstration pratique
Je vais vous montrer rapidement un cluster de cache. Ainsi, par exemple, j'ai ces ... euh, j'ai ces machines virtuelles Azure où j'ai demo1 et demo2, tout comme mes machines virtuelles de serveur de cache et le client de démonstration est comme le serveur d'application. Donc, ce sont les clients. Un client de cache est votre boîte de serveur d'application. Alors, je vais…
Créer un cluster de cache
Et, je me suis connecté, disons, je me suis connecté au client de démonstration et je vais l'utiliser, en cas de NCache et encore je vais utiliser cet outil appelé NCache gestionnaire. C'est un outil graphique. Laissez-vous configurer les caches à partir d'un seul endroit. Je viendrai ici et je dirai créer un nouveau cache en cluster. Toutes les caches sont nommées dans NCache. Donc, je vais nommer mon cache comme cache de démonstration. Je ne vais pas entrer dans les détails de ces propriétés.Je choisirai ma stratégie de réplication pour être une réplique partitionnée. Et, je choisirai une réplication asynchrone. Je fais mon premier serveur de cache. Je vais faire mon deuxième serveur de cache ici. Je vais donc créer un cluster de cache à deux nœuds. Je vais juste tout choisir. Donc, c'est le port TCP sur lequel le cluster de cache est formé, vous pouvez le changer s'il y a un conflit de port. Je vais spécifier la quantité de mémoire que mon serveur de cache va utiliser pour le cache. Je l'ai comme un concert, bien sûr, le vôtre va être beaucoup plus.
Ainsi, par exemple, laissez-moi vous montrer rapidement ce que cela signifie. Je vais juste passer à cette partie.
Alors, considérez cela comme un serveur de cache et cela a un autre serveur de cache. Ainsi, la partition 1 existe ici. La partition 1 est essentiellement une collection de compartiments. La partition 2 a sa propre boîte. Donc, il y a un en cas de NCache il y a environ un millier de seaux qui sont répartis entre le nombre de partitions dont vous disposez. Chaque serveur a une partition et chaque serveur la partition est répliquée sur un serveur différent. Donc, si vous aviez trois serveurs, vous verrez que la partition 1 est sauvegardée ici. La partition 2 est sauvegardée ici. La partition 3 est sauvegardée ici. Les répliques ne sont pas actives en cas de NCache. Ils ne deviennent actifs que si la partition principale tombe en panne.
Donc, ce que je spécifie là, c'est la taille d'une partition. Donc, dans le cas d'une réplique de partition, si je spécifie, disons, 1 Go ici, il va en fait utiliser 1 Go pour la partition et 1 Go pour la réplique. Donc, un total de 2 concerts. Donc, si vous avez, disons, 16 Go de mémoire, ce que vous voulez faire, c'est laisser environ deux ou deux Go et demi pour le système d'exploitation et d'autres processus et le reste que vous pouvez utiliser. Ainsi, pour 16 concerts, vous pouvez facilement utiliser 13 concerts. Alors, faites moitié-moitié. Donc, c'est une taille de partition de six giga et demi et, bien sûr, vous pouvez avoir 32 gigaoctets et encore une fois vous laissez trois gigas de côté et vous avez une taille de partition de 29 gigaoctets et demi, 14 gigaoctets et demi. Et, ensuite, comme vous voulez plus de stockage, au lieu d'ajouter plus de mémoire juste pour ajouter plus de serveurs car c'est plus facile à gérer. Cela rend les choses beaucoup plus évolutives. Donc, je vais juste frapper ensuite ici.
La prochaine est ma politique d'expulsion. Je ne vais pas entrer dans ces détails. Et, je vais maintenant ajouter un nœud client. Une fois que j'ai fait cela, je vais commencer un cache. Je vais commencer une cache et je voulais vous montrer cette partie parce que c'est ce qui va donner du sens à la suite de la discussion. Donc, il démarre ces deux nœuds de cache.
Simuler le stress et surveiller les statistiques du cache
Donc, je vais ouvrir un tas d'outils de surveillance et je vais exécuter cet outil appelé outil de test de stress.
C'est une ligne de commande. C'est une console qui commence réellement à faire de l'activité sur le cache. Maintenant, c'est comme s'il simulait votre application. Donc, si vous le regardez, votre application met des sessions dans le cache, chaque session est un objet. Donc, vous ajoutez. Donc, le nombre de caches a été de 177, sur cette boîte 172 et 35. Donc, ça va être presque égal et ensuite il vaut mieux sauvegarder sur un autre…
Celui-ci est sauvegardé ici celui-ci est sauvegardé ici. Donc, comme vous pouvez le voir, la réplication se produit automatiquement. Votre application n'a pas à se soucier. Tout ce que vous avez fait est de créer ce cluster et au niveau de l'application, vous venez de modifier le Web.config et tout le reste se fait automatiquement. Vous pouvez, bien sûr, surveiller ces éléments, mais le cache est nommé. Donc, dans notre cas, j'ai nommé le cache comme cache de démonstration. Vous pouvez le nommer, en fait vous pouvez avoir plusieurs caches. La configuration la plus courante que nous avons vue avec nos clients est qu'ils ont trois caches. Un cache qu'ils appelleront, disons, cache d'objets. C'est donc leur principal cache transactionnel. Un cache, ils l'appelleront cache de session. Ainsi, il mettra toutes les sessions dans ce cache. Le troisième cache, ils l'appelleront cache de référence. Ainsi, ils mettront plus de données de référence dans le cache de référence.
Et, la raison pour laquelle ils créent un cache séparé pour les données transactionnelles par rapport aux données de référence est que pour les données de référence, vous souhaitez utiliser cette fonctionnalité appelée Client Cache où vous souhaitez mettre en cache.
Cache client pour des performances encore meilleures
En fait, je saute partout, alors s'il vous plaît, pardonnez-moi si je confonds les choses. Si vous avez des données de référence, permettez-moi de revenir en arrière. avant d'avoir des caches distribués, les gens avaient cet objet de cache ASP.NET. L'objet de cache ASP.NET était un cache InProc local. C'était dans le cadre du processus de candidature, super rapide, n'est-ce pas ? Si vous gardez des choses sur votre propre tas, rien ne peut égaler cette performance. Dès que vous entrez dans un cache distribué, c'est différent, c'est un cache de traitement automatique. Ce que les gens ne réalisent pas, c'est que vos performances chutent.
Nous avons de nombreux clients qui ont d'abord été déconcertés et ont dit, eh bien, j'étais censé obtenir une amélioration des performances et mes performances ont chuté à partir d'un cache ASP.NET là-haut, c'est beaucoup plus lent maintenant, car ils doivent sérialiser l'objet. Si vous avez un objet volumineux, la sérialisation est un coût assez important et c'est un coût que vous devez supporter indépendamment de tout cache spécifique. Et, dès que vous sortez du cache de processus, vos performances sont beaucoup plus lentes qu'un cache InProc local. Mais, c'est toujours plus rapide que la base de données. C'est presque 10 fois plus rapide que la base de données mais on peut presque dire 10 fois plus lent que le cache InProc.
Donc, ce qui se passe, c'est que les gens veulent profiter de ce cache InProc. Eh bien, pour les données qui ne changent pas très fréquemment, il existe une fonctionnalité appelée Client Cache. Certaines personnes l'appellent Near Cache, en particulier du côté Java.
Cette fonctionnalité, essentiellement, c'est un cache local. C'est comme votre cache InProc ASP.NET. Il se trouve dans le processus d'application ou il peut s'agir simplement d'un cache OutProc local qui n'est pas aussi rapide qu'InProc mais toujours plus rapide que d'aller au niveau de mise en cache. Mais la différence est que ce cache connaît le niveau de mise en cache. Ce cache client est le cache au-dessus du cache et il est synchronisé. Ainsi, vous n'avez pas à vous soucier du plus gros problème dont nous avons parlé, à savoir comment synchroniser le cache avec la base de données. Eh bien, vous avez maintenant trois copies des données. Un dans la base de données, un dans le niveau de mise en cache, un dans le cache client. Bien entendu, le cache client est un sous-ensemble du niveau de mise en cache. Le niveau de mise en cache est un sous-ensemble de la base de données. Mais, quoi qu'il en soit, il doit être synchronisé. Ainsi, en ayant un cache client, il s'agit à nouveau d'un InProc, il conserve les éléments sous forme d'objet au lieu d'une forme sérialisée. Il le garde sur votre tas. Ainsi, vous obtenez le même avantage de l'objet de cache local InProc ASP.NET, mais avec tous les autres avantages de l'évolutivité, car ce cache client sera un petit sous-ensemble. Vous pouvez spécifier sa taille. Il ne franchira jamais ce seuil.
Ainsi, vous pouvez avoir un concert dans chaque cache client et vous pouvez avoir 32 concerts dans le niveau de mise en cache et la base de données en a probablement beaucoup plus que cela. Quoi qu'il en soit, même en ayant un concert parce que c'est une fenêtre mobile, n'est-ce pas ? Donc, quoi que vous fassiez, vous le gardez. Certaines des données resteront longtemps, certaines des données resteront peut-être quelques minutes, mais pendant ce temps, vous passerez des centaines d'appels et vous n'aurez pas à vous rendre au niveau de mise en cache et, bien sûr, vous n'aurez pas à allez dans la base de données. Ainsi, un cache client est une fonctionnalité très puissante lorsqu'elle est activée. Vous faites cela pour plus de données de référence. Ainsi, en cas de NCache, vous pouvez spécifier un cache client en modifiant la configuration. Il n'y a pas de programmation supplémentaire mais elle est mappée à un cache spécifique. C'est pourquoi nos clients ont généralement trois caches ; cache d'objet, cache de session et cache de référence. Pour le cache de référence, ils utilisent un cache client, pour les deux autres, ils ne le font pas.
Cache client facile à configurer
Maintenant, pourquoi ne font-ils pas un cache client avec le cache de session ? En fait, parce que les performances ralentissent. La raison en est que ce n'est mieux que si vous effectuez beaucoup plus de lectures et d'écritures. Car, que se passe-t-il en cas d'écriture ? Vous faites une écriture ici, puis vous écrivez ici, puis vous faites une écriture sur la base de données. Donc, vous faites l'écriture à trois endroits. Donc, cela n'ajoute aucune valeur si vous devez faire plus d'écritures. Vous mettez à jour votre copie, puis vous ne mettez à jour que celle-ci, puis cela notifie à tous les autres caches clients d'aller se mettre à jour. C'est une mise à jour retardée, non pas qu'elle ne soit retardée que d'une milliseconde ou deux, mais c'est toujours une mise à jour retardée en cas de cache client. Il n'y a pas de réplication entre les caches client. Le cache client se synchronise uniquement avec le niveau de mise en cache et le niveau de mise en cache propage ensuite les mises à jour vers d'autres caches client. Uniquement si l'autre cache contient ces données. Parce que, dans le cas du cache client, chaque cache client contient des données différentes en fonction de votre modèle d'utilisation.
Où utiliser le cache client
Donc, revenons en arrière, en cas de données de référence, chaque cache client a son propre ensemble de données. Donc, disons 1 à 1000, 500 à 1500 et ainsi de suite. Donc, il y a un certain chevauchement entre chacun mais ce ne sont pas des copies identiques. Ce qui est commun, c'est qu'ils sont tous des sous-ensembles de ce cache. Ainsi, lorsque je mets à jour le numéro d'élément, disons, 700 dans ce cache, il y aura une mise à jour dans le cache et le cache saura quels autres caches client ont ces éléments et ils seront immédiatement mis à jour dans leurs autres caches. Mais seulement s'ils l'ont tous. Donc, ce n'est pas vraiment répliqué car ce ne sont pas des copies identiques dans le cas du cache client. En cas de sessions, ce que j'essayais en fait d'expliquer, c'est qu'en cas de session, vous devrez mettre à jour le cache client et le cache clusterisé, deux endroits sans valeur ajoutée car pour les sessions, vous faites une lecture et une écriture. Ainsi, au moment de la requête Web, vous faites la lecture à la fin de la page, vous faites l'écriture.
Ainsi, l'écriture doit maintenant se faire à deux endroits et la lecture va se faire dans le cache client. Ainsi, les performances diminuent réellement si vous utilisez le cache client avec des sessions ou avec d'autres opérations intensives en écriture, mais les performances s'améliorent considérablement si vous l'utilisez pour des opérations plus intensives en lecture. Cela avait-il du sens?
Ainsi, la plus grande valeur d'un cache distribué, le plus rapide le plus rapide et le plus important est l'état de session. Presque toutes les applications en disposent. Je viens de créer un cluster de cache à deux nœuds et vous avez vu combien de temps cela a pris, peut-être deux minutes, en cas de NCache. Donc, c'est vraiment facile de créer un cluster de cache, bien sûr, vous voulez faire vos tests et tout. Mais, c'est vraiment facile. Il n'y a aucun effort d'ingénierie. Lorsqu'il n'y a aucun effort d'ingénierie, vos horaires sont beaucoup plus faciles à gérer. Vous n'avez qu'à faire des tests de santé mentale pour passer. Je recommanderais fortement, si vous allez commencer à utiliser un cache distribué, de l'utiliser pour l'état des sessions au début comme première étape, puis de sauter dans la mise en cache d'objets dont nous parlerons dans une minute.
Mise en cache des données d'application
Donc, nous avons parlé de la mise en cache de session. Passons rapidement à la mise en cache des données de l'application. Voici ce qu'est un typique NCache L'API ressemble beaucoup au cache ASP.NET si vous remarquez qu'il y a une connexion.
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Ainsi, vous vous connectez au cache en fonction du nom et vous créez simplement un cache avec le nom. C'est pourquoi je vous ai fait cette démonstration pour que vous compreniez ce que cela voulait dire. Et, ce handle de cache est quelque chose que vous conservez juste comme vous conserveriez un handle de base de données. Et, ensuite, vous utilisez ce handle de Cache pour faire un Cache.Get. Chaque Get, chaque opération, a une clé. Une clé est une chaîne en cas de NCache puis vous formatez la clé en fonction de ce que vous en faites. Ainsi, dans le cas d'un objet individuel, une bonne pratique consiste à spécifier simplement le nom de la classe, peut-être le nom de l'attribut et la valeur. Et puis vous pouvez obtenir cela. Donc, il y a un Get et Get.Contains, Add, AddAsync. Asynchrone signifie ne pas attendre.
Eh bien, ce qui se passe, c'est qu'en dessous, il y a une désérialisation qui se passe côté client. Donc, le client, nous allons faire un Cache.Add, disons que vous lui donnez un objet, c'est un objet employé, il va le sérialiser en fonction de la sérialisation .NET standard ou de la coutume NCache sérialisation. Et, puis créez cela dans un tableau d'octets et envoyez le tableau d'octets au cache. NCache fait plus que cela car vous devrez peut-être indexer certains attributs. Il en extrait les valeurs. Ouais ça va. Ce sera. Cela immédiatement. Ouais! Chaque objet que vous cachez doit passer par la sérialisation.
Ainsi, dès que vous activez l'application, elle va lancer des exceptions. Si vous utilisez un objet cache ASP.NET, vous n'avez pas besoin de sérialiser. Ainsi, vous pouvez à peu près tout mettre en cache et la plupart du temps, vos propres objets sont peut-être plus faciles à sérialiser, mais vous utilisez peut-être un tiers. Disons qu'auparavant, l'objet de table de données n'était pas sérialisé, mais maintenant il l'est. Ainsi, si vous utilisez des objets tiers qui ne sont pas sérialisables, vous n'avez aucun contrôle. Donc, vous ne pouvez pas les attraper si vous allez utiliser un cache distribué. En cas de NCache, nous avons notre propre sérialisation personnalisée où vous pouvez identifier ces objets. NCache crée ensuite le code de sérialisation pour vous lors de l'exécution et le compile en mémoire. Ainsi, cela vous permet d'utiliser également les objets qui ne sont pas sérialisables. Mais, cette sérialisation se produit immédiatement. Ainsi, votre application ne fonctionnera pas si elle n'utilise pas la sérialisation appropriée.
Async dit essentiellement de ne pas attendre que le cache soit mis à jour. Donc, je peux continuer. J'espère que le cache ajoutera cette chose. Ainsi, ils ne déverrouillent pas la base de données où les mises à jour peuvent échouer en raison de problèmes d'intégrité des données. Un cache n'a pas de problèmes d'intégrité des données. Il échoue uniquement lorsque vous avez des plantages. Lorsque vous manquez de mémoire ou que quelque chose d'autre se produit. Ainsi, vous pouvez à peu près être assuré que quoi que vous ajoutiez, vous l'ajouterez très probablement dans le cache. Ainsi, Async vous donne toujours un coup de pouce supplémentaire. Ainsi, l'API semble très simple comme vous pouvez le voir.
Garder le cache à jour
Ainsi, lorsque vous effectuez la mise en cache des données d'application, comment maintenez-vous le cache à jour ? C'est vraiment très important. Il existe différentes manières de mettre en cache.
Utilisation des expirations basées sur le temps
Expirations, presque tous les caches prennent en charge les expirations. Il y a une expiration absolue où vous obtenez cette spécification pour chaque élément, voici combien de temps je me sens à l'aise pour qu'il reste dans le cache, cela peut aller de 15 secondes à des heures, des jours et des semaines. Et c'est pour la mise en cache des données d'application. Il existe une autre expiration appelée expiration glissante qui n'est pas destinée à synchroniser le cache avec la base de données. C'est pour le nettoyage. Donc, cet ASP.NET, toutes les données transitoires dont nous avons parlé, eh bien, que se passe-t-il lorsque vous avez terminé avec ces données ? Vous ne devriez pas avoir à vous soucier de le nettoyer. Ainsi, vous pouvez spécifier une expiration glissante et dire si personne n'utilise ces données pendant aussi longtemps, disons, dans le cas de sessions de 20 minutes, si personne n'utilise la session pendant ces 20 minutes, supprimez-les du cache. Donc, c'est plus un nettoyage.
Quels sont les risques en expiration ? L'expiration est en fait, vous faites une supposition. Vous dites, je pense que je suis d'accord avec cinq minutes, mais il n'y a aucune garantie que personne ne mettra à jour ces données dans la base de données pendant ce temps, surtout si vous avez d'autres applications ou d'autres processus mettant à jour la base de données. Ainsi, les expirations ne sont bonnes que dans des cas d'utilisation limités.
Utilisation des dépendances de base de données
Une autre caractéristique très importante est que vous pouvez avoir des mises à jour inattendues ou imprévisibles dans la base de données. Si tel est le cas, le cache doit pouvoir se synchroniser avec la base de données. Ainsi, le cache devrait connaître votre base de données. Il doit devenir un client de votre base de données et surveiller votre base de données pour tout changement. Il existe une fonctionnalité dans ADO.NET appelée dépendance SQL. Quelqu'un a-t-il vu ça ?
Donc, la dépendance SQL est ce que NCache utilise pour devenir client de votre serveur SQL ou de votre base de données Oracle. Ainsi, dans le cas d'un serveur SQL, vous pouvez utiliser la dépendance SQL de la fonctionnalité ADO.NET du serveur SQL qui NCache utilise pour obtenir des événements de la base de données. La Cachette, NCache devient client de votre base de données. Il reçoit des événements et ensuite, en fonction de cela, il fait son propre truc. Dans certains cas, vous n'avez pas d'événements. Donc, disons que si vous aviez db2 ou MySQL, ils n'ont pas d'événements. Ainsi, le cache devrait pouvoir effectuer des interrogations. NCache prend également en charge l'interrogation basée. Donc, vous faites la même chose, vous cachez cet élément dans le cache et vous dites que cela correspond à cette ligne dans ce tableau, puis NCache effectuera l'interrogation, puis si ces données changent, il les supprimera à nouveau du cache ou rechargera une nouvelle copie. Mais, cette fonctionnalité, elle vous donne beaucoup de confort.
Encore une fois, la même chose dont je parlais, c'est que vous voulez vous assurer que le cache est toujours synchronisé avec la base de données. L'expiration n'est suffisante que pour un petit sous-ensemble des cas d'utilisation.
Ainsi, vous obtiendrez un manque de cache si vous ne faites pas de rechargement automatique. Ainsi, lorsque vous lancez la dépendance SQL, elle supprime, NCache supprime l'élément du cache. Donc, si votre application le veut alors, ce sera un manque de cache et vous serez alors obligé d'aller chercher une nouvelle copie de la base de données. Si vous ne voulez pas manquer de cache, ce qui se trouve dans de nombreuses applications de commerce électronique, car elles lisent des données si fréquemment qu'elles ne veulent rien pour augmenter la charge sur la base de données, vous utiliserez en fait la dépendance SQL avec cette fonctionnalité appelée lecture continue.
En fait, je dois vous montrer du code sinon ça commence à devenir très ennuyeux. Alors, laissez-moi vous montrer rapidement. Donc, j'ai juste une application console très simple. En cas de NCache, tout ce que vous avez à faire est d'ajouter quelques assemblages ici. Donc, il y a NCache.Exécution et NCache.La toile. Ensuite, vous spécifiez des espaces de noms ces deux, puis vous vous connectez au cache et vous avez votre poignée de cache, puis vous créez un objet, puis vous faites Cache.Add. Et, vous spécifiez la clé. Ce n'est pas une bonne clé. Je voulais le changer, mais votre clé devrait contenir la valeur réelle. Donc, vous faites un Cache.Add et vous spécifiez l'objet.
Dans ce cas, j'utilise également une expiration absolue d'une minute. Donc, vous spécifiez l'expiration absolue et c'est tout. C'est tout ce que vous faites pour l'ajouter au cache. La prochaine fois que vous en aurez besoin, vous ferez simplement un Cache.Get, spécifierez la même clé et vous récupérerez l'objet. Très très simple pour une expiration absolue. Vous pouvez faire la même chose pour l'expiration glissante. Cependant, au lieu de spécifier une valeur absolue, vous devez spécifier un intervalle comme 10 minutes ou 20 minutes. La dépendance SQL est ce que je voulais vous montrer. À quoi il ressemble. Là! Donc, le même type d'application. Vous avez juste besoin d'ajouter ces deux ici et vous spécifiez les espaces de noms, puis lorsque vous allez ajouter les éléments au cache, c'est lorsque vous spécifiez la dépendance SQL.
Permettez-moi de passer à la définition de celui-ci. Donc, je vais ajouter ceci au cache ici. Donc, j'ai ma clé qui est ce que je vous ai montré la dernière fois. Maintenant, au lieu d'ajouter l'objet, je vais ajouter un élément Cache. C'est un NCache structure. Ainsi, il stocke l'objet réel et il stocke également une dépendance SQL. Alors, NCache a un objet de dépendance de cache. Donc, je fais une nouvelle dépendance SQL Cache. C'est un NCache classe qui correspond en interne à la dépendance SQL des serveurs SQL. Ainsi, vous lui transmettez une chaîne de connexion et la chaîne de connexion est votre chaîne de connexion au serveur SQL et vous lui transmettez une instruction SQL. Donc, ici, dans mon cas, j'ai spécifié select this où l'ID de produit est quelle que soit ma valeur. Donc, je le mappe simplement sur une ligne de la table des produits. Et, en le précisant tant que ça, je viens maintenant de dire NCache devenir un client du serveur SQL. Et, supprimez cet élément si cela change, si cette ligne change dans la base de données.
Donc, cela dépend de la nature de l'instruction SQL. Donc, si la méthode de séquence ne contient qu'une seule ligne, elle est mappée pour ne faire qu'une seule ligne et c'est ce que ça va être. Habituellement, vous ne pouvez pas faire de jointures et c'est la limitation de la fonctionnalité de dépendance SQL dans ADO.NET mais, pour une seule table, vous pouvez facilement le faire. Donc, c'est comme ça que vous feriez le…
Ainsi, le serveur SQL a cette chose appelée courtier SQL. Ainsi, il crée en fait un ensemble de données ou une structure de données sur le serveur SQL pour surveiller ces ensembles de données. Ainsi, toutes les dépendances SQL que vous créez, le serveur SQL crée des structures de données pour aller surveiller les ensembles de données. Et, sur cette base, il vous envoie une notification SQL.
Donc, vous devez configurer cela du côté du serveur SQL car c'est aussi une question de sécurité, donc votre base de données doit s'impliquer dans la configuration du serveur SQL, mais c'est assez simple. Je veux dire qu'il n'y a pas de programmation ou quoi que ce soit nécessaire sur le serveur et juste une configuration. Tout est pris en charge par le client.
Lecture et écriture
D'accord! Donc, nous avons fait la dépendance SQL. Je voulais vous montrer que si vous ne voulez pas supprimer cet élément du cache, vous pouvez effectuer un rechargement via une lecture. Ainsi, la lecture est une autre fonctionnalité très très puissante.
La lecture est un code côté serveur. En fait, la lecture est votre code qui s'exécute sur le cluster de cache. Ainsi, vous enregistrez réellement votre code et il s'exécute sur le cluster de cache. ça s'appelle bi NCache. Et, la valeur d'une lecture continue… laissez-moi d'abord vous montrer à quoi ressemble une lecture continue et je vous montrerai quelle est la valeur, je veux dire pourquoi voulez-vous faire la lecture continue. Alors, voici à quoi ressemble une lecture typique. C'est une interface IReadThrough. Vous faites un InIt pour pouvoir vous connecter à vos sources de données. Vous procédez à une élimination, bien sûr, puis il y a un chargement à partir de la source. Il transmet votre clé et attend un élément de cache. Ainsi, l'élément de cache contient votre objet et un tas d'autres choses que vous pouvez spécifier des expirations et d'autres choses à l'intérieur. Interface très simple.
Ceci est appelé par NCache Donc, vous implémentez cette interface et vous enregistrez votre assembly. En cas de NCache, vous enregistrez votre assemblage avec le cache et maintenant, lorsque vous effectuez un Cache.Get et que cet élément n'existe pas dans le cache, le cache sera en fait, NCache appellera votre lecture pour aller la chercher à partir de vos sources de données. Votre source de données peut être une base de données, un ordinateur central, n'importe quelle source de données. Ainsi, en ayant une lecture continue, vous pouvez vous assurer qu'un cache contient toujours les données et ce que l'application voit. Donc, c'est un avantage.
Le deuxième avantage est le rechargement qui… Ainsi, vous pouvez réellement combiner la lecture. Ainsi, vous pouvez à l'expiration et à la synchronisation de la base de données, lorsque l'élément devait autrement être supprimé du cache et que vous ne voulez pas qu'il soit supprimé car vous allez simplement le recharger de toute façon. Alors, pourquoi ne pas recharger le cache pour vous de cette façon, car si vous pensez à cela, vous avez des millions d'éléments dans le cache et ils expirent tous tout le temps, n'est-ce pas ? Parce que c'est ainsi que vous l'avez configuré. Et, vous avez un e-commerce et une application à très fort trafic et chaque fois que quelque chose expire, vous avez beaucoup de demandes simultanées pour cela. Ils iront tous dans la base de données. Ainsi, tout à coup, le trafic de la base de données a augmenté sans raison, même si vous n'en avez de toute façon pas besoin dans le cache.
Donc, puisque cela continue à se produire tout le temps, vous verrez beaucoup de pics dans le trafic de la base de données malgré le cache. Donc, c'est là que, avoir un rechargement signifie qu'il n'est jamais supprimé du cache. Il est juste mis à jour. Ainsi, vos applications n'iront jamais dans la base de données. Ils continueront à récupérer l'ancienne copie jusqu'à ce que vous la mettiez à jour. Ainsi, vous avez soudainement supprimé ou pris en charge ce problème où, même si vous aviez le cache, vous voyiez beaucoup de pics dans le trafic de la base de données en raison des expirations ou de la synchronisation de la base de données. Donc, en faisant recharger le cache tout au long de la lecture, cela le rend vraiment très puissant.
L'autre avantage de la lecture continue, bien sûr, est que vous centralisez, vous simplifiez le niveau application car de plus en plus d'accès à la base de données sont effectués par le cache. Ainsi, si vous avez plusieurs applications accédant aux mêmes données, vous pouvez véritablement centraliser l'accès aux données au sein du niveau de mise en cache. Bien sûr, vous ne pouvez pas le faire pour toutes les données, mais pour une grande partie des données, vous le pouvez.
L'écriture continue fonctionne de la même manière que la lecture continue. Permettez-moi de passer à l'écriture. Cela fonctionne de la même manière. Il a un fournisseur d'écriture immédiate, encore une fois InIt, éliminé et maintenant, au lieu de charger, il s'agit d'une écriture sur la source de données et d'un autre type d'écriture en bloc. L'écriture, un avantage est le même que la lecture, c'est-à-dire que vous centralisez tout. Le deuxième avantage est que vous pouvez faire une écriture différée, c'est-à-dire que vous mettez à jour le cache qui est, comme je l'ai dit, dix fois plus rapide que la base de données, puis vous demandez au cache d'aller mettre à jour la base de données. Et, l'écriture différée est essentiellement la même que l'écriture continue, mais effectuée de manière asynchrone. C'est une file d'attente qui est créée et qui est traitée. Cette file d'attente est également répliquée en cas de NCache. Ainsi, aucune des mises à jour n'est perdue si l'un des serveurs tombe en panne. Mais l'écriture différée accélère vraiment l'application parce que, je veux dire, vous l'avez déjà rendue plus rapide en mettant en cache toutes les lectures, n'est-ce pas ? Ainsi, environ 70 à 80% des lectures sont maintenant ou les transactions vont de toute façon dans le cache. Pourquoi ne pas également accélérer les écritures ? Si vous pouvez le faire en écriture différée, si vous pouvez vous permettre de faire une écriture asynchrone. Si les données sont trop sensibles là où vous ne pouvez pas vous le permettre, vous effectuez une écriture directe, vous n'obtenez que le premier avantage qui est la centralisation du code. Le deuxième avantage de performances plus rapides ne vient que si vous pouvez faire de l'asynchrone.
Conclusion
L'idée est que lorsque vous commencez à faire de la mise en cache, ne pensez pas à un cache qui n'est qu'une simple valeur de clé ici, je veux dire, mon objectif était d'abord de vous convaincre que vous avez vraiment besoin d'un cache distribué dans le cadre de votre infrastructure et l'architecture de l'application. Si vous voulez que les applications évoluent, vous devez incorporer cela indépendamment du produit de mise en cache que vous utilisez, je veux dire, vous devriez simplement l'avoir. Actuellement, pour les utilisateurs de .NET, les options sur le marché sont NCache qui est une source ouverte et également commerciale. Il y a Redis que Microsoft a mis à disposition sur Azure au moins. Sur Azure, c'est un service de cache géré, en dehors de celui-ci, vous devez l'installer et il s'installe principalement sur Linux, sauf si vous utilisez la version open source non prise en charge. Du côté Java, il y a beaucoup plus d'options sur la mise en cache. Donc, c'était le premier de tous.
Deuxième objectif il faut le comprendre, ce n'est pas une simple valeur clé. Vous voulez vous assurer que vous pouvez mettre en cache toutes sortes de données et gérer toutes sortes de situations, c'est là que vous obtenez le véritable avantage. Et, je n'ai même pas abordé l'autre partie parce que je manque de temps, par exemple, comment faire le partage de données d'exécution et quelles sont certaines des choses architecturales que vous voulez vous assurer que le cache est toujours dynamique afin que vous puissiez configurer les choses. Cela fait partie de votre centre de données, cela fait partie de votre environnement de production. Ainsi, tout cache qui ne vous permet pas d'apporter des modifications au moment de l'exécution n'est pas un bon cache à choisir car. Ensuite, vous serez coincé avec beaucoup de temps d'arrêt, nous avons des clients qui ont programmé des temps d'arrêt une fois par an, vous savez. Ainsi, certains de nos clients n'ont même pas cela parce qu'ils ont une disponibilité si élevée.
Ils veulent même mettre à niveau le cache lui-même vers une nouvelle version sans temps d'arrêt. Donc, je veux dire, cela dépend des besoins de votre entreprise. Mais, toutes ces choses doivent être prises en compte, beaucoup de gens ont maintenant plusieurs centres de données. Au moins à des fins de reprise après sinistre, puis également pour l'équilibrage de charge géographique, si vous en avez, vous vous attendez à ce que votre base de données se réplique, n'est-ce pas ?
Alors, pourquoi le cache ne pourrait-il pas prendre en charge plusieurs centres de données ? Parce que moins une cache peut faire, plus vous auriez à faire. C'est la ligne du bas. Parce que les besoins de votre application ne changeront pas, le cache doit s'adapter. Alors, gardez tout cela à l'esprit.
Donc, il y a une comparaison entre NCache ainsi que Redis.
Ils sont tous les deux open source. NCache a également Enterprise Edition. Donc, fondamentalement, si votre .NET, NCache s'intègre très bien. Dans le NCache, N signifie .NET, en bout de ligne, je veux dire que c'est à quel point nous sommes engagés envers .NET.