Aller au contenu principal

Cache distribué pour .NET

Un cache distribué conserve en mémoire des données partagées à accès rapide à travers plusieurs processus ou machines, de sorte que chaque instance de votre application voit les mêmes valeurs. Cet article explique ce qu'est un cache distribué, quand une application .NET en a besoin, et comment Clustron Zaris remplit ce rôle.

Ce qu'est un cache distribué​

Un cache stocke en mémoire des valeurs calculées ou récupérées afin que vous n'ayez pas à les produire de nouveau. Un cache distribué répartit cette mémoire sur plus d'un nœud et rend les données mises en cache accessibles depuis n'importe quelle instance de votre application.

La distinction prend tout son sens dès que votre application s'exécute sous forme de plusieurs processus. Un cache en processus (in-process) vit à l'intérieur d'une seule instance : chaque instance possède sa propre copie, les copies divergent, et aucune ne survit à un redémarrage. Un cache distribué détient un seul jeu de données logique que chaque instance lit et écrit, de sorte qu'une valeur écrite par une instance est visible à la requête suivante, même si une instance différente la traite.

Quand en avez-vous besoin​

Tournez-vous vers un cache distribué lorsque votre application s'exécute sous forme de multiples instances — pour la montée en charge, pour la disponibilité, ou parce qu'elle vit dans des conteneurs — et que ces instances ont besoin d'une vue partagée et cohérente des données chaudes. Les charges de travail typiques comprennent :

  • L'état de session, afin que n'importe quelle instance derrière un équilibreur de charge puisse servir la requête suivante d'un utilisateur.
  • La mise en cache des réponses d'API et de requêtes, afin qu'un résultat coûteux calculé une seule fois soit réutilisé dans toute la flotte.
  • La configuration et les feature flags, afin qu'un changement se propage à chaque instance sans redéploiement.
  • L'état applicatif partagé, tel que des compteurs ou des valeurs dérivées que plusieurs instances mettent à jour.

Comment Clustron Zaris sert de cache distribué​

Clustron Zaris est un store clé-valeur distribué et en mémoire pour .NET. En tant que cache, il vous offre les éléments que vous attendez d'une couche de cache :

  • Un stockage clé-valeur distribué partitionné à travers les nœuds, de sorte que la capacité croît à mesure que vous ajoutez des nœuds.
  • Une montée en charge horizontale à travers un cluster multi-nœuds.
  • L'expiration par durée de vie (TTL), de sorte que les entrées mises en cache vieillissent d'elles-mêmes.
  • Des API client .NET asynchrones pour les lectures et les écritures.
  • Une vue des données à l'échelle du cluster, de sorte que n'importe quel nœud peut servir une requête pour n'importe quelle clé.

Vous l'installez sous forme de package NuGet et vous lui parlez depuis le client .NET natif. En développement, vous pouvez exécuter le store en processus — embarqué dans votre application sans serveur distinct — puis, plus tard, pointer le même code client vers un véritable cluster distant sans le réécrire.

astuce

Commencez en processus pendant que vous construisez et testez, puis passez à un cluster distant pour la production. L'API client est la même dans les deux modes, donc le passage est un changement de configuration, pas une réécriture.

Plus qu'un cache​

Zaris est un store sensible à la coordination, pas seulement un cache. Aux côtés de get et set, il expose des primitives qu'un simple cache ne propose pas :

  • Des verrous distribués, afin qu'une seule instance exécute une section critique à la fois.
  • Des transactions, afin que plusieurs opérations s'appliquent de manière atomique.
  • Des notifications de surveillance (watch), afin qu'un client réagisse à la modification d'une clé au lieu d'interroger en boucle.
  • Des compteurs atomiques et des baux, pour l'état numérique partagé et la propriété avec expiration.

Cela vous permet d'utiliser un seul store à la fois pour les données mises en cache et pour la logique de coordination qui nécessite d'ordinaire un second système. Pour un traitement plus approfondi de ces primitives, consultez le guide de coordination ci-dessous.

Étapes suivantes​