NCache Architecture

Cluster peer to peer (auto-guérison)

NCache Le cluster a une architecture de cluster peer-to-peer. Cela signifie qu'il n'y a pas de nœuds maître/esclave et que chaque serveur est un homologue. Il existe un nœud Coordinateur de cluster qui est le nœud le plus ancien du cluster. Si le nœud du coordinateur de cluster tombe en panne, le prochain plus ancien devient automatiquement le coordinateur.

Le coordinateur de cluster gère toutes les opérations liées au cluster, y compris l'adhésion au cluster lorsque des nœuds sont ajoutés ou supprimés, la carte de distribution pour Cache partitionné / Cache de Partition-Réplica topologie et autres informations de configuration du cache. Le coordinateur de cluster gère également l'intégrité du cluster et supprime de force tous les serveurs de cache qui sont partiellement connectés à tous les autres serveurs du cluster.

Clustering Dynamique

NCache possède de architecture de clustering dynamique. Cela signifie que vous pouvez ajouter or supprimez n'importe quel serveur de cache du cluster sans arrêter le cache ou les applications. Chaque fois que vous ajoutez ou supprimez un serveur de cache, l'appartenance au cluster est mise à jour immédiatement au moment de l'exécution et propagée à tous les serveurs du cluster ainsi qu'à tous les clients connectés au cluster. Cette mise à jour et cette propagation du runtime permettent 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 au moment de l'exécution: sans arrêter le cache ni 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

Une autre partie de NCache Le clustering dynamique est son système intelligent Détection et récupération du cerveau divisé aptitude. Le cerveau divisé se produit essentiellement lorsqu'en raison de problèmes de réseau, la connexion réseau est interrompue entre ces serveurs de cache, ce qui entraîne la création de plusieurs sous-clusters indépendants où chaque sous-cluster suppose que tous les autres serveurs de cache sont tombés en panne et qu'il s'agit du cluster restant correct. .

Dans ces cas, NCache Les serveurs se rendent compte que les autres serveurs de cache ont quitté le cluster brusquement et continuent d'essayer de se reconnecter avec eux. Ensuite, lorsque le problème de réseau disparaît, ces NCache les serveurs peuvent se reconnecter aux autres serveurs de cache. Mais désormais, chaque sous-cluster a mis à jour le cache en parallèle sans se synchroniser avec les autres serveurs de cache et il existe donc plusieurs versions des données dans les sous-clusters.

NCache fournit un moyen de se remettre de ce « cerveau divisé » en décidant automatiquement quels serveurs de cache doivent abandonner leurs données et quels autres serveurs de cache doivent conserver leurs données. Il y a une certaine perte de données mais le résultat final est une restauration rapide du cluster de cache sans aucune intervention humaine.

Connexions client dynamiques

NCache vous permet également ajouter ou supprimer des clients de cache au moment de l'exécution sans arrêter le cache ou les autres clients. Lorsque vous ajoutez un client, ce client a simplement besoin de connaître n'importe quel serveur de cache du cluster auquel se connecter. Une fois connecté à ce serveur, il reçoit des informations sur l'appartenance au cluster et la topologie de mise en cache en fonction desquelles il décide à quels autres serveurs se connecter.

• - Ajouter/supprimer des clients au moment de l'exécution: sans arrêter le cache ou votre application.
• - Cache partitionné/Cache de réplique de partition: le client se connecte à toutes les partitions de tous les serveurs de cache (pas aux répliques car les partitions communiquent avec leurs répliques). Cela permet au client d'aller directement là où se trouvent les données pour les lectures et les écritures. Et, si un nouveau serveur est ajouté au cluster, le client reçoit des informations d'appartenance au cluster mises à jour, puis se connecte également à ce serveur de cache nouvellement ajouté.
• - Cache répliqué: en cas de Cache répliqué, le client se connecte simplement à un serveur de cache dans le cluster, mais en équilibrant la charge pour garantir que tous les serveurs de cache ont le même nombre de clients. Le client obtient les informations d'équilibrage de charge de ce serveur cache et sur cette base, si nécessaire, il se reconnecte au serveur cache approprié. Le client se connecte à un seul serveur de cache car chaque serveur dispose de l'intégralité du cache, de sorte que toutes les lectures et écritures sont possibles sur place.
• - Cache en miroir: en cas de Cache en miroir, le client se connecte uniquement au nœud actif de ce cluster à 2 nœuds. Si le client se connecte au nœud passif, le nœud passif informe le client 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 devient actif, tous les clients se connectent automatiquement au nouveau nœud actif.

Configuration dynamique

NCache fournit également une configuration dynamique du cache et des clients. Le but est de vous permettre d'apporter des modifications ultérieurement lorsque le cache est en cours d'exécution sans arrêter le cache ou votre application.

• - Propager à tous les serveurs et clients au moment de l'exécution: cela inclut toute la configuration et ses modifications ainsi que la carte de distribution.
• - Configuration du cache: lorsqu'une configuration de cache est créée via les outils d'administration, ces informations de configuration sont copiées sur tous les serveurs de cache connus à ce moment-là. Et tout nouveau serveur ajouté au moment de l'exécution reçoit l'intégralité de cette configuration de cache et la copie sur son disque local.
• - Modifications de configuration appliquées à chaud : vous pouvez modifier une partie de la configuration du cache au moment de l'exécution via un "Application à chaud" caractéristique de NCache. Lorsque vous faites cela, 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 transmise à tous les clients en fonction de leurs besoins.
• - Carte de distribution (cache partitionné/réplique de partition): ceci est créé au démarrage du cache et est ensuite copié sur tous les serveurs de cache et clients de cache. Cette carte de distribution contient des informations sur les compartiments (sur un total de 1000 XNUMX compartiments dans le cache en cluster) qui se trouvent sur quelle partition.

Basculement de connexion au sein du cluster

Tous les serveurs de cache du cluster sont connectés les uns aux autres via TCP. De plus, chaque serveur de cache est connecté à tous les autres serveurs de cache du cluster, y compris tous les nouveaux serveurs ajoutés au moment de l'exécution. NCache fournit différentes manières de s'assurer que toutes les connexions au sein du cluster sont maintenues actives malgré l'interruption de la connexion. Une rupture de connexion se produit généralement en raison d'un problème de réseau dû à un routeur ou à un pare-feu ou à un problème avec la carte réseau ou le pilote réseau.

• - Nouvelles tentatives de connexion: si la connexion entre deux serveurs de cache est interrompue, NCache Le serveur effectue automatiquement plusieurs tentatives pour établir cette connexion. Ces tentatives sont effectuées jusqu'à ce que la période de "timeout" soit épuisée. Dans la plupart des situations, cela rétablit la connexion.
• - Battement de coeur Keep-Alive: NCache a également une fonctionnalité pour que chaque serveur de cache continue d'envoyer de petits paquets de données sous forme de battement de cœur à tous les autres serveurs. Cela garantit qu'en cas de problème de rupture de socket réseau, les serveurs de cache le sauront et le résoudront par de nouvelles tentatives.
• - Serveurs partiellement connectés: malgré les tentatives, il arrive parfois qu'une connexion ne soit pas restaurée dans le délai d'expiration et qu'un serveur de cache suppose qu'un ou plusieurs autres serveurs de cache sont en panne. Ainsi, il continue de fonctionner sans eux. Mais en réalité, les autres serveurs ne sont pas en panne et sont en fait vus par certains autres serveurs du cluster. C'est ce qu'on appelle des serveurs partiellement connectés. Lorsque cela se produit, le coordinateur du cluster en prend note et supprime de force le serveur « Partiellement connecté » du cluster. Ce faisant, le cluster redevient sain. Et le serveur supprimé peut rejoindre le cluster via une intervention manuelle.

Basculement de connexion avec les clients

Tous les clients de cache sont connectés à un ou plusieurs serveurs de cache du cluster via TCP en fonction des topologies de mise en cache. Pour le cache partitionné/partition-réplica, chaque client est connecté à tous les serveurs de cache. Pour le cache répliqué, chaque client est connecté à un seul des serveurs de cache, généralement via un algorithme d'équilibrage de charge utilisé par les serveurs de cache. Et, pour Mirrored Cache, tous les clients sont connectés uniquement au nœud actif et ne se connectent au nœud passif que lorsque le nœud actif tombe en panne et que le nœud passif devient un nœud actif.

• - Nouvelles tentatives de connexion: 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 sont effectuées jusqu'à ce que la période de "timeout" soit épuisée. Dans la plupart des situations, cela rétablit la connexion sans même que l'application cliente s'en aperçoive. Si une connexion ne peut pas être établie, une exception est levée vers l'application cliente afin qu'elle puisse la gérer.
• - Battement de coeur Keep-Alive: NCache a également une fonction pour que chaque client continue d'envoyer de petits paquets de données au fur et à mesure battement de coeur à tous les serveurs de cache auxquels il est connecté. Cela garantit que s'il y a un problème de rupture de socket réseau, le client le saura et le résoudra par de nouvelles tentatives de connexion.
• - Clients partiellement connectés (cache partitionné/réplique de partition): malgré les tentatives, il arrive parfois qu'une connexion ne soit pas restaurée dans le délai imparti et un client de cache suppose qu'il ne peut pas atteindre un ou plusieurs autres serveurs de cache même s'ils ne sont pas en panne. 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 carte de distribution lui indique que le serveur avec lequel il ne peut pas communiquer possède les données. Dans ce cas, l’autre serveur de cache fait office d’intermédiaire pour réussir l’opération.
• - Déconnexion avec le serveur (cache répliqué/miroir): en cas de Cache Répliqué, le client n'est connecté qu'à un seul serveur et si cette connexion est interrompue, le client se connecte automatiquement à l'un des autres serveurs de cache. Dans le cas du cache miroir, si le client ne parvient pas à se connecter au nœud actif, il suppose qu'il est en panne et essaie de se connecter au nœud passif.

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

NCache fournit une variété de topologies de mise en cache pour permettre une évolutivité linéaire tout en maintenant la cohérence et la fiabilité des données. L'objectif est de répondre aux besoins des applications fonctionnant avec de très petits caches à deux serveurs vers de très grands clusters de cache composés de dizaines, voire de centaines de serveurs de cache. Une topologie de mise en cache est essentiellement une stratégie de stockage de données, de réplication de données et de connexions client dans un cache en cluster couvrant plusieurs serveurs de cache.

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

Les données de référence sont des données qui ne changent pas très fréquemment et vous les mettez en cache pour les consulter encore et encore et les mettre à jour occasionnellement. Les données transactionnelles, en revanche, sont des données qui changent très fréquemment et vous pouvez les mettre à jour aussi souvent que vous les lisez.

Au début, un cache était considéré comme utile principalement 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 dernières données 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.

Toutes les topologies de mise en cache conviennent aux données de référence, mais seules certaines topologies de mise en cache sont particulièrement adaptées aux données transactionnelles. Vous devez déterminer le nombre de lectures et d'écritures que vous effectuerez pour déterminer quelle topologie vous convient le mieux. De plus, certaines topologies de mise en cache ne s'adaptent pas autant, en particulier pour les mises à jour, alors gardez cela également à 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): très bon. Super rapide pour les lectures et les écritures et évolue également de manière linéaire en ajoutant des serveurs. Topologie la plus rapide mais 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): très bon. Ultra-rapide pour les lectures et les écritures et évolue également de manière linéaire en ajoutant des serveurs. Deuxième topologie la plus rapide, mais réplique les données pour plus de fiabilité sans compromettre l'évolutivité linéaire. La meilleure combinaison de vitesse/évolutivité et de fiabilité des données.
• - Cache répliqué: Très bien pour les petits environnements. Ultra-rapide et évolutif linéairement pour les lectures. Modérément rapide pour les écritures dans un cluster à 2 nœuds, mais n'évolue pas à mesure que vous ajoutez des serveurs, car les écritures sont effectuées de manière synchrone sur tous les serveurs de cache.
• - Cache en miroir: Très bien pour les petits environnements. Ultra-rapide pour les lectures. Les écritures sont plus rapides que le cache répliqué pour 2 nœuds actifs/passifs. Mais cela ne va pas au-delà de cela.
• - Cache Client: Très bien pour une utilisation intensive en lecture avec toutes les topologies de mise en cache. Vous 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 pour les lectures et les écritures. Il est destiné aux clusters de cache plus importants et les performances de lecture et d'écriture restent très bonnes même en cas de pics de charge. Cependant, il ne réplique pas les données et il y a donc une perte de données si un serveur de cache tombe en panne.

Voici quelques caractéristiques du cache partitionné.

• - Partitions dynamiques: le cache est divisé en partitions au moment de l'exécution, chaque serveur de cache ayant une partition. Il existe un total de 1000 XNUMX compartiments par cache en cluster, répartis uniformément sur toutes les partitions. L'ajout/la suppression d'un serveur de cache entraîne la création/suppression de partitions au moment de l'exécution. L'affectation des compartiments aux partitions ne change pas lorsque les données sont ajoutées au cache. Au lieu de cela, cela ne change que lorsque des partitions sont ajoutées ou supprimées ou lorsque l'équilibrage des données se produit (voir ci-dessous).
• - Carte de répartition: le cluster de cache crée une carte de distribution qui contient des informations sur les compartiments qui existent dans quelles partitions. La carte de distribution est mise à jour chaque fois que des partitions sont ajoutées ou supprimées ou lorsque l'équilibrage des données se produit (voir ci-dessous). La carte de distribution est propagée à tous les serveurs et clients. Les clients l'utilisent pour déterminer à quel serveur de cache communiquer pour lire ou écrire un certain élément mis en cache.
• - Équilibrage dynamique des données: étant donné que tous les compartiments sont en fait des compartiments HashMap où les données sont stockées sur la base d'un algorithme de hachage sur les clés, il est possible que certains compartiments contiennent plus de données que d'autres en fonction des clés utilisées. Si ce déséquilibre franchissait un seuil paramétrable, NCache déplace automatiquement les godets pour équilibrer cette charge.
• - Les clients se connectent à TOUTES les partitions: les clients se connectent à tous les serveurs de cache afin de pouvoir lire ou écrire directement des données en une seule requête depuis le serveur. Si la connexion d'un client avec un serveur de cache tombe en panne, il demande alors à l'un des autres serveurs de lire ou d'écrire un élément en cache existant sur le serveur auquel il ne peut pas accéder. Et ce serveur aide le client à y parvenir.

Cache de Partition-Réplica

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

Tout comme Cache partitionné, Partition-Replica Cache est une topologie de mise en cache extrêmement rapide et linéairement évolutive pour les lectures et les écritures. Il est destiné aux clusters de cache plus importants et les performances de lecture et d'écriture restent très bonnes même en cas de pics de charge. En plus de cela, Partition-Replica Cache réplique également les données et il n'y a donc aucune perte de données même si un serveur de cache tombe en panne.

Partition-Replica Cache 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 dynamiques: lorsque des partitions sont créées ou supprimées au moment de l'exécution, leurs répliques sont également créées ou supprimées. Les répliques se trouvent toujours sur un serveur de cache différent et il n'existe qu'une seule réplique pour une partition.
• - Réplication asynchrone: par défaut, la réplication de la partition vers la réplique est asynchrone. Cela signifie que le client peut ajouter, mettre à jour ou supprimer n'importe quelle donnée dans la partition et que toutes ces opérations sont mises en file d'attente. Et puis ils sont répliqués en VRAC sur la réplique. Cela améliore les performances mais présente un léger risque de perte de données au cas où une partition disparaîtrait et que toutes les mises à jour n'auraient pas été répliquées sur la réplique. Mais dans la plupart des situations, cela convient parfaitement.
• - Synchroniser la réplication: si vos données sont très sensibles (par exemple des données financières) et que vous ne pouvez jamais vous permettre d'avoir des données obsolètes, vous pouvez alors choisir l'option « Sync Replication » dans la configuration. Lorsque cette option est sélectionnée, toutes les opérations d'écriture sont effectuées de manière synchrone sur la partition et le réplica jusqu'à ce qu'elles soient considérées comme terminées. De cette façon, si l'opération échoue sur la réplique, elle échoue également sur la partition. Et vous pouvez être assuré que toutes les données du cache (dans la partition et dans la réplique) sont toujours cohérentes. Cependant, cela a des implications en termes de performances car il est plus lent 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 de partition-réplique, l'équilibrage des données se produit également dans les répliques lorsque les partitions sont équilibrées.
• - Les clients se connectent à TOUTES les partitions: identique au cache partitionné. De plus, dans Partition-Replica Cache, les clients communiquent uniquement avec les partitions et non avec leurs répliques. En effet, les réplicas sont passifs et seules les partitions communiquent avec leurs réplicas lors de la réplication 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 pour les lectures. Mais il ne s'adapte pas aux écritures car elles sont synchrones avec tous les serveurs du cluster. Pour un cluster à 2 nœuds, les écritures sont plus rapides que votre base de données mais pas aussi rapides que le cache de réplication de partition. Pour 3 clusters de serveurs ou plus, les performances d'écriture se dégradent et finissent par devenir peu attrayantes.

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

• - Nœuds répliqués dynamiques: vous pouvez ajouter ou supprimer des serveurs de cache au moment de l'exécution dans un cache existant sans arrêter le cache ou votre application. Le serveur nouvellement ajouté effectue une copie (réplique) de l'intégralité du cache sur lui-même. De plus, le serveur supprimé met à jour l'adhésion au cluster et tous ses clients sont déplacés 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 évolutives: les lectures sont ultra rapides et évolutives lorsque vous ajoutez plus de serveurs. Cependant, l'ajout de serveurs supplémentaires n'augmente pas la taille du cache, car le serveur nouvellement ajouté n'est qu'une autre copie de l'intégralité du cache.
• - Les écritures sont synchrones: les écritures sont très rapides pour un cluster à 2 nœuds et plus rapides que votre base de données. Toutefois, les écritures sont synchrones, ce qui signifie que chaque opération d'écriture ne se termine que lorsque tous les serveurs de cache sont mis à jour de manière synchrone. Pour cette raison, les écritures ne sont pas aussi rapides que les autres topologies et leurs performances se dégradent lorsque vous augmentez la taille du cluster au-delà de 2 nœuds.
• - Le client se connecte à un seul serveur: chaque client de cache ne se connecte qu'à un seul serveur du cluster sur la base d'un algorithme d'équilibrage de charge déterminé par les serveurs de cache. Si ce serveur de cache tombe en panne, le client se connecte au serveur suivant de la liste. Vous pouvez également spécifier manuellement le serveur auquel vous connecter dans le fichier de configuration du cache si vous ne souhaitez pas utiliser l'équilibrage de charge.

Cache en miroir

Mirrored Cache est un cluster de cache actif/passif à 2 nœuds destiné aux environnements plus petits. Il assure la fiabilité des données grâce à la réplication/mise en miroir asynchrone du nœud actif au nœud passif. Il est très rapide en lecture et en écriture (en fait, les écritures sont plus rapides que le cache répliqué) mais ne s'étend pas au-delà de ce cluster actif/passif à 2 nœuds.

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

• - 1 serveur actif et 1 serveur passif: Mirrored Cache n'a que deux serveurs. L’un est actif et l’autre est passif. Ils ont tous deux une copie de l’intégralité du cache. Si le serveur actif tombe en panne, le serveur passif devient automatiquement actif. Et, si le serveur actif précédemment arrêté revient, il est traité comme un serveur passif, sauf si vous modifiez cette désignation via les outils d'administration au moment de l'exécution.
• - Connexions clients avec prise en charge du basculement: chaque client de cache se connecte uniquement au serveur actif du cluster pour effectuer ses opérations de lecture et d'écriture. Si ce serveur actif tombe en panne, tous les clients se connectent automatiquement au serveur passif devenu actif. Cette prise en charge du basculement garantit que Mirrored Cache est toujours opérationnel même si un serveur tombe en panne.
• - Mise en miroir asynchrone: toutes 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 dernières données au cas où le serveur actif tomberait en panne et que le serveur passif devrait devenir actif. La mise en miroir asynchrone signifie également des performances plus rapides car plusieurs écritures sont effectuées en tant qu'opération EN BULK sur le serveur passif.

Cache client (vitesse InProc)

Le cache client est local sur votre serveur Web / application et se trouve très près de votre application et vous permet de mettre en cache les données que vous lisez à partir du cache distribué (toute topologie de mise en cache). Vous pouvez voir cela comme un "cache au-dessus d'un cache" et améliore considérablement les performances et l'évolutivité de votre application. Si vous utilisez Client Cache en mode InProc, vous pouvez atteindre la vitesse InProc.

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 intensive: Le cache client n'est utile que si vous avez un cas d'utilisation intensif en lecture où le nombre de lectures est plusieurs fois supérieur à celui des écritures. Si le nombre d'écritures est le même que celui des lectures, le cache client est en réalité plus lent car une écriture implique de le mettre à jour à deux endroits.
• - Vitesse plus rapide qu'un cache local (InProc / OutProc): un cache client existe soit à l'intérieur de votre processus d'application (mode InProc), soit local sur votre serveur Web/application (mode OutProc). Dans les deux cas, cela améliore considérablement les performances de votre application par rapport à la simple récupération de ces données à partir du cache cluster. Le mode InProc vous permet de mettre en cache des objets sur votre « tas d'application », ce qui vous donne une « vitesse InProc » qui ne peut être égalée par aucun cache distribué.
• - Pas un cache autonome: Le cache client peut être un cache local mais ce n'est pas un cache autonome. Au lieu de cela, il reste synchronisé avec le cache cluster. Cela signifie que si un autre client met à jour les données dans le cache cluster que vous avez dans votre cache client, le cache cluster demande au cache client de se mettre à jour avec la dernière copie de ces données. Et cela se fait de manière asynchrone mais immédiatement.
• - Synchronisation optimiste/pessimiste: Par défaut, Client Cache utilise la synchronisation optimiste, ce qui signifie que NCache client suppose que toutes les données dont dispose le cache client sont la dernière copie. Si le cache du client ne contient aucune donnée, le client les récupère dans le cache en cluster, les place dans le cache du client et les renvoie à l'application cliente. La synchronisation pessimiste signifie que le client de cache vérifie d'abord le cache en cluster s'il possède une version plus récente d'un élément mis en cache. Si tel est le cas, le client le récupère, le place dans le cache client et le renvoie à l'application client. Sinon, il renvoie tout ce qui se trouve dans le cache client.
• - Plug-in sans aucun changement de code: la meilleure chose à propos de Client Cache est qu'il n'implique aucun changement de code dans votre application. Au lieu de cela, vous le branchez simplement via un changement de configuration. Et, NCache L'API client en coulisse sait quoi faire pour utiliser le cache client.

Que faire ensuite?

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