NCache Architecture

Cluster peer-to-peer (auto-guérison)

NCache Le cluster possède une architecture pair à pair. Cela signifie qu'il n'y a pas de nœud maître/esclave et que chaque serveur est un pair. Cependant, le coordinateur du cluster est le nœud le plus ancien du cluster. En cas de panne, le nœud suivant devient automatiquement le coordinateur.

Ce coordinateur de cluster gère toutes les opérations du cluster et les autres informations de configuration du cache. Il gère également l'intégrité du cluster et supprime de force les serveurs de cache partiellement connectés aux autres serveurs du cluster.

Clustering Dynamique

Le noyau de NCache La haute disponibilité repose sur le clustering dynamique, qui permet l'ajout ou la suppression de serveurs sans interruption de service en propageant les modifications d'appartenance via TCP en temps réel. Comme indiqué précédemment, NCache possède de architecture de clustering dynamique. Ceci permet NCache être toujours opérationnel même lorsque de tels changements sont apportés.

Le clustering dynamique vous permet d'effectuer les opérations suivantes :

• - Ajouter/supprimer des serveurs de cache lors de l'exécution sans arrêter le cache ou votre application.
• - Appartenance au cluster est mis à jour au moment de l'exécution et propagé à tous les serveurs du cluster et à tous les clients connectés au cluster.

Gestion des clusters cérébraux divisés

NCache résout les problèmes de split-brain grâce à un algorithme de détection intelligent qui réconcilie automatiquement les sous-clusters divergents afin de restaurer l'intégrité des données sans intervention manuelle. Une autre partie de NCache Le clustering dynamique est son Détection et récupération intelligentes du cerveau divisé Capacité. Le split brain se produit lorsque, en raison de problèmes réseau, la connexion entre les serveurs de cache est interrompue. Cela entraîne la formation de plusieurs sous-clusters indépendants, chacun supposant que les autres sont hors service et qu'il est le seul cluster restant.

Dans de tels cas, lorsque les serveurs de cache quittent brusquement le cluster, les serveurs restants NCache Les serveurs continuent de tenter de se reconnecter. Cependant, pendant ce temps, chaque sous-cluster met à jour les données indépendamment, créant ainsi plusieurs versions non synchronisées des données.

Une fois le problème de réseau résolu, NCache Déclenche automatiquement le Split Brain. Ce processus est automatique : les serveurs de cache conservent leurs données (gagnants) et ceux qui doivent les abandonner (perdants) sont déterminés. Cette opération est nécessaire car les serveurs du cluster perdant doivent rejoindre le cluster gagnant en tant que nouveaux nœuds. Il y a une perte de données, mais le résultat final est une restauration rapide du cluster de cache sans intervention humaine.

Connexions client dynamiques

NCache vous permet également ajouter ou supprimer Les clients sont exécutés sans interrompre le cache ni aucun autre client. Lorsqu'un client est ajouté, il n'a besoin que d'un seul serveur de cache du cluster pour établir une connexion. Une fois connecté à ce serveur, il reçoit les informations nécessaires sur l'appartenance au cluster et la topologie de mise en cache. Il décide ensuite à quels autres serveurs se connecter.

• - Cache partitionné/réplique de partitionLe client se connecte à toutes les partitions du serveur de cache (mais pas aux réplicas, car ces derniers communiquent uniquement avec leurs partitions). Cela lui permet de cibler la partition appropriée pour les opérations de lecture et d'écriture. De plus, si un nouveau serveur est ajouté au cluster, le client reçoit les informations d'appartenance mises à jour et se connecte également à ce nouveau serveur.
• - Cache répliqué:En cas de Cache répliquéLe client se connecte à un seul serveur de cache du cluster, mais avec un équilibrage de charge pour garantir que tous les serveurs de cache ont le même nombre de clients. Ainsi, toutes les lectures et écritures sont possibles sur un seul serveur de cache. Lorsqu'un nouveau serveur est ajouté au cluster, le client obtient ces informations du serveur de cache et se reconnecte à un nouveau serveur, si nécessaire.
• - Cache en miroir:En cas de Cache en miroirLe client se connecte simplement au seul nœud actif du cluster à deux nœuds. Si le client se connecte au nœud passif, celui-ci l'informe de l'existence du nœud actif, et le client se reconnecte automatiquement au nœud actif. Si le nœud actif tombe en panne et que le nœud passif redevient actif, tous les clients se connectent automatiquement au nouveau nœud actif.

Configuration dynamique

Comme mentionné dans les sections Connexions client dynamiques et Clustering dynamique, NCache Fournit une configuration dynamique du cache et des clients. Cette section vous explique le fonctionnement de cette configuration d'exécution.

• - Configuration du cacheLorsqu'un cache est créé via les outils d'administration, ces informations de configuration sont copiées sur tous les serveurs de cache connus à ce moment. De même, tout nouveau serveur ajouté au cluster lors de l'exécution reçoit l'intégralité de la configuration de cache mise à jour et la copie sur son disque local.
• - Modifications de configuration appliquées à chaud: Vous pouvez modifier certaines configurations du cache à l'exécution grâce à l'application à chaud. Par exemple, lors de la modification de Taille du cache ou activer CompressionDans ce cas, les informations de configuration mises à jour sont propagées à tous les serveurs de cache lors de l'exécution et enregistrées sur leurs disques. Une partie de ces informations est également envoyée à tous les clients, si nécessaire.
• - Carte de distribution (cache partitionné/réplique de partition)Créé au démarrage d'un cache, il est ensuite copié sur tous les serveurs et clients de cache. Cette carte de distribution contient des informations sur les compartiments (sur un total de 1 000 compartiments du cache clusterisé) situés dans chaque partition.

Basculement de connexion au sein du cluster

Tous les serveurs de cache du cluster sont connectés via TCP. De plus, chaque serveur de cache est connecté à tous les autres serveurs de cache du cluster, y compris à tout nouveau serveur ajouté lors de l'exécution. NCache fournit différentes manières de garantir que toutes les connexions au sein du cluster sont maintenu en vie Malgré un échec de connexion, ces échecs surviennent généralement en raison d'un problème réseau dû aux routeurs, aux pare-feu ou à un problème de carte ou de pilote réseau.

• - Nouvelles tentatives de connexion:Si la connexion entre deux serveurs de cache est rompue, NCache tente automatiquement plusieurs tentatives pour rétablir cette connexion. Ces tentatives se produire pendant la durée du délai d'expiration spécifié par l'utilisateur.
• - Battement de coeur Keep-Alive: NCache Il dispose également d'une fonctionnalité permettant à chaque serveur de cache d'envoyer régulièrement de petits paquets de données en guise de pulsation à tous les autres serveurs. Ainsi, en cas de problème de socket réseau, les serveurs de cache le détecteront et le corrigeront par de nouvelles tentatives.
• - Serveurs partiellement connectés:Dans certains cas, des problèmes de réseau peuvent diviser le cluster en sous-clusters (un "Cerveau divisé"). NCache détecte et résout automatiquement ce problème une fois le réseau restauré en décidant quel cluster conserve ses données et en demandant aux autres de le rejoindre.

Basculement de connexion avec les clients

Le basculement de connexion dans les clients est similaire aux nouvelles tentatives de basculement de cluster, aux pulsations et à la reconnexion automatique aux serveurs sains.

• - Nouvelles tentatives de connexionEn termes de basculement, les tentatives de connexion sont les mêmes au niveau du cluster et du client. Cependant, si une connexion entre un client et les serveurs de cache est interrompue, NCache le client fait automatiquement plusieurs tentatives de connexion Pour établir cette connexion. Ces tentatives se produisent pendant la durée du délai d'expiration. Si la connexion ne peut être établie, une exception est levée pour que l'application cliente puisse la gérer.
• - Battement de coeur Keep-Alive:Identique à celui du basculement de connexion au sein du cluster.
• - Clients partiellement connectés (cache partitionné/réplique de partition)Parfois, malgré plusieurs tentatives, la connexion n'est pas rétablie à temps, ce qui fait que le client suppose que les autres serveurs sont inaccessibles, même si ce n'est pas le cas. Ainsi, dans le cas d'un cache partitionné/réplique de partition, il interagit avec d'autres serveurs pour lire ou écrire toutes les données, même si sa table de distribution lui indique que le serveur avec lequel il ne peut communiquer possède les données. Dans ce cas, l'autre serveur de cache sert d'intermédiaire pour assurer le bon fonctionnement du système.

Topologies de mise en cache (évolutivité linéaire)

NCache Offre une variété de topologies de mise en cache pour une évolutivité linéaire tout en préservant la cohérence et la fiabilité des données. L'objectif est de prendre en charge des applications allant des petits caches de deux serveurs aux grands clusters comptant des centaines de serveurs. Une topologie de mise en cache est essentiellement une stratégie de stockage, de réplication et de connexions client dans un cache en cluster couvrant plusieurs serveurs.

Données de référence vs données transactionnelles

Les données de référence ne changent pas très fréquemment ; vous les mettez en cache pour répondre aux requêtes fréquentes et éviter les déplacements coûteux vers la base de données, tout en ne les mettant à jour qu'occasionnellement. Les données transactionnelles, en revanche, sont des données qui changent très fréquemment et que vous pouvez mettre à jour aussi souvent que vous les consultez.

Au début, les caches étaient principalement utilisés pour les données de référence, car les données fréquemment modifiées devenaient obsolètes et désynchronisées avec les données les plus récentes de la base de données. Cependant, NCache fournit maintenant des fonctionnalités très puissantes qui permettent au cache de garder ses données en cache synchronisées avec la base de données.

Tous NCacheLes topologies de mise en cache sont efficaces pour les données de référence, mais certaines sont particulièrement avantageuses pour les données transactionnelles. Il est donc nécessaire de déterminer le nombre de lectures et d'écritures à effectuer pour déterminer la topologie la plus adaptée. De plus, certaines topologies de mise en cache sont moins évolutives, notamment pour les mises à jour ; gardez cela à l'esprit.

Vous trouverez ci-dessous une liste des topologies de mise en cache ainsi que leur impact sur les lectures par rapport aux écritures.

• - Cache partitionné (pas de réplication):Il s'agit de la topologie la plus rapide, mais elle ne réplique pas les données, il y a donc une perte de données si un serveur de cache tombe en panne.
• - Cache de Partition-Réplica (Le plus populaire)Cette topologie est ultra-rapide en lecture comme en écriture. Elle réplique également les données pour une fiabilité optimale. Elle offre la meilleure combinaison entre vitesse, évolutivité et fiabilité des données.
• - Cache répliquéIdéal pour les environnements de petite taille. Chaque serveur conserve une sauvegarde complète du cache, garantissant une fiabilité élevée des données et une tolérance aux pannes. Il est ultra-rapide et linéairement évolutif en lecture. Moyennement rapide en écriture dans un cluster à deux nœuds, mais ne s'adapte pas à l'ajout de serveurs, car les écritures sont effectuées de manière synchrone sur tous les serveurs de cache.
• - Cache en miroirCette topologie est idéale pour les environnements de petite taille. Elle offre des écritures plus rapides que le cache répliqué pour les configurations actives/passives à deux nœuds. Cependant, elle ne peut pas évoluer au-delà.
• - Cache ClientIdéal pour les cas d'utilisation intensifs en lecture, quelle que soit la topologie de mise en cache. Permet d'atteindre la vitesse InProc avec un cache distribué.

Cache partitionné

Le cache partitionné est la topologie de mise en cache la plus rapide et la plus évolutive, tant en lecture qu'en écriture. Conçu pour les grands clusters, il offre des performances de lecture et d'écriture rapides, même en cas de pics de charge. Cependant, il ne réplique pas les données. Il n'existe donc aucune sauvegarde en cas de panne d'un serveur.

Voici quelques caractéristiques du cache partitionné.

• - Partitions dynamiques: Le cache est divisé en partitions lors de l'exécution, chaque serveur de cache possédant une partition. Chaque cache clusterisé compte 1 000 compartiments répartis uniformément sur toutes les partitions. En résumé, l'ajout ou la suppression d'un serveur de cache entraîne la création ou la suppression de partitions lors de l'exécution. L'affectation des compartiments de partition ne change pas lors de l'ajout de données au cache. Elle ne change que lors de l'ajout ou de la suppression de partitions, ou lors de la modification de données. charge équilibrée. Ce rééquilibrage fait référence au processus de transfert d'état qui déplace les buckets et leurs données vers les partitions cibles
• - Carte de répartitionLe cluster de cache crée une carte de distribution contenant des informations sur les compartiments et les partitions. Cette carte est mise à jour à chaque transfert d'état. Elle est ensuite propagée à tous les serveurs et clients. Les clients l'utilisent pour déterminer à quel serveur de cache communiquer pour toute opération de lecture/écriture.
• - Équilibrage dynamique des donnéesÉtant donné que tous les compartiments sont basés sur HashMap et que les données sont stockées selon un algorithme de hachage appliqué aux clés, certains compartiments peuvent contenir plus de données que d'autres, selon les clés utilisées. Si ce déséquilibre dépasse un seuil configurable, NCache déplace automatiquement les godets pour rééquilibrer cette charge.
• - Les clients se connectent à TOUTES les partitionsLes clients se connectent à tous les serveurs de cache afin de pouvoir lire ou écrire directement des données en une seule requête. Si la connexion d'un client à un serveur de cache est interrompue, il demande à l'un des autres serveurs de lire ou d'écrire un élément en cache existant sur le serveur auquel il n'a pas accès. Ce serveur aide le client à y parvenir.

Cache de Partition-Réplica

REMARQUE : tout ce qui est mentionné dans Cache partitionné est également vrai ici.

Tout comme Cache partitionnéLe cache de réplication de partition est une topologie de mise en cache extrêmement rapide et évolutive linéairement, tant en lecture qu'en écriture. Conçu pour les clusters de cache de grande taille, il offre d'excellentes performances en lecture et en écriture, même en cas de pics de charge. De plus, le cache de réplication de partition réplique également les données. Ainsi, aucune perte de données n'est constatée, même en cas de panne d'un serveur de cache.

Le cache de réplication de partition est notre topologie de mise en cache la plus populaire car il vous offre le meilleur des deux mondes : performances/évolutivité linéaire et fiabilité des données.

Vous trouverez ci-dessous certaines des caractéristiques de Partition-Replica Cache.

• - Partitions dynamiques:Identique au cache partitionné.
• - Répliques dynamiquesLorsque des partitions sont créées ou supprimées à l'exécution, leurs répliques le sont également. Les répliques se trouvent toujours sur un serveur de cache différent, et il n'existe qu'une seule réplique par partition.
• - Réplication asynchronePar défaut, la réplication d'une partition vers son réplica est asynchrone. Les écritures client (ajout, mise à jour, suppression) affectent la partition et sont mises en file d'attente pour une réplication asynchrone en masse vers le réplica. Cela améliore les performances, mais présente un léger risque de perte de données en cas de panne d'une partition et si toutes les mises à jour n'ont pas été répliquées vers le réplica. Cependant, ce cas est extrêmement rare.
• - Synchroniser la réplicationSi vos données sont très sensibles (par exemple, des données financières) et que vous ne pouvez pas vous permettre d'avoir des données obsolètes, vous pouvez choisir l'option Réplication synchronisée dans la configuration. Lorsque cette option est sélectionnée, toutes les opérations d'écriture sont exécutées de manière synchrone sur la partition et le réplica jusqu'à ce qu'elles soient considérées comme terminées. Ainsi, si l'opération échoue sur le réplica, elle échoue également sur la partition. Ainsi, la cohérence de toutes les données du cache (partition et réplica) est garantie. Cependant, cette option a des répercussions sur les performances, car elle est plus lente que la réplication asynchrone.
• - Carte de répartition:Identique au cache partitionné.
• - Équilibrage dynamique des données (partitions et répliques)Identique au cache partitionné. Cependant, dans le cache partition-réplique, l'équilibrage des données se produit également dans les réplicas lorsque les partitions sont équilibrées.
• - Les clients se connectent à TOUTES les partitionsIdentique au cache partitionné. Cependant, dans le cache partition-réplique, les clients communiquent uniquement avec les partitions et non avec leurs réplicas. En effet, les réplicas sont passifs et les partitions ne communiquent avec leurs réplicas que pour y répliquer des données.

Cache répliqué

Le cache répliqué assure la fiabilité des données grâce à la réplication sur deux serveurs de cache ou plus. Il est très rapide et évolutif en lecture. En revanche, il ne l'est pas en écriture, car celles-ci sont synchrones avec tous les serveurs du cluster. Pour un cluster à deux nœuds, les écritures sont plus rapides que celles de votre base de données, mais moins rapides qu'un cache de réplication de partition. Pour les clusters à trois serveurs ou plus, les performances en écriture se dégradent et finissent par devenir coûteuses.

Vous trouverez ci-dessous certaines des caractéristiques du cache répliqué.

• - Nœuds répliqués dynamiquesVous pouvez ajouter ou supprimer des serveurs de cache à un cache existant lors de l'exécution, sans interrompre le cache ni votre application. Le serveur nouvellement ajouté effectue une copie (réplique) de l'intégralité du cache sur lui-même. Le serveur supprimé met à jour l'appartenance au cluster et tous ses clients migrent vers d'autres serveurs.
• - Cache entier sur chaque nœud:L'intégralité du cache est copiée sur chaque serveur du cluster.
• - Les lectures sont évolutivesLes lectures sont ultra-rapides et évolutives lorsque vous ajoutez des serveurs. Cependant, l'ajout de serveurs supplémentaires n'augmente pas la taille du cache, car le nouveau serveur n'est qu'une copie de l'intégralité du cache.
• - Les écritures sont synchronesLes écritures sont très rapides pour un cluster à deux nœuds et plus rapides que votre base de données. Cependant, elles sont synchrones, ce qui signifie que chaque opération d'écriture ne se termine qu'une fois tous les serveurs de cache mis à jour simultanément. Par conséquent, les écritures ne sont pas aussi rapides que dans d'autres topologies.
• - Le client se connecte à un seul serveurChaque client de cache se connecte à un seul serveur du cluster, selon un algorithme d'équilibrage de charge déterminé par les serveurs de cache. En cas de panne de ce serveur, le client se connecte au serveur suivant de la liste. Vous pouvez également spécifier manuellement le serveur auquel se connecter dans le fichier de configuration du cache si vous ne souhaitez pas utiliser l'équilibrage de charge.

Cache en miroir

Le cache miroir est un cluster de cache actif/passif à deux nœuds destiné aux environnements de petite taille. Il assure la fiabilité des données grâce à la réplication/mise en miroir asynchrone du nœud actif vers le nœud passif. Il est très rapide en lecture comme en écriture (d'ailleurs, ses opérations d'écriture sont plus rapides que celles du cache répliqué), mais ne peut pas évoluer au-delà de ce cluster actif/passif à deux nœuds.

Vous trouverez ci-dessous certaines des caractéristiques de Mirrored Cache.

• - 1 serveur actif et 1 serveur passifLe cache miroir ne comporte que deux serveurs : l'un actif et l'autre passif. Ils possèdent tous deux une copie de l'intégralité du cache. Si le serveur actif tombe en panne, le serveur passif redevient automatiquement actif. De plus, si le serveur actif précédemment arrêté est remis en service, il est considéré comme passif, sauf si vous modifiez cette désignation via les outils d'administration lors de l'exécution.
• - Connexions des clients avec prise en charge du basculementChaque client de cache se connecte uniquement au serveur actif du cluster pour ses opérations de lecture et d'écriture. En cas de panne de ce serveur actif, tous les clients se connectent automatiquement au serveur passif désormais actif. Ce basculement garantit que le cache miroir reste opérationnel en permanence, même en cas de panne d'un serveur.
• - Mise en miroir asynchroneToutes les écritures effectuées sur le serveur actif sont mises en miroir/répliquées de manière asynchrone sur le serveur passif. Cela garantit que le serveur passif est toujours synchronisé avec les données les plus récentes en cas de panne du serveur actif nécessitant son activation. La mise en miroir asynchrone améliore également les performances, car les écritures multiples sont effectuées en bloc sur le serveur passif.

Cache client (vitesse InProc)

Le cache client est local sur votre serveur web/d'application et très proche de votre application. Il vous permet de mettre en cache les données lues depuis le cache distribué (quelle que soit la topologie de mise en cache). Bien que local à votre application, un cache client n'est pas autonome. Il est toujours synchronisé avec le cache clusterisé. Cela garantit que les données du cache client ne sont jamais obsolètes.

Considérez cela comme un « cache sur un autre cache », qui améliore encore les performances et l'évolutivité de votre application. En utilisant le cache client en mode InProc, vous pouvez atteindre la vitesse InProc. NCache propose deux variantes de cache client : le cache standard et le cache complet. Chacun est conçu pour optimiser les performances en réduisant les appels réseau tout en restant synchronisé avec le cache cluster.

Cache client régulier

Le cache client standard agit comme un cache local (L1) sur la machine cliente, conservant un sous-ensemble des données fréquemment consultées à proximité de l'application. Cela réduit les allers-retours réseau répétés vers le cache clusterisé (L2). Pour garantir la cohérence, le cache client reste synchronisé avec le cache clusterisé en recevant des notifications de modification. Comme il ne contient pas l'intégralité du jeu de données, toutes les requêtes sont exécutées sur le cache clusterisé (L2).

Cache client de données complètes

Le cache client de données complètes va plus loin en mettant en cache des jeux de données entiers localement sur la machine cliente. Il offre les avantages et options suivants :

• - Met en cache des ensembles de données complets localement: Met en cache toutes les entrées des classes .NET sélectionnées, rendant les ensembles de données complets instantanément disponibles.
• - Vitesse proche du processus: Le cache client de données complètes fournit des opérations de lecture plus rapides et permet aux requêtes SQL de s'exécuter entièrement sur le cache client, puisque l'ensemble de données complet est présent localement.
• - Synchronisation avec le cache en cluster:Il reste entièrement synchronisé avec le cache en cluster pour garantir la cohérence.
• - Application stricte des requêtesCette application garantit que les requêtes ne s'exécutent que lorsque l'ensemble de données complet est disponible localement. Si l'ensemble de données est partiellement chargé, la requête échoue immédiatement sans retour au cache clusterisé.
• - Lectures locales strictesCela force toutes les opérations de lecture à être effectuées exclusivement depuis le cache client. Si une clé est introuvable localement, un message d'erreur « cache miss » est renvoyé au lieu d'être récupérée depuis le cache clusterisé.

Tout en étant local à votre application, un cache client n'est pas autonome. Au lieu de cela, il est toujours synchronisé avec le cache en cluster. Cela garantit que les données du cache client ne sont jamais obsolètes.

Vous trouverez ci-dessous certaines des caractéristiques de Mirrored Cache.

• - Idéal pour les cas de lecture intensiveLe cache client est idéal pour les utilisations intensives en lecture. Cependant, si le nombre d'écritures est égal au nombre de lectures, le cache client est plus lent, car une opération d'écriture implique la mise à jour des données à deux endroits.
• - Vitesse plus rapide qu'un cache local (InProc / OutProc)Un cache client est présent soit dans votre processus applicatif (mode InProc), soit localement sur votre serveur web/d'applications (mode OutProc). Dans les deux cas, il améliore considérablement les performances de votre application par rapport à la simple récupération des données depuis le cache clusterisé. Le mode InProc vous permet de mettre en cache des objets sur le tas de votre application, ce qui vous offre une vitesse d'exécution InProc inégalée par aucun cache distribué.
• - Pas un cache autonomeUn cache client peut être un cache local, mais il ne s'agit pas d'un cache autonome. Il est synchronisé avec le cache cluster. Cela signifie que si un autre client met à jour des données du cache cluster présent dans votre cache client, ce dernier lui demande de se mettre à jour avec la dernière copie de ces données. Cette opération est effectuée de manière asynchrone, mais immédiate.
• - Synchronisation optimiste/pessimiste:Par défaut, le cache client utilise la synchronisation optimiste, ce qui signifie que le NCache Le client suppose que les données du cache client sont les plus récentes. Si le cache client ne contient aucune donnée, il les récupère dans le cache clusterisé, les place dans le cache client et les renvoie à l'application cliente. La synchronisation pessimiste signifie que le client du cache vérifie d'abord si le cache clusterisé contient une version plus récente d'un élément mis en cache. Si c'est le cas, il la récupère, la place dans le cache client et la renvoie à l'application cliente. Sinon, il renvoie le contenu du cache client.
• - Plug-in sans aucun changement de codeL'utilisation du cache client n'implique aucune modification du code de l'application. Une simple modification de configuration est nécessaire.

Que faire ensuite?

• NCache DÉTAILS
• Télécharger NCache
• Comparaison Des Éditions

Questions fréquentes

Comment NCache parvenir à une évolutivité linéaire ?

NCache Il assure une évolutivité linéaire en utilisant une carte de distribution à 1000 compartiments pour répartir les données sur plusieurs nœuds de serveur, permettant ainsi au cluster de gérer des charges transactionnelles accrues à mesure que du nouveau matériel est ajouté en cours d'exécution.

Ce qui rend NCacheLe regroupement de 's est-il « auto-réparateur » ?

NCache utilise une architecture 100 % pair à pair où chaque serveur est un pair ; si un nœud (y compris le coordinateur de cluster) tombe en panne, les nœuds restants élisent automatiquement un nouveau coordinateur et rééquilibrent le cluster via des pulsations basées sur TCP pour maintenir une disponibilité de 100 %.

Quelle est la différence entre les topologies partitionnées et les topologies à répliques de partitions ?

Bien que les deux offrent une évolutivité linéaire, le cache partitionné offre la vitesse la plus élevée sans redondance des données, tandis que le cache à réplicas de partitions est le choix le plus populaire car il équilibre des performances extrêmes avec une haute disponibilité en créant des répliques passives de chaque partition.

Comment NCache Résoudre les scénarios de « double cerveau » ?

NCache résout les problèmes de split-brain grâce à un algorithme intelligent de détection et de récupération qui réconcilie automatiquement les sous-clusters divergents et restaure l'intégrité des données sans nécessiter d'intervention manuelle.

Pourquoi devrais-je utiliser un NCache Cache client (L1) ?

An NCache Le cache client (L1) offre une vitesse InProc inférieure à la milliseconde en stockant un sous-ensemble de données fréquemment consulté directement sur le serveur d'application, ce qui réduit considérablement la latence réseau vers le cache en cluster (L2).

Puis-je ajouter ou supprimer des serveurs en cours d'exécution sans interruption de service ?

Oui, NCache prend en charge le clustering dynamique, qui permet l'ajout ou la suppression de serveurs sans interruption de service en mettant à jour et en propageant automatiquement la carte de distribution du cluster à tous les clients en temps réel.