Aller au contenu principal

Présentation du guide du développeur

Ce guide vous montre comment construire des applications .NET sur Clustron Zaris : comment obtenir un client, stocker et récupérer des données, exécuter des opérations en masse (bulk) et par lot (batch), effacer des données, contrôler le comportement d'écriture avec des options et gérer la sérialisation. Il couvre aussi les primitives de coordination (baux, verrous, compteurs, observateurs, transactions) qui rendent Zaris sûr à utiliser depuis de nombreux processus à la fois.

Chaque tâche de ce guide utilise la même interface client, IZarisClient, et le même code fonctionne que le store s'exécute in-process ou à travers un cluster distribué.

Ce que vous allez apprendre​

Le guide est orienté tâches. À la fin, vous saurez :

  • Résoudre un client depuis l'injection de dépendances et le réutiliser correctement.
  • Stocker, lire et supprimer des clés individuelles, et interpréter le KvResult que vous obtenez en retour.
  • Déplacer de nombreuses clés d'un coup avec les opérations en masse, et mélanger les types d'opérations avec des lots.
  • Effacer un préfixe, une plage de clés ou le store entier.
  • Attacher un TTL, des étiquettes, des baux et des contrôles de concurrence à une écriture via PutOptions.
  • Contrôler la façon dont vos objets sont sérialisés et désérialisés.
  • Concevoir les clés et les étiquettes pour que les balayages, les requêtes et les observateurs restent efficaces.
  • Rendre les opérations résilientes grâce aux nouvelles tentatives intégrées du client et aux motifs sûrs pour les nouvelles tentatives.
  • Observer un store à travers les métriques qu'il émet, et tester votre code contre un store in-process.
  • Appliquer les bonnes pratiques, éviter les pièges courants et utiliser Zaris comme cache ASP.NET Core.

Le workflow typique​

La plupart des applications suivent la même forme. Vous résolvez un client une fois au démarrage, puis vous le réutilisez pour chaque opération.

// 1. Resolve a client for a named store.
var client = await provider.GetAsync("default");

// 2. Write and read data.
await client.PutAsync("key", "value");
var result = await client.GetAsync<string>("key");

// 3. Inspect the result.
if (result.IsSuccess)
{
    Console.WriteLine(result.Value);
}

Chaque opération renvoie un objet résultat plutôt que de lever une exception sur une clé manquante ou une écriture rejetée. Vous vérifiez IsSuccess (ou le plus spécifique Status) au lieu d'intercepter des exceptions pour des résultats attendus. Les opérations de base couvrent ce motif en détail.

Primitives de coordination​

Les lectures et écritures sur une seule clé suffisent pour un cache. Lorsque plusieurs processus partagent le même store, vous devez aussi les coordonner. Zaris expose ces primitives via le même client :

  • Les baux accordent une propriété limitée dans le temps d'une clé. Lorsque le bail expire, les clés qui lui sont attachées sont supprimées.
  • Les verrous donnent à un seul appelant un accès exclusif à une clé pendant qu'il effectue un changement.
  • Les compteurs fournissent l'incrémentation et la décrémentation atomiques pour un état numérique partagé.
  • Les observateurs (watch) livrent des notifications de changement pour que votre code réagisse aux mises à jour au lieu de sonder.
  • Les transactions regroupent plusieurs opérations en une unité tout-ou-rien.

Chaque primitive a sa propre page plus loin dans ce guide.

Structures de données, pub/sub et Streams​

Au-delà du clé/valeur simple, Zaris 2.0.0 ajoute des collections et de la messagerie natives côté serveur, chacune étant une API client de première classe et aussi accessible via le front-end protocole Redis :

  • Structures de données — hachages (hashes), listes, ensembles (sets) et ensembles triés (sorted sets), les analogues des types Redis.
  • Pub/sub — messagerie publication/abonnement à l'échelle du cluster.
  • Streams — un journal durable en ajout seul (append-only) avec groupes de consommateurs et lectures bloquantes.

Le front-end protocole Redis (RESP) expose tout ce qui précède (plus le KV simple) aux clients Redis ordinaires dans n'importe quel langage.

La même API partout​

L'API client ne change pas entre les modes de déploiement. Un store configuré en InProc s'exécute à l'intérieur de votre processus ; un store configuré en Remote dialogue avec un cluster sur le réseau. Le code de votre application est identique dans les deux cas, de sorte que vous pouvez développer contre un store in-process et déployer contre un cluster sans réécrire d'appels. Voir Obtenir un client pour savoir comment sélectionner un mode via la configuration.

Étapes suivantes​