Topologies de mise en cache pour une é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.

Vous trouverez ci-dessous les principales topologies de mise en cache qui NCache fournit:

1. Cache partitionné
2. Cache de Partition-Réplica
3. Cache répliqué
4. Cache en miroir (2 nœuds actif/passif)
5. Cache Client (Vitesse InProc ; cache local connecté au cache en cluster)

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.

La mise en cache d'un catalogue de produits où les prix ne changent pas très fréquemment est une donnée de référence. D'autre part, ASP.NET Core Le stockage des sessions est considéré comme une utilisation transactionnelle car une session est lue et mise à jour une fois sur chaque requête Web, ce qui peut se produire toutes les quelques secondes.

Au début, un cache était considéré comme bon principalement pour les données de référence, car les données qui changeaient fréquemment devenaient obsolètes et désynchronisées avec les dernières données de la base de données. Mais, 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 sont bonnes pour les données de référence, mais seules certaines topologies de mise en cache sont particulièrement meilleures pour les données transactionnelles. Vous devez déterminer le nombre de lectures par rapport aux écritures que vous ferez pour déterminer quelle topologie vous convient le mieux. De plus, certaines topologies de mise en cache ne s'adaptent pas autant spécialement aux mises à jour, alors gardez cela à l'esprit également.

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

1. 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.
2. Cache de Partition-Réplica (Le plus populaire): très bon. Super 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. Meilleure combinaison de vitesse/évolutivité et fiabilité des données.
3. Cache répliqué: Très bien pour les petits environnements. Superrapide et linéairement évolutif pour les lectures. Modérément rapide pour les écritures dans un cluster à 2 nœuds, mais ne s'adapte pas à mesure que vous ajoutez des serveurs, car les écritures sont effectuées de manière synchrone sur tous les serveurs de cache.
4. Cache en miroir: Très bien pour les petits environnements. Super rapide pour les lectures. Les écritures sont plus rapides que le cache répliqué pour 2 nœuds actifs/passifs. Mais, n'évolue pas au-delà de cela.
5. 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é.

1. Partitions dynamiques : le cache est divisé en partitions au moment de l'exécution, chaque serveur de cache ayant une partition. Il y a un total de 1000 compartiments par cache en cluster qui sont répartis uniformément sur toutes les partitions. L'ajout/la suppression d'un serveur de cache entraîne la création/la suppression de partitions lors de l'exécution. L'affectation des compartiments aux partitions ne change pas lorsque des données sont ajoutées au cache. Au lieu de cela, il ne change que lorsque des partitions sont ajoutées ou supprimées ou lorsque l'équilibrage des données se produit (voir ci-dessous).
2. Carte de répartition : le cluster de cache crée une carte de distribution qui contient des informations sur les compartiments qui existent dans les 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 parler pour lire ou écrire un certain élément mis en cache.
3. É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.
4. Les clients se connectent à TOUTES les partitions : les clients se connectent à tous les serveurs de cache afin qu'ils puissent directement lire ou écrire des données en une seule requête du serveur. Si la connexion d'un client avec un serveur de cache tombe en panne, il demande à l'un des autres serveurs de lire ou d'écrire un élément en cache qui existe 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.

1. Partitions dynamiques : même que Cache partitionné.
2. Répliques dynamiques : lorsque des partitions sont créées ou supprimées lors 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'y a qu'une seule réplique pour une partition.
3. 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 toutes les données de la partition et toutes ces opérations sont mises en file d'attente. Et, ensuite, 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, c'est parfaitement bien.
4. Synchroniser la réplication : Si 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 "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 la réplique jusqu'à ce qu'elles soient considérées comme terminées. Ainsi, si l'opération échoue sur la réplique, elle échoue également sur la partition. De plus, vous pouvez être assuré que toutes les données du cache (à la fois dans la partition et dans la réplique) sont toujours cohérentes. Cependant, cela a une implication sur les performances car il est plus lent que la réplication asynchrone.
5. Carte de répartition : même que Cache partitionné.
6. Équilibrage dynamique des données (partitions et répliques) : même que Cache partitionné. Cependant, dans Partition-Replica Cache, l'équilibrage des données se produit également dans les répliques lorsque les données des partitions sont équilibrées.
7. Les clients se connectent à TOUTES les partitions : même que Cache partitionné. De plus, dans Partition-Replica Cache, les clients ne parlent qu'aux partitions et non à leurs répliques. En effet, les répliques sont passives et seules les partitions communiquent avec leurs répliques lors de la réplication des données vers celles-ci.

Cache répliqué

Le cache répliqué assure la fiabilité des données grâce à la réplication sur deux ou plusieurs serveurs de cache. 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 Cache de Partition-Réplica. 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é.

1. Nœuds répliqués dynamiques : vous pouvez ajouter ou supprimer des serveurs de cache lors de l'exécution d'un cache existant sans arrêter le cache ou votre application. Le serveur nouvellement ajouté crée une copie (réplique) de l'intégralité du cache sur lui-même. De plus, le serveur supprimé met à jour l'appartenance au cluster et tous ses clients sont déplacés vers d'autres serveurs.
2. Cache entier sur chaque nœud : l'intégralité du cache est copiée sur chaque serveur du cluster.
3. Les lectures sont évolutives : les lectures sont ultrarapides 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.
4. Les écritures sont synchroniséesus: les écritures sont très rapides pour un cluster à 2 nœuds et plus rapides que votre base de données. Cependant, les écritures sont synchrones, ce qui signifie que chaque opération d'écriture ne se termine pas tant que tous les serveurs de cache ne sont pas 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.
5. 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 dans 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

Le cache miroir 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 pour les lectures et les écritures (en fait, les écritures sont plus rapides que Cache répliqué) mais n'évolue pas au-delà de ce cluster actif/passif à 2 nœuds.

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

1. 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 à moins que vous ne changiez cette désignation via les outils d'administration au moment de l'exécution.
2. 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 qui est devenu actif à ce moment-là. Cette prise en charge du basculement garantit que le cache miroir est toujours opérationnel même si un serveur tombe en panne.
3. 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 tombe en panne et que le serveur passif doit devenir actif. La mise en miroir asynchrone signifie également des performances plus rapides car plusieurs écritures sont effectuées en tant qu'opération 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.

1. Bon pour les cas de lecture intensive : Le cache client n'est bon que si vous avez un cas d'utilisation intensive en lecture où le nombre de lectures est plusieurs fois supérieur au nombre d'écritures. Si le nombre d'écritures est le même que celui des lectures, le cache client est en fait plus lent car une écriture implique sa mise à jour à deux endroits.
2. Vitesse plus rapide comme un cache local (InProc / OutProc) : un cache client existe soit à l'intérieur de votre processus d'application (mode InProc), soit localement 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 en 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é.
3. 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 en cluster. Cela signifie que si un autre client met à jour les données dans le cache en cluster que vous avez dans votre cache client, le cache en cluster avertit le 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.
4. Synchronisation Optimiste / Pessimiste : Par défaut, le cache client 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.
5. 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