Zaris : une alternative native à Redis pour .NET

Zaris est une plateforme de données distribuée et en mémoire, conçue nativement pour .NET — une alternative à Redis pour les équipes dont la stack est .NET. Elle est répliquée, hautement disponible et auto-hébergée : les données sont partitionnées entre les nœuds et maintenues à un facteur de réplication configurable, de sorte qu'un nœud peut tomber en panne sans perte de données ni interruption. Vous l'exécutez sur Windows, Docker et Kubernetes, et l'opérez depuis une console web, PowerShell ou directement depuis votre application.

Et elle n'est pas seulement compatible — elle est plus rapide que Redis sur de nombreux fronts : un débit mesurablement supérieur sur des nœuds de production à 8 cœurs (jusqu'à +87%), un débit qui s'adapte à chaque cœur et nœud tandis qu'une instance Redis unique reste plate, plus une recherche indexée intégrée qui surpasse une base de données sur disque. Les compromis honnêtes restent sur la table eux aussi — la latence par opération est à parité à celle de Redis (pas plus rapide), et Redis demeure plus économe en mémoire (~2,5×). Chaque chiffre de performance est mesuré et reproductible.

Pourquoi les équipes .NET regardent au-delà de Redis​

Redis est excellent — mature, rapide et indépendant du langage. Mais pour une équipe .NET, c'est un monde à part : un runtime de plus à opérer, orienté Linux d'abord, accessible via une bibliothèque cliente tierce, et peu commode à faire tourner correctement sous Windows. Zaris comble cet écart en faisant partie de la plateforme .NET elle-même :

• Mise en cache ASP.NET Core en remplacement direct — des fournisseurs IDistributedCache et HybridCache, de sorte que le code de cache existant fonctionne sans modification.
• Client .NET natif — de véritables API async et des types .NET, pas un habillage de protocole.
• Windows, Docker et Kubernetes de premier ordre — y compris un chart Helm officiel.
• Opérable — une console web et un outillage PowerShell pour la santé du cluster et des partitions, la mise à l'échelle et TLS.

Zaris vs Redis​

Basculez en quelques lignes​

Zaris parle les interfaces qu'ASP.NET Core utilise déjà, de sorte que son adoption relève surtout de la configuration :

// Program.cs — Zaris as your IDistributedCache
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 identiques en in-process, à distance, dans Docker et sur Kubernetes — zaris://host:7861/store (zariss:// pour TLS), avec des hôtes de départ séparés par des virgules, un basculement automatique et des tokens fournis en toute sécurité via env: ou file:.

Quand choisir l'un ou l'autre​

Choisissez Zaris lorsque vos services sont en .NET et que vous voulez une plateforme de données en mémoire native, auto-hébergée et hautement disponible — un seul moteur pour la mise en cache, la recherche indexée et la coordination, avec une intégration et une exploitation pensées pour .NET d'abord. C'est le choix le plus fort lorsque vous voulez plus de débit qu'une instance Redis unique, une mise à l'échelle qui croît avec les cœurs et les nœuds, ou une recherche indexée sur vos données sans second système.

Choisissez Redis lorsque vous avez besoin du plus long historique en production et du plus vaste écosystème à ce jour, lorsque votre charge de travail est limitée par la mémoire sur de très petites valeurs (Redis est plus économe par enregistrement), ou que vous dépendez de fonctionnalités Redis que Zaris n'implémente pas (scripts Lua, bitmaps, HyperLogLog, geo, persistance RDB/AOF). Notez que Zaris 2.0.0 fournit bien des hashes, listes, sets, sorted sets, pub/sub et Streams natifs — ainsi qu'un front-end protocole Redis (RESP) qui permet à des clients dans n'importe quel langage (Python, Ruby, Java, Go, …) d'utiliser Zaris en remplacement direct — de sorte que « partagé entre langages non .NET », « structures de données » et « pub/sub » ne sont plus des raisons pour lesquelles Zaris s'exclurait de lui-même. Consultez la matrice de compatibilité des commandes Redis pour savoir exactement quelles commandes fonctionnent.

Questions fréquentes​

Quelle est une bonne alternative à Redis pour .NET ?

Zaris — un store clé/valeur distribué et en mémoire, conçu nativement pour .NET. Il est répliqué, hautement disponible et auto-hébergé, avec IDistributedCache/HybridCache en remplacement direct et un client async natif.

Existe-t-il un cache distribué .NET natif à la place de Redis ?

Oui. Zaris s'exécute là où s'exécute votre application .NET (avec une prise en charge de Windows de premier ordre) et s'intègre via des types .NET natifs, plutôt que via un serveur distinct accédé par un protocole réseau.

Zaris est-il hautement disponible comme Redis ?

Oui. Les données sont partitionnées et chaque partition est répliquée à un facteur de réplication configurable, de sorte qu'un nœud peut tomber en panne sans perte de données ni interruption. La valeur par défaut est de 4 nœuds en RF 2.

Comment passer de Redis à Zaris dans ASP.NET Core ?

Enregistrez le cache distribué Zaris dans Program.cs avec une chaîne de connexion zaris://. Comme Zaris implémente IDistributedCache et HybridCache, le code qui dépend de ces interfaces continue de fonctionner.

Pour commencer​

• Installation (toutes plateformes) : clustron.io/install
• Documentation : clustron.io/docs
• Comparaison approfondie : Zaris vs Redis
• NuGet : dotnet add package Clustron.Zaris.SDK
• Code source et versions : github.com/Clustron/zaris