Aller au contenu principal

Vous venez de Redis : pointer votre application .NET vers Zaris

· 6 minutes de lecture
Clustron Team
Clustron Team
Ingénierie des systèmes distribués

Deux chemins de Redis vers Zaris

Si vos services .NET communiquent déjà avec Redis, passer à Zaris n'a pas à être une réécriture. Zaris est un store clé-valeur distribué, en mémoire et répliqué, conçu nativement pour .NET — et depuis la 2.0.0, il parle deux protocoles à la fois : son propre protocole binaire efficace pour les clients .NET de premier ordre, et un front-end RESP2 compatible Redis que n'importe quel client Redis, dans n'importe quel langage, peut viser.

Cela vous offre deux chemins de migration honnêtes, qui ne s'excluent pas mutuellement. Vous pouvez commencer par le chemin RESP sans aucune modification pour mettre Zaris sous charge dès aujourd'hui, puis adopter le client natif là où cela est rentable. Cet article parcourt les deux et vous donne une règle claire pour choisir.

Chemin A — conserver votre client Redis​

Le moyen le plus rapide d'essayer Zaris est de ne rien changer à votre code. Activez le listener RESP sur vos nœuds Zaris et pointez votre client Redis existant vers le port RESP d'un nœud. Zaris accepte les commandes Redis ordinaires, achemine chacune d'elles vers la partition propriétaire de la clé, et répond sur le protocole que votre client comprend déjà.

Voici StackExchange.Redis communiquant avec Redis :

var mux = await ConnectionMultiplexer.ConnectAsync("redis-0:6379");
var db  = mux.GetDatabase();

await db.StringSetAsync("session:42", payload, TimeSpan.FromMinutes(30));
var back = await db.StringGetAsync("session:42");

Et voici le même code contre Zaris — la seule chose qui change est l'hôte :

var mux = await ConnectionMultiplexer.ConnectAsync("zaris-0:6379");
var db  = mux.GetDatabase();

await db.StringSetAsync("session:42", payload, TimeSpan.FromMinutes(30));
var back = await db.StringGetAsync("session:42");

Pas de nouveau package, pas de changement d'API. En interne, Zaris hache les clés avec le même calcul de slot CRC16(key) % 16384 qu'utilise Redis Cluster, de sorte qu'un client conscient du cluster achemine chaque clé directement vers le nœud qui la possède — pas de proxy, pas de saut supplémentaire, exactement comme Redis Cluster. (Derrière un simple load balancer ou Sentinel, n'importe quel nœud acceptera n'importe quelle clé à la place.) Si vous voulez les détails de son fonctionnement et du comportement en cas de basculement, voir comment Zaris parle le protocole Redis et la référence du protocole Redis.

Ce à quoi veiller sur ce chemin :

  • RESP2 uniquement. Le front-end parle RESP2, alors figez votre client Redis sur des versions qui négocient RESP2 et ne présument pas des trames push RESP3.
  • Certaines commandes sont proprement rejetées, pas simulées. Lua/EVAL, geo, HyperLogLog, bitmaps et la persistance RDB/AOF ne sont pas implémentés — Zaris renvoie un clair « non pris en charge » plutôt que de faire semblant. Le détail complet de ce qui fonctionne figure dans la matrice de compatibilité des commandes Redis, mesurée par rapport à StackExchange.Redis 2.8.16 : environ 126 commandes prises en charge, 92 proprement non prises en charge, zéro surprise.
  • Les commandes de coordination que vous utilisez vraiment sont présentes. MULTI/EXEC se traduisent sur les transactions natives à validation en deux phases de Zaris, SET key val NX PX vous donne le modèle de verrou distribué, et les notifications d'espace de clés fonctionnent.

Ce chemin est idéal lorsqu'un service est polyglotte, lorsque Redis est partagé entre plusieurs équipes, ou lorsque vous voulez simplement que Zaris tourne en staging dès cet après-midi.

Chemin B — le client .NET natif​

Une fois que Zaris a fait ses preuves, le client natif est ce qui permet aux applications .NET-first d'en tirer le meilleur parti. Ce n'est pas un enrobage de protocole — c'est un véritable client .NET aux API typées, et ses opérations du chemin critique (Get/Put/Delete/Expire/Persist/TTL) renvoient un ValueTask, de sorte qu'elles n'allouent rien lorsqu'elles se terminent de façon synchrone.

L'adoption est essentiellement une affaire de configuration. Si vous êtes sur ASP.NET Core et utilisez Redis comme IDistributedCache, le basculement tient en deux lignes :

// Program.cs
builder.Services.AddClustronZaris("cache", "zaris://cache-0:7861,cache-1:7861/app");
builder.Services.AddClustronDistributedCache("cache");

// ...then inject IDistributedCache (or HybridCache) and use it exactly as before.

Les chaînes de connexion sont les mêmes partout — en intra-processus, à distance, sur Docker ou Kubernetes :

zaris://host:7861/store

Utilisez zariss:// pour le TLS, séparez les hôtes d'amorçage par des virgules pour le basculement, et fournissez les tokens en toute sécurité avec env: ou file: plutôt qu'en ligne.

Au-delà du cache, le client natif vous offre des choses que l'API Redis ne modélise tout simplement pas comme des opérations de premier ordre : des hashes, listes, sets, sorted sets et Streams typés ; le compare-and-swap ; les opérations en masse et par lots ; les requêtes par scan et par préfixe ; et un ensemble complet de primitives de coordination — transactions, verrous distribués, élection de leader, baux, compteurs, limitation de débit et une file de tâches. Si vous les assembliez jusqu'ici à partir de briques Redis et de Lua, elles sont ici natives.

Lequel choisir, et quand​

Une règle simple :

  • Optez pour le chemin A (RESP) lorsque l'appelant n'est pas en .NET, lorsque Redis est partagé entre plusieurs services, ou lorsque vous voulez l'essai le plus rapide possible sans aucune modification de code.
  • Optez pour le chemin B (natif) lorsque le service est en .NET, lorsque le débit sans allocation vous importe, ou lorsque vous voulez des structures de données typées et des primitives de coordination plutôt que des modèles bricolés à la main.

La plupart des équipes aboutissent à un mélange — RESP pour les marges polyglottes, natif pour le cœur .NET — et c'est un état final parfaitement valable, pas une demi-migration.

Une note de mise à niveau​

Zaris 2.0.0 est une version majeure assortie d'une rupture du protocole filaire sur le client natif : le routage du cluster est passé à un hachage aligné sur CRC16, et le minimum de protocole est désormais 2. Un serveur 2.0.0 rejette les clients antérieurs à la 2.0 au niveau de HELLO, alors mettez à niveau vos clients natifs et vos serveurs ensemble. Le front-end RESP n'est pas affecté — les clients Redis ne participent pas du tout au protocole natif. L'histoire complète figure dans l'annonce de la 2.0.0.

Pour commencer​

dotnet add package Clustron.Zaris.SDK --version 2.0.0

Si votre pile est en .NET et que vous utilisez Redis surtout parce que c'était le choix évident, Zaris vous permet de conserver tout ce qui fonctionne aujourd'hui et d'adopter l'intégration native à votre propre rythme.