NCache Architecture
Aujourd'hui, je vais parler de NCache Architecture. NCache est un magasin distribué en mémoire pour les applications .NET et Java. C’est extrêmement rapide et évolutif. Et vous pouvez l'utiliser dans vos applications serveur à transactions élevées pour améliorer les performances et l'évolutivité de vos applications.
Utilisations courantes de NCache
Cache distribué
Les deux manières courantes NCache est utilisé. Le numéro un est comme un Cache distribué où vous mettez en cache les données de l'application pour réduire ces déplacements coûteux dans la base de données et, le numéro deux est un Messagerie et flux plate-forme. Je vais passer brièvement en revue ces deux éléments avant d'entrer dans l'architecture.
-
Mise en cache des données d'application
Ainsi, dans le cache distribué, la mise en cache des données d'application signifie que vous utilisez un NCache L'API sert généralement à simplement mettre en cache les données de votre application. Vous n'avez donc pas besoin d'accéder à la base de données aussi fréquemment, car le cache est beaucoup plus rapide que la base de données. Il est également plus évolutif car il est en mémoire, donc c'est rapide. Il est proche de votre application donc rapide et distribué donc évolutif. Et, si vous disposez d’une application .NET et que vous utilisez EF Core, vous pouvez utiliser NCache via EF Core également, ainsi que NHibernate et EF 6. Si vous disposez d'applications Java, vous pouvez utiliser NCache en tant que cache Hibernate de deuxième niveau. Vous pouvez également utiliser with comme Spring Cache ou le programmer avec JCache. -
Mise en cache des applications Web
La deuxième partie de l'utilisation du cache distribué est, si vous avez des applications Web, que vous pouvez stocker vos séances en NCache et puis NCache réplique ces sessions sur plusieurs serveurs, de sorte que s'il y en a un NCache serveur qui tombe en panne, vous ne perdez aucune donnée mais ces sessions sont encore une fois très évolutives car c'est un magasin distribué et c'est évidemment ultra-rapide. Il existe également une fonctionnalité de session multi-site disponible dans tous les langages .NET, Java, Nodejs, etc. En plus des sessions, par exemple pour .NET 6, ASP.NET Core les applications peuvent stocker leurs Cache de réponse dans NCache et ils peuvent également utiliser NCache car fond de panier pour SignalR. SignalR est destiné aux applications Web en direct où l'application Web doit envoyer des événements aux clients. Et puis, si vous utilisez .NET 4.8, vous pouvez également stocker votre état de session, Afficher l'état, Cache de sortie, et aussi SignalR.
NCache pour les applications critiques
Laissez-moi vous montrer rapidement ce NCache ressemble à. Voici ce qu’est un cache distribué pour les applications critiques. J'utilise le mot « mission critique » car dans la plupart des cas, nous constatons que les clients utilisent NCache dans des applications très sensibles orientées client et très importantes pour leur entreprise. Donc, NCache fait, vous savez, une partie de votre infrastructure très critique dans ce cas.
Et ce sont, comme je l’ai dit, des applications serveur qui génèrent de nombreuses transactions. Ce sont des applications Web. Il s'agit de microservices, d'API Web ou d'autres applications serveur. Évidemment, vous pouvez utiliser .NET, Java, Node.js ou Python. Et ces applications tentent d'accéder à votre base de données soit en tant que SQL Server, Oracle, Db2, MySQL ou toute autre base de données relationnelle, soit elles accèdent peut-être à vos données mainframe héritées, soit elles utilisent un NoSQL database comme Mongo DB, Cosmos DB, Cassandra ou autres. Dans cette situation, NCache devient un cache distribué par… vous utilisez NCache en tant que deux serveurs ou plus en tant que niveau de mise en cache distinct, bien que vous n'ayez pas besoin d'un niveau de mise en cache distinct, votre application peut s'exécuter dans la même boîte que NCache et fonctionne parfaitement, mais l'architecture de déploiement la plus populaire consiste à avoir un niveau de mise en cache séparé, c'est juste une façon plus propre d'utiliser NCache.
Supposons que vous commenciez avec un cluster de cache à 2 serveurs, NCache grappe, NCache regroupe la mémoire, le processeur et les ressources de la carte réseau de tous ces serveurs en une seule capacité logique et, disons, vous placez plus de charge de transaction via vos applications sur NCache et ces deux serveurs sont bien optimisés, vous pouvez facilement ajouter un troisième serveur, ou un quatrième serveur, ou un cinquième serveur et, ainsi de suite, NCache ne devient jamais un goulot d'étranglement. C'est quelque chose que vous ne pouvez pas faire avec vos bases de données. Les bases de données ne sont pas évolutives. NoSQL est évolutif, mais, dans la plupart des cas, nous avons constaté que les utilisateurs doivent utiliser des bases de données relationnelles pour diverses raisons commerciales et qu'ils disposent également d'ordinateurs centraux existants. Ainsi, parce que la couche de stockage des données n'évolue pas NCache aide votre application à évoluer en vous permettant de mettre en cache autant de données que possible. L'objectif général est d'avoir environ 80 % du temps pendant lequel vous devriez trouver les données de NCache plutôt que d'aller dans votre base de données. Si vous parvenez à atteindre ce ratio, vous savez, vous avez soulagé les bases de données et votre application va évoluer.
Messagerie et flux
Le deuxième cas d'utilisation courant, ou utilisation de NCache est de l'utiliser comme une plate-forme de messagerie et de flux sur laquelle vous pouvez avoir plusieurs applications pouvant communiquer entre elles via Messagerie Pub/Sub, par Requête continueou NCache événements basés sur. Laissez-moi vous montrer à quoi cela ressemble. Ainsi, par exemple, si vous disposez d'une application serveur à transactions élevées qui doit effectuer beaucoup de messagerie en temps réel ou de traitement de flux, vous pouvez utiliser NCache. Maintenant pareil NCache qui était un cache distribué devient désormais une plateforme de messagerie et de flux. Encore une fois, il s'agit d'un magasin distribué en mémoire. Il évolue de manière linéaire. Il réplique les messages sur plusieurs serveurs. En fait, NCache contient également de la persistance.
Ainsi, avec cela, vous pouvez avoir différentes applications, par exemple, la messagerie Pub/Sub est un moyen très populaire, c'est une méthodologie, c'est un paradigme dans lequel vous avez plusieurs éditeurs et plusieurs abonnés qui peuvent communiquer entre eux de manière découplée. Découplé signifie que l'éditeur ne sait pas qui est l'abonné, il publie simplement des messages sur certains sujets et ces abonnés peuvent les obtenir. Les requêtes continues fonctionnent de la même manière. Voilà donc les deux manières courantes NCache est utilisé.
Applications .NET et Java
Parlons maintenant de la façon dont NCache gère les applications .NET et Java. NCache a une capacité multiplateforme native très unique que vous trouverez très intéressante, laissez-moi y entrer.
Édition .NET
NCache essaie de vous fournir une solution native pour .NET et Java. Et, par là, je veux dire que lorsque vous avez une application .NET, l’ensemble de votre pile d’applications fait l’expérience de .NET, vous n’utilisez rien d’autre que .NET. Ainsi, par exemple, NCache dispose d'un client .NET natif que votre application va utiliser sur votre application. Cela s'exécute sur votre serveur d'applications et NCache a développé cela en 'C Sharp' (C#), à 100 %.
De même, si vous avez du code côté serveur tel que Read-through, Write-through, Right-behind, Loader/Refresher que vous avez écrit en .NET, NCache exécutera ce code dans son propre processus .NET CLR. Laisse moi te montrer comment. Et je reviendrai sur ce diagramme dans les deux sens. Ainsi, par exemple, voici un NCache architecture, vous disposez ici d’une application .NET qui peut s’exécuter sous Windows ou Linux. Il a un natif NCache Client .NET. Et cela parle à un NCache cluster qui est une édition .NET NCache Grappe. Cela signifie donc que le code côté serveur est également .NET.
Maintenant, la façon NCache est architecturé et, c'est pourquoi ce qui le rend vraiment puissant pour le support natif multiplateforme, c'est qu'il existe un processus de cache, il existe un processus de gestion, ceux-ci sont distincts de votre processus de code côté serveur. Et il existe un RPC très performant. C'est un RPC en mémoire qui NCache utilise, que NCache a développé son propre RPC propriétaire ultra-rapide. C'est ainsi que le cache communique avec votre code côté serveur. Ainsi, par exemple, s'il doit appeler le gestionnaire de lecture, votre gestionnaire de lecture s'exécutera dans ce processus .NET CLR pour accéder à votre base de données pour obtenir les données, puis il les transmettra au cache. Et la même chose vaut pour l’écriture directe, le chargeur et le rafraîchissement. Ainsi, toute l’expérience de votre application est .NET.
Édition Java
Eh bien, passons du côté Java. Encore une fois, de la même manière, vous disposez d’un code Java côté serveur. NCache dispose d'un client 100% Java qui s'exécute sur votre serveur d'applications puis de la même manière que .NET. Voici l'édition Java. Disons que vous disposez d'une application Java qui fonctionne probablement sous Linux, ou peut-être même sous Windows, peut-être Docker, peut-être Kubernetes. Ainsi, cette application intégrera le NCache Client Java qui, comme je l'ai dit ici, est 100% Java natif, puis ce client Java est une base identique au client .NET. Il parle également au NCache Cluster de la même manière que le client .NET en utilisant NCachele propre protocole de socket propriétaire de et le NCache Le serveur est architecturé de manière à ce que votre code Java côté serveur s'exécute sur sa propre JVM.
Ainsi, tous les développements, tests et débogages que vous effectuerez se feront tous dans des processus JVM natifs. Et ce processus de cache appellera, disons, le gestionnaire de lecture qui ira, disons, peut-être dans Oracle ou Db2, ou même la base de données SQL Server, et récupèrera les données et les transmettra au processus de cache. Encore une fois, le même RPC en mémoire hautes performances est utilisé. Ainsi, en ayant une architecture qui encapsule en quelque sorte le code .NET et Java dans leurs propres processus natifs, NCache est capable de vous fournir une pile native pour Java et .NET.
Et, encore une fois, dans le cas d'une application Java, vous souhaiterez peut-être effectuer votre développement sous Windows ou Mac OS et NCache le prend entièrement en charge, ou même Linux, et vous êtes alors plus susceptible d'utiliser Docker et Kubernetes que les utilisateurs de .NET. NCache vous fournit les images Docker, mais également un support complet pour Kubernetes, Azure AKS, AWS EKS, Google GKE ou Red Hat OpenShift. Vous pouvez l’utiliser de manière très fluide.
Alors, NCache est très unique. Il vous offre une expérience .NET native et en même temps une expérience Java native. Ainsi, si vous êtes une boutique Java, vous n'avez pas l'impression d'utiliser un produit non Java et si vous êtes une boutique .NET, vous n'avez pas l'impression d'utiliser un produit non Java. Produit NET. C'est la beauté de NCache la façon dont il est architecturé.
Cluster dynamique
Bon, passons maintenant au Clustering Dynamique une partie de NCache Architecture destinée à la haute disponibilité. Et, une seconde, d'accord. Ainsi, la première partie est le cluster dynamique. Lorsque j'utilise le mot cluster, je ne parle pas de cluster Kubernetes, ni de tout autre cluster au niveau du système d'exploitation. C'est NCachepropre cluster basé sur TCP. Et ce cluster a une architecture peer-to-peer. Ce que signifie le peer-to-peer, c'est qu'il n'y a pas de maître, ni d'esclave. Le problème du maître/esclave est que si le maître tombe en panne, l'esclave devient inopérant ou devient limité, alors que dans une architecture peer-to-peer, chaque nœud est également capable. Il existe évidemment un nœud coordinateur de cluster, qui est le nœud le plus ancien et, si ce nœud tombe en panne, le prochain plus ancien est automatiquement sélectionné comme coordinateur de cluster. Le coordinateur du cluster s'occupe de l'adhésion au cluster. Il gère la carte de distribution, la santé du cluster et bien d'autres choses que je vais aborder en partie.
Le clustering dynamique signifie que vous pouvez ajouter ou supprimer des serveurs au cluster au moment de l'exécution sans arrêter le cache ou votre application. Il n'y a aucune interruption. Et, disons, si vous ajoutez un nouveau serveur au cluster, l'appartenance au cluster est évidemment mise à jour au moment de l'exécution et ces informations d'exécution sont ensuite propagées aux clients. Et j'en parlerai un peu plus dans la diapositive suivante.
Il existe également une fonctionnalité de basculement de connexion au cluster. Donc, comme il s'agit de sockets, même si les serveurs de cluster se trouvent généralement dans le même sous-réseau, assez proches les uns des autres, cela n'est pas toujours le cas. Nous avons des clients qui ont même des serveurs déployés dans différentes régions et cela fonctionne parfaitement bien même si nous recommandons que dans la plupart des cas, le NCache les serveurs doivent être assez proches les uns des autres. Mais il peut toujours y avoir un échec de connexion. Si c'est le cas NCache a une logique de tentatives et il y a des délais d'attente. Il y a une logique de battement de cœur, tout cela est pour s'assurer que tout est dynamique.
Clients dynamiques et configuration dynamique
Connexions client dynamiques
L'autre partie de l'architecture dynamique est constituée des clients dynamiques. Ainsi, tout comme cela, le cluster avait la possibilité d'ajouter ou de supprimer des serveurs au moment de l'exécution. Vous avez également la possibilité d'ajouter ou de supprimer des clients au moment de l'exécution. Que veut dire un client ? Un client est le NCache Client qui s'exécute sur votre serveur d'applications, votre serveur Web, c'est la partie avec laquelle votre application communique. Ainsi, vous pouvez ajouter un client au moment de l'exécution, vous pouvez supprimer un client au moment de l'exécution sans vous arrêter NCache, le cache ou votre application sans aucune interruption. Voilà donc la première partie.
Configuration dynamique
La deuxième partie est la configuration dynamique. Ainsi, comme je l'ai mentionné dans la dernière diapositive, lorsque vous ajoutez un serveur au cluster, l'appartenance au cluster change. Eh bien, cela se propage à tous les clients existants qui sont connectés, de sorte qu'ils savent maintenant qu'il y a un nouveau serveur auquel ils doivent se connecter. Ainsi, s’ils choisissent de le faire en fonction de la topologie de mise en cache, ils peuvent également se connecter à ce serveur. De plus, selon la topologie, il peut y avoir une carte de distribution. Une carte de distribution est davantage destinée au cache partitionné et au cache de réplique partitionnée. Mais, à mesure que vous ajoutez un serveur, il est mis à jour et cela se propage au moment de l'exécution. Et aussi un tas d’autres changements de configuration. Il existe une fonctionnalité d'application à chaud que vous pouvez utiliser et qui se propage au moment de l'exécution. Voilà donc la deuxième partie.
Basculement de la connexion client
La troisième partie est, encore une fois, un basculement de connexion client qui est le même que le basculement de connexion de cluster. Mais cela est en fait encore plus nécessaire car les clients ne seront probablement pas toujours très proches des serveurs du cluster. Et il peut s'agir de routeurs ou de pare-feu entre les deux. Ainsi, la connexion entre les clients et le cluster est plus susceptible d'être rompue. Donc, NCache a une capacité de nouvelle tentative assez intelligente, un délai d'attente. Il existe également une capacité de maintien en vie, de sorte que le client reste connecté même si la connexion est interrompue, le client se reconnecte au NCache Groupe.
Détection et récupération du cerveau divisé
Un autre sujet important concernant l'aspect dynamique de NCache L'architecture est le cerveau divisé. Le Split Brain est un phénomène qui peut se produire dans le cluster.
Un cerveau divisé se produit lors de la rupture de la connexion
Et, Split Brain se produit chaque fois que, disons, si vous disposez d'un cluster sain de six serveurs, un split-brain se produit lorsque la connexion entre certains de ces serveurs est interrompue pour une raison quelconque et, chaque fois que vous avez des connexions réseau, elles peuvent être interrompues. Et nous le voyons tout le temps. Ainsi, lorsque cela se produit, des sous-clusters se forment. Disons que dans ce cas, il y a une division 1, une division 2, une division 3. Chaque sous-cluster pense qu'il est le survivant. Ainsi, il crée son propre coordinateur de cluster et devient un cluster indépendant.
Détection de cerveau divisé
Cependant, toutes ces scissions rappellent qu'ils faisaient partie d'un cluster sain et que ces serveurs ne sont pas partis volontairement, ils ne sont pas partis en douceur. Vous n'avez pas effectué de « quitter le nœud » à partir du NCache Outil de gestion, au lieu de cela, la connexion s'est rompue. Ils continueront donc à rechercher ces serveurs pour voir si la connexion réseau est rétablie. Et, la plupart du temps, cinq, dix minutes, une demi-heure, une heure plus tard, cette connexion sera probablement rétablie.
Récupération du Cerveau Divisé
Lorsque cela se produit, une récupération cérébrale divisée est effectuée. Et c’est là que ces divisions sont fusionnées. Ces sous-clusters sont fusionnés de manière itérative du plus grand au plus petit, et il y a évidemment une certaine perte de données car ils sont devenus des clusters indépendants et, maintenant, certaines données doivent être perdues. Mais tout se fait automatiquement en fonction des règles que vous spécifiez.
Il y a plus de détails sur le cerveau divisé dans un document séparé. vidéo mais cela vous donne en quelque sorte un aperçu. Il s'agit d'une fonctionnalité très importante qui garantit que votre NCache le cluster reste en bonne santé et peut récupérer chaque fois qu'une division du cerveau se produit.
Topologies de mise en cache
Ok, maintenant, passons à Topologies de mise en cache. Les topologies de mise en cache concernent essentiellement le stockage de données, les stratégies de réplication ainsi que les stratégies de connexion client. Il existe quatre topologies : le cache partitionné, la réplique de partition, le cache répliqué et le cache miroir. Allons-y avec le cache partitionné.
Cache partitionné
Cache partitionné est essentiellement que l'ensemble du cache est divisé en partitions, chaque serveur a une partition. Et il y a ce concept de seaux. Ainsi, chaque partition possède des compartiments. Un total de 100 buckets pour l'ensemble du cache. Ainsi, en fonction du nombre de partitions dont vous disposez, ces compartiments sont répartis uniformément entre eux.
Et ces partitions sont créées au moment de l’exécution, c’est la partie importante. Ainsi, lorsque vous ajoutez un serveur, une partition est créée. Disons que vous commencez avec un serveur, qu'il n'y a qu'une seule partition, les 100 buckets se trouvent dans cette partition. Si vous ajoutez un deuxième serveur au moment de l'exécution, non seulement les informations d'appartenance au cluster sont mises à jour, comme je l'ai mentionné dans les diapositives précédentes, mais la carte de distribution est désormais également mise à jour. Une carte de distribution est essentiellement une carte indiquant quelle partition contient quels compartiments. Supposons donc que si vous avez ajouté une deuxième partition, la carte de distribution sera désormais modifiée. Une carte de distribution est en fait une carte de hachage mappée à des compartiments. La valeur de la carte de hachage s'étend aux compartiments. Et cela ne change pas en fonction de la quantité de données que vous avez ajoutées, cela change uniquement lorsque vous modifiez le nombre de serveurs, le nombre de partitions ou que vous effectuez le rééquilibrage des données. Les partitions sont donc dynamiques.
Équilibrage dynamique des données
La deuxième partie concerne l’équilibrage dynamique des données. Ainsi, comme tout cela est basé sur une carte de hachage, il est très possible qu'en fonction du type de clés que vous avez utilisé, certains compartiments obtiennent plus de données que d'autres. Et vous vous retrouverez avec certaines partitions presque pleines et les autres presque vides. Et lorsque cela se produit, le NCache a cette fonctionnalité où vous pouvez définir un seuil. Disons que si une partition est pleine à plus de 80 %, supprimez-en 20 %, ou 10 %, ou 5 %. Pas supprimer, je veux dire équilibrer dynamiquement. Ainsi, l'équilibrage des données signifie prendre ces compartiments de la partition 1 et les copier vers une autre, ou les déplacer vers d'autres partitions. Ainsi, l'équilibrage des données garantit que les données et toutes les partitions sont assez égales.
Le client se connecte à toutes les partitions
Dans le cache partitionné, chaque client se connecte à toutes les partitions ou à tous les serveurs. La raison pour laquelle il le fait est qu'il souhaite accéder directement à l'élément de son choix en un seul appel. S'il n'était connecté qu'à un seul serveur, disons, et qu'il voulait l'élément numéro 3, il parlerait au serveur 1, le serveur 1 ira au serveur 2 et l'obtiendrait. Et il s’agit d’une opération à deux sauts qui n’est pas aussi optimisée que si le client pouvait accéder directement à l’endroit où se trouvent les données. Et le client le sait grâce à une carte de distribution. C'est pourquoi la carte de distribution est créée pour aider les clients à savoir où se trouvent les données, afin qu'ils puissent directement les récupérer à partir de là.
Ainsi, le cache partitionné n'a pas de réplication. Ainsi, si un serveur tombe en panne, vous perdez ces données. Il n'y a aucun moyen sauf si vous utilisez « Persistance » dont je vais parler dans un instant. Alors même le cache partitionné ne perd aucune donnée.
Cache de Partition-Réplica
Répliques de partitions (dynamiques)
La topologie suivante est le cache de réplique de partition. Il s'agit d'ailleurs de notre topologie la plus populaire car elle vous offre le meilleur des deux mondes. Il vous donne le partitionnement, qui est l'évolutivité. Et cela vous offre également une réplication qui correspond à la haute disponibilité. Il n’y a donc aucune perte de données. Ainsi, par exemple, c'est la même chose que le cache partitionné, tout est pareil mais chaque partition a désormais une réplique sur un serveur différent. Ainsi, la partition 1 se trouve sur le serveur 1, puis sa réplique est appelée Réplique 2, qui est, disons, dans ce cas sur le serveur XNUMX. Ainsi, tout comme les partitions ont été créées dynamiquement au moment, les répliques sont également créées au moment de l'exécution, lorsque les partitions sont ajoutés ou supprimés. Et ils sont évidemment toujours situés sur un serveur différent.
L'autre partie est que toutes les répliques sont passives. Passif signifie qu’aucun client ne leur parle directement. Les clients signifient qu'ils ne parlent qu'aux partitions et que les partitions mettent ensuite à jour leur réplique. Ainsi, chaque fois que vous mettez à jour quelque chose dans la partition, la partition le met à jour dans la réplique. Et cette mise à jour par défaut est asynchrone. L'asynchrone l'est, pour que cela puisse être plus rapide. Tout d’abord, le client n’a pas besoin d’attendre que cette réplication se produise, deuxièmement, vous pouvez effectuer une réplication en masse. Ainsi, vous pouvez combiner des centaines ou des milliers de ces mises à jour et les déplacer ou les transférer simultanément vers la réplique. Parce que le coût de ce voyage sur le réseau est beaucoup plus rapide ou beaucoup plus coûteux que la combinaison de données.
Réplication asynchrone/synchronisée
Cependant, la réplication asynchrone présente évidemment le fait qu'elle n'est pas toujours cohérente. Il est finalement cohérent, ce qui est suffisant dans peut-être 95 à 99 % des cas et il y a peut-être 1 à 5 % des cas où vous traitez des données très sensibles. Donc, vous ne voulez pas de réplication asynchrone, vous voulez une réplication synchrone. Il existe donc une fonctionnalité appelée Sync Replication que vous pouvez activer, et lorsque vous le faites, chaque fois que le client met à jour les éléments de la partition, cette opération ne se termine pas tant que la partition n'a pas mis à jour la réplique en premier. Ainsi, si cette réplication échoue, l’opération échoue. C'est ainsi que, vous savez, si l'opération réussit, la réplication réussit également. C’est donc une caractéristique très importante de ceci.
Et enfin, tout comme la topologie partitionnée, la topologie de cache partitionné, il existe également un équilibrage dynamique des données sur les répliques. Ainsi, lorsque les partitions sont équilibrées dynamiquement, les répliques doivent correspondre à cela car les répliques sont toujours une copie identique de la partition. Ainsi, ils passeront également par un équilibrage des données.
Partitionnement dynamique
Voyons maintenant rapidement comment se produit réellement le partitionnement dynamique. Donc, disons que si vous aviez un cluster de deux serveurs et que vous y aviez 6 éléments et que vous vouliez ajouter un troisième serveur, je n'ajoute pas encore plus de données car c'est un autre cas d'utilisation, c'est juste ainsi que les données sont déplacé vers d'autres partitions à mesure que vous ajoutez un autre nœud.
Disons que vous ajoutez un nœud. Il y a donc maintenant un troisième serveur. Ainsi, la partition 3 est créée et la partition 3 récupère maintenant les données de la partition 1 et de la partition 2. Ainsi, elle obtient des données de 1, d'autres de 2. Alors, disons, disons qu'elle prend l'élément 3 de la partition 1, l'élément 4 de la partition 2. et devient la partition 3.
Maintenant qu'il est devenu la partition 3, sa réplique doit être sur un serveur différent, donc, disons, elle est placée sur le serveur 1. Ainsi, le serveur 1 avait la réplique 2, il est converti en réplique 3, puis la réplique 2 est déplacée. dans le serveur 3. Ainsi, par exemple, la réplique 3 contiendra désormais 3, 4 au lieu de 4, 5, 6, et la réplique 2 contiendra 5, 6. Tout cela sera fait dynamiquement au moment de l'exécution sans que votre application ne le voie. toute interruption.
La même chose se produit à l'envers : si un serveur tombe en panne, disons que vous aviez trois partitions NCache Le cluster et le serveur 3 sont tombés en panne, soit vous l'avez arrêté, soit il est tombé en panne, dès que cela se produit, car la partition 3 n'est plus disponible. Réplique 3, comme vous pouvez le voir, j'ai changé sa couleur, elle devient active. Normalement, comme je l’ai dit, les répliques ne sont pas actives, n’est-ce pas ? Seules les partitions sont actives mais cela devient maintenant partitionné. Mais ce n'est que temporaire car vous ne voulez pas avoir deux partitions sur la même boîte et ensuite aucune réplique.
Donc, maintenant, cela se fusionne ici avec la partition 1, donc, disons, l'élément 3 va à la partition 1, l'élément 4 va à la partition 2, et votre situation est comme ceci ici et cette réplique 3 devient maintenant la réplique 2. Donc, le la même chose se produit à l'envers, tout au moment de l'exécution, partitionnement dynamique, très très flexible, très dynamique. Cette dynamique ajoute la puissance de haute disponibilité de NCache.
Mode de maintenance
Eh bien, bien que ce partitionnement dynamique soit très utile et très puissant, il existe certains cas où vous ne souhaitez pas répartir et l'un de ces cas est la maintenance planifiée. Disons que vous appliquez un correctif au système d'exploitation et que ce correctif va interrompre le serveur pendant cinq ou dix minutes. Eh bien, vous savez que l'ensemble de votre cluster de cache peut contenir des dizaines de gigaoctets de données. Donc, vous ne voulez pas répartir uniquement pendant ces cinq minutes, puis répartir à nouveau lorsque vous rétablissez ce nœud. Ainsi, vous pouvez activer une fonctionnalité de maintenance planifiée de NCache auquel cas lorsque vous abaissez ce nœud, vous devez encore une fois l'abaisser via votre outil de gestion, cela déclenche des choses selon lesquelles cette réplique devient active mais il n'y a pas de répartition.
Ainsi, il reste une configuration à deux serveurs avec la partition 1 Replica 3, la partition 2 Replica 1 et cette réplique 3 est en fait la partition 3, ce qui signifie qu'elle est active et qu'elle fonctionne. Évidemment, ce n'est pas une haute disponibilité car même si la partition 1 est sauvegardée ici. La partition 2 n'a pas de sauvegarde et la réplique 3 n'a pas de sauvegarde. Mais ce n’est que temporaire car vous n’en avez besoin que pendant 5, 10 minutes. Ainsi, une fois que ce serveur est redémarré, il revient à son ancien état et redevient une réplique lorsqu'il redevient une partition. C'est ainsi que la fonctionnalité de maintenance planifiée de NCache œuvres.
Cache répliqué
La topologie suivante s'appelle un Cache répliqué. Dans cette topologie, vous pouvez avoir deux serveurs ou plus sur lesquels chaque serveur dispose d'une copie complète du cache et chaque serveur est actif, ce qui signifie que chaque serveur a des clients qui y sont connectés. Mais ici, chaque client ne se connecte qu’à un seul serveur. Parce que ce serveur possède tout le cache. Ainsi, il n’est pas nécessaire de se connecter à deux serveurs comme une partition ou une réplique de partition.
Avec cette topologie, toutes les lectures sont ultra-rapides car tout le cache est là mais les mises à jour doivent être effectuées de manière synchrone. Parce que ces deux serveurs sont actifs, le même élément peut donc être mis à jour ici et ici simultanément et vous ne voulez évidemment pas vous lancer dans un problème d'intégrité des données. Donc, cela se fait de manière synchrone où il y a un schéma d'indexation, il y a un index, il y a en fait un numéro de séquence qui est émis, et chaque élément est mis à jour dans la même séquence. Cela permet donc que les mises à jour se fassent toujours de manière correcte. Cependant, le coût est qu'une mise à jour synchrone signifie que si vous avez un client qui met à jour l'élément 1, ce serveur informera l'élément 2 de mettre à jour l'élément 1. Lorsque les deux serveurs ont mis à jour l'élément 1 avec succès uniquement, la mise à jour est réussie et le contrôle il revient. Cela signifie donc que ce n'est pas aussi rapide que la topologie de partition ou de réplication de partition, mais l'opération est garantie. Si cette mise à jour réussit, cela signifie qu'elle est toujours effectuée sur tous les serveurs.
Cette topologie convient aux opérations intensives en lecture. Pour un cluster à deux serveurs, même les écritures sont assez rapides, pas aussi rapides qu'une réplique de partition mais raisonnablement rapides dans la plupart des situations. Cependant, à mesure que vous ajoutez des serveurs, les performances des mises à jour diminuent. En fait, cela devient plus lent car davantage de serveurs doivent être mis à jour de manière synchrone. Donc, cette topologie a ses propres utilisations, c'est pourquoi nous la conservons. Beaucoup de nos clients l'utilisent dans des situations particulières.
Cache en miroir
La quatrième topologie est appelée Cache en miroir. Il s'agit là encore d'une topologie très spécifique. Il s'agit d'une topologie à 2 nœuds uniquement. Il y a un nœud actif et un nœud passif. Encore une fois, le nœud actif possède l’intégralité du cache et une copie du cache se trouve sur le nœud passif. Tous les clients se connectent au nœud actif et mettent à jour le nœud actif pour tout le reste, et les mises à jour sont mises en miroir ou répliquées de manière asynchrone sur le nœud passif. Et ce caractère asynchrone signifie qu'il est également assez rapide, tout comme Partition Replica.
Dans cette topologie, si le nœud actif tombe en panne, le nœud passif devient automatiquement actif et tous les clients se déplacent automatiquement vers le nœud passif ou nouvellement actif. Et de cette façon, il n'y a pas de temps d'arrêt, il n'y a pas d'interruption et, c'est ce qu'on appelle la prise en charge automatique du basculement, c'est ce que je voulais dire par là. Et, évidemment, lorsque le nœud actif revient, il redevient actif, la même chose se produit en sens inverse.
Ainsi, Mirror Topology est également très utile pour les cas spécialisés. Il n'est pas évolutif au-delà de ces deux serveurs mais il a sa propre utilité du fait que tous les clients se connectent ici, et vous pouvez ensuite faire une réplique sur une autre machine. Je veux dire que cela pourrait être utilisé par exemple, en cas de situation de reprise après sinistre par exemple.
Persistance en direct
Une autre fonctionnalité très puissante de NCache est appelé Persistance en direct. La persistance en direct est disponible uniquement pour les topologies de partition et de réplica de partition. Elle est en direct, ce qui signifie que lorsque vous mettez à jour le cache au moment de l'exécution, le magasin de persistance est également mis à jour immédiatement. La mise à jour du magasin persistant est asynchrone. Ainsi, cela n'interfère pas avec les performances de votre application ou NCache performance. C’est ainsi que votre candidature peut rester très rapide. La persistance se fait au niveau du bucket. Ainsi, il y a 100 compartiments qui représentent l'intégralité du cache et qui sont conservés dans un NoSQL magasin de documents. Il s'agit d'un magasin basé sur des fichiers, ce n'est donc pas un magasin basé sur un serveur. Ce n'est pas un NoSQL database serveur, c'est un NoSQL magasin de documents qui NCache les usages. Vous pouvez l'utiliser dans un emplacement commun à tous les serveurs du NCache cluster, et de cette façon, ils peuvent tous s’appuyer sur le même magasin persistant.
Certains des avantages de ceci, et la raison pour laquelle cette fonctionnalité est fournie, sont que, quoi que vous persistiez, vous pouvez, par exemple, conserver l'intégralité du cache, et l'intégralité du cache est toujours conservée. Vous pouvez dire que tout ce que vous mettez à jour dans le cache est, vous savez, à quelques millisecondes près, il est également conservé dans le magasin persistant. Ainsi, vous pouvez prendre cela et le recharger dans un cache différent, ou si tous les serveurs devaient tomber en panne, vous pouvez toujours les redémarrer à partir des magasins persistants. Vous ne perdez aucune donnée, sauf une très très petite quantité de données. Ou peut-être que vous souhaitez transférer le cache d'un environnement à un autre, vous pouvez facilement le faire.
L'autre avantage est qu'il ajoute en réalité une plus grande disponibilité aux topologies de partition et de réplique de partition. Eh bien, la topologie des partitions, et j'y reviendrai ici. Ainsi, le cache partitionné, comme je l'ai mentionné plus tôt, n'a aucune réplication, donc, si une partition ou un serveur tombe en panne, vous perdez cette partition, n'est-ce pas ? Eh bien, si vous faites preuve de persévérance, vous ne le faites pas. Parce qu'une copie de ces données est également conservée dans ces compartiments. Ainsi, si ce serveur devait descendre, les compartiments en mémoire seront réaffectés mais évidemment sans données vers d'autres serveurs et maintenant ces serveurs savent qu'il s'agit de compartiments vides dont les données existent dans le magasin de persistance, ils rechargeront donc ces données à partir de la persistance. magasin.
C'est ainsi que vous ne perdez aucune donnée même si un serveur tombe en panne, même si vous utilisez le cache partitionné. Et vous bénéficiez des mêmes avantages qu'une réplique de partition et un cache partitionné.
L'avantage que vous obtiendrez ici est que vous pourrez utiliser plus de mémoire. Vous pouvez stocker plus de données dans le cache car ici, vous devez allouer plus de mémoire pour la réplique que vous n'êtes pas obligé d'allouer ici, mais vous devez allouer le magasin de persistance. C'est donc l'avantage du cache partitionné. Partition-Replica présente également des avantages. Et c'est assez intéressant, même si cela vous donne déjà une haute disponibilité, mais si la haute capacité ne se produit que si un serveur tombe en panne à un moment donné, mais, disons, si deux serveurs tombaient en panne simultanément sans même persistance dans Partition-Replica, vous perdriez des données. Parce que, vous savez, il n'y a qu'une seule copie de chaque partition et si deux serveurs tombaient en panne, vous perdriez plus de serveurs que vous ne pouvez vous le permettre. Eh bien, avec la persistance, vous n'avez aucun problème, vous pouvez simplement recharger toutes ces données depuis le magasin de persistance.
Évidemment, dans les deux cas, vous devez garder à l’esprit que chaque fois que vous chargez des données à partir du magasin de persistance, vous aviez trois serveurs, maintenant vous en avez deux. Eh bien, les données peuvent avoir une valeur trop volumineuse pour tenir sur les deux serveurs. Un autre problème auquel vous devez faire face est de vous assurer que vous disposez de suffisamment de mémoire sur ces deux serveurs restants pour qu'ils puissent accueillir l'équivalent des trois. les serveurs. C'est donc la seule limitation. Sinon, la persistance ajoute vraiment de la valeur au cache partitionné et au cache de réplique de partition.
Cache Client
D'accord, une autre fonctionnalité très importante de NCache est appelé Cache Client. Il vous offre une vitesse InProc dans un environnement de magasin distribué. Ainsi, par exemple, vous avez un système distribué NCache cluster, votre application s'exécute ici, il s'agit généralement d'un cache au-dessus de votre base de données ou quoi que vous fassiez, un cache client est généralement utilisé lorsque vous avez un scénario de cache distribué, et un cache client est un cache au-dessus de ce cluster de cache, et il se trouve très proche de votre application. Il se trouve sur le serveur d'applications ou sur le NCache boîte client. Et cela peut même être InProc ou OutProc selon vos préférences. Un cache InProc est ultra-rapide car il conserve les données sous forme d'objet désérialisé sur votre tas. C'est donc comme si vous aviez cet objet sur votre tas. Cela peut aller plus vite que cela.
Ainsi, un cache InProc est ultra-rapide mais en même temps la beauté est qu'il est synchronisé avec le NCache grappe. Et la façon dont il est synchronisé dépend de ce qui est conservé dans le cache client et dont le cluster en a connaissance. Ainsi, si quelque chose qui a été conservé dans ce cache client, un autre client est mis à jour dans le cluster, le cluster informe ce cache client d'aller se mettre à jour. Et puis ce cache client se met à jour de manière asynchrone. Évidemment, il y a un délai de quelques millisecondes, mais c'est, vous savez, comme je l'ai dit, la cohérence finale est le modèle dans la plupart des cas, et c'est généralement acceptable dans 99 % des cas.
Si ce n'est pas acceptable, alors NCache vous fournit… et la synchronisation optimiste est la synchronisation par défaut, c'est-à-dire qu'il y a un retard de quelques millisecondes et il pourrait techniquement y avoir une situation où vous avez des données obsolètes, ce qui est correct comme je l'ai dit 99 % du temps. Mais, disons, si cela ne va pas et que vos données sont très sensibles mais que vous souhaitez quand même utiliser le cache client, vous pouvez utiliser une fonctionnalité de synchronisation pessimiste qui garantit qu'avant que votre application récupère quoi que ce soit du cache client, le client Le cache vérifie uniquement s'il existe une version plus récente de ces données, c'est un appel plus rapide que d'obtenir les données elles-mêmes car, NCache conserve ensuite plusieurs informations de version. Et puis, s'il existe une version plus récente de ces données, le cache client la récupère, sinon il la restitue simplement à partir du cache client.
Un cache client que vous pouvez utiliser sans aucune modification de code. Il se connecte simplement à votre environnement et convient parfaitement aux situations de lecture intensive. Là où vous faites beaucoup plus de lectures, au moins 5:1, 10:1 est idéal, mais quand il y a 1:1, disons, dans le cas de sessions Web, le cache client n'aide en fait pas du tout. En fait, ce n’est pas du tout recommandé.
Réplication WAN
Multi-Zone / Multi-Région
Ok, une autre partie de NCache est l'endroit où NCache Réplication WAN pour gérer le déploiement multi-zones ou multi-régions de vos applications. Ainsi, par exemple, vous pouvez déployer votre application sur deux sites différents pour la reprise après sinistre, pour la reprise après sinistre, l'un est actif et l'autre est passif. Et vous avez cette application, un NCache en cours d'exécution avec, et vous avez ici une application qui ne fonctionne pas. Mais vous voulez vous assurer que si ce site devait tomber en panne, il serait immédiatement en mesure de reprendre la charge. Donc, vous pouvez mettre un pont. Un pont est lui-même un cluster à 2 nœuds qui peut être sur les mêmes boîtiers que le NCache principal, ou il peut s'agir d'un site dédié distinct, c'est à vous de décider. Ensuite, tout ce que vous mettez à jour dans ce cache est répliqué de manière asynchrone sur le WAN vers l'autre cache. Donc, c'est l'actif-passif.
Vous pouvez faire la même chose avec un actif-actif. Disons que si vous avez une situation où même ce site est actif, vous pouvez faire exactement la même chose avec un actif-actif où les deux sites peuvent se mettre à jour. Dans ce cas, il existe également une situation dans laquelle un conflit peut se résoudre ou surgir. Et ce qu'un conflit signifie, c'est que le même élément, la même clé est mis à jour simultanément sur les deux sites. Si cela se produit, le pont applique par défaut la logique « la dernière mise à jour gagne ». Ainsi, quelle que soit celle qui a l'horodatage le plus récent, cette mise à jour l'emporte. Mais, par exemple, si vous le souhaitez, vous pouvez également fournir un gestionnaire de résolution de conflits et de résolution de conflits qui est votre code .NET ou Java que le pont appellera, et il transmettra les deux copies des données ou de l'objet à ce gestionnaire de résolution. et ensuite vous pouvez analyser le contenu pour déterminer lequel est le plus correct, puis vous dites, d'accord, cette mise à jour gagne, puis cette mise à jour est appliquée aux deux sites. Tant que cela s’applique aux deux parties, il n’y a pas de conflit.
La NCache a la capacité de vous offrir trois sites ou plus en mode actif-actif ou actif-passif, ou une combinaison de ceux-ci. Ainsi, par exemple, vous avez besoin d'au moins un actif, mais ceux-ci pourraient alors tous être passifs ou tous pourraient être actifs ou encore il pourrait s'agir d'une combinaison d'actifs ou de passifs. Et, encore une fois, de la même manière, lorsqu'il y en a plus d'un actif, cela pourrait être une résolution de conflit.
Conteneurs (Docker et Kubernetes)
Enfin, les conteneurs Docker et Kubernetes sont devenus très populaires. Donc, NCache les prend évidemment en charge car ils sont encore plus populaires du côté Java et Linux que du côté .NET et Windows, mais je suis sûr que cela va changer, vous savez, avec le temps. Donc, de toute façon, NCache est tout à fait capable de le gérer dans les deux environnements. Ainsi, par exemple, voici un exemple typique Déploiement Kubernetes de NCache.
Voici un NCache déploiement. Il y a NCache a son propre service de découverte. Ce sont des pods qui peuvent évoluer et vous avez ensuite des applications au sein du cluster Kubernetes qui sont NCache clients et il peut s'agir d'Azure, AKS, AWS, EKS, Google GKE ou Red Hat OpenShift. Red Hat OpenShift est généralement soit un autre cloud comme AWS, Azure ou Google, soit peut-être un autre cloud, mais NCache les soutient tous. Et ce pod pourrait être Linux, ce qui est le cas le plus courant dans Kubernetes, et NCache fonctionne parfaitement bien. Et l’application peut également être Linux ou Windows. Il peut donc s'agir de Linux ou de Windows, de Linux ou de Windows.
Docker / Kubernetes (Multi-Zone)
De la même manière que la réplication WAN entre en jeu, si vous le souhaitez, disons, à cause du cloud, vous pouvez avoir plusieurs zones de disponibilité. Vous vouliez créer un Kubernetes multizone.
Nous vous recommandons donc de créer un cluster Kubernetes, d'en avoir deux NCache déploiements, ceux-ci peuvent être actifs-actifs ou actifs-passifs. Et puis le pont peut être soit complètement assis ici, soit complètement ici. Ou vous pouvez même diviser le pont où une partie se trouve sur cette zone et une partie sur cette zone, puis la réplication se produit de manière asynchrone.
Je pense que cela couvre à peu près le sujet d’aujourd’hui. Je vous recommande fortement de venir sur notre site Web et d'y jeter un œil NCache cour de récréation qui est vraiment un moyen très rapide et simple depuis votre navigateur d'utiliser une copie en cours d'exécution de NCache, et vous pouvez même obtenir un 2-Node NCache Cluster avec tous les outils sans aucun effort d’installation. Ou si tu es prêt, viens ici et inscrivez-vous et téléchargez non plus NCache Enterprise pour l'édition .NET ou NCache Enterprise pour l'édition Java. Comme je l'ai dit, vous pouvez obtenir soit le .tar.gz pour Linux, soit le .msi, ou vous pouvez également obtenir le Docker. Vous pouvez simplement extraire une image Docker de NCache. C'est la fin de ma présentation. Merci beaucoup.