Aller au contenu principal

Zaris 2.0.0 : structures de données natives, Streams et un front-end protocole-Redis

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

Zaris 2.0.0 — Structures de données natives, Streams et un front-end protocole-Redis

Aujourd'hui, nous publions Zaris 2.0.0 — la plus importante version depuis que Zaris a atteint la disponibilité générale, et la première avec un changement de version majeure. Elle transforme Zaris, qui était un store clé-valeur rapide et répliqué, en un serveur de structures de données complet : hashes, listes, sets, sorted sets, pub/sub et Redis Streams natifs, tous partitionnés et répliqués de la même façon que le sont déjà vos clés.

Et elle ouvre la porte à tous les autres. Chaque nœud peut désormais exposer un front-end protocole-Redis (RESP), de sorte qu'une application en Python, Ruby, Java, Go — n'importe quel langage disposant d'un client Redis — peut pointer vers Zaris et l'utiliser en remplacement direct, sans SDK natif et sans réécrire une ligne.

Le numéro de version est un 2, et non un 1.x, pour une raison : la 2.0.0 modifie le protocole filaire. Lisez la note de mise à niveau ci-dessous avant de la déployer.

Deux portes d'entrée, un seul store, sept types de données

Structures de données natives​

Zaris 1.x stockait des valeurs. Zaris 2.0.0 stocke des collections. Les hashes, listes, sets et sorted sets sont désormais des types de premier ordre, côté serveur, assortis de véritables API .NET typées :

await client.DataStructures.Hash("user:42").SetAsync("email", "ada@example.com");
await client.DataStructures.SortedSet("leaderboard").AddAsync("ada", score: 4096);
var top = await client.DataStructures.SortedSet("leaderboard").RangeByRankAsync(0, 9);

Chaque collection est une unique valeur logique qui réside sur la partition propriétaire de sa clé, et chaque mutation emprunte le même chemin répliqué qu'un Put ordinaire — une lecture-modification-écriture par compare-and-swap sur la valeur entière — de sorte qu'un hash ou un sorted set est exactement aussi durable et hautement disponible qu'une simple clé. Nous les avons construits et validés face à des clients .NET, Java et Ruby afin que la sémantique tienne à travers les langages, et pas seulement en intra-processus.

Consultez le guide des structures de données pour l'API complète.

Pub/Sub et Streams​

Deux autres types de collection complètent l'ensemble.

Le Pub/Sub vous offre une publication/souscription à l'échelle du cluster — diffusez un message à chaque abonné de tout le cluster, pas seulement à ceux connectés à un seul nœud.

Les Streams sont le véritable fait marquant : un journal en ajout seul doté de groupes de consommateurs et de lectures bloquantes, natif à Zaris et accessible via les commandes RESP XADD / XREAD / XREADGROUP. Cela fait de Zaris un cinquième type de collection — un journal d'événements durable et répliqué que vous pouvez utiliser pour des files de travail, des flux de changements et de l'event sourcing, validé en direct face à un client StackExchange.Redis standard sur un socket.

await client.Streams.Stream("orders").AppendAsync(new { id = 1001, total = 59.90 });
var batch = await client.Streams.Stream("orders").ReadGroupAsync("fulfilment", "worker-1", count: 10);

Les détails figurent dans les guides streams et pub/sub.

Un front-end protocole-Redis pour n'importe quel langage​

Zaris a toujours parlé son propre protocole binaire efficace à ses clients de premier ordre — le client .NET, PowerShell, la console. La 2.0.0 ajoute une seconde porte : chaque nœud peut aussi exécuter un listener RESP2, de sorte que n'importe quel client Redis existant peut parler directement à Zaris.

Cela fonctionne comme le fait Redis Cluster. Zaris hache les clés avec le même calcul de slot CRC16(key) % 16384 qu'utilise Redis Cluster, et chaque nœud annonce une vue CLUSTER SLOTS exacte, de sorte qu'un client Redis conscient du cluster achemine chaque clé directement vers le nœud qui la possède — pas de proxy, pas de saut supplémentaire. Lorsque la commande atteint le propriétaire, elle est servie directement depuis le store intra-processus de ce nœud, et lors d'un basculement le client reçoit un MOVED et rafraîchit sa carte de slots. Vous préférez ne pas exécuter de client conscient du cluster ? Placez les nœuds derrière un load balancer ou utilisez Sentinel à la place, et n'importe quel nœud acceptera n'importe quelle clé.

# point any Redis client at a Zaris node's RESP port
redis-cli -h zaris-0 -p 6379 SET greeting "hello from zaris"
redis-cli -h zaris-0 -p 6379 GET greeting

Nous avons mesuré la couverture face à StackExchange.Redis 2.8.16 : 126 commandes prises en charge, 92 proprement non prises en charge, et zéro échec. « Proprement non prise en charge » est la partie importante — les commandes que Zaris n'implémente pas (Lua/EVAL, geo, HyperLogLog, bitmaps, *STORE inter-clés, retraits bloquants de liste, persistance RDB/AOF) sont rejetées honnêtement plutôt que de faire silencieusement la mauvaise chose. Ce qui est présent couvre le quotidien : les chaînes, INCR/DECR, MGET/MSET, les hashes, les listes, les sets, les sorted sets, les streams, SUBSCRIBE/PUBLISH, les notifications d'espace de clés, MULTI/EXEC/WATCH (projetés sur les transactions natives à validation en deux phases de Zaris), et le modèle de verrou distribué SET NX PX. C'est du RESP2, alors figez les versions de votre client.

Il existe tout un article sur le fonctionnement de ce front-end — N'importe quel langage, un seul store — ainsi que la matrice de compatibilité des commandes exacte si vous voulez vérifier une commande précise avant de basculer.

Des lectures qui montent en charge avec vos cœurs​

Zaris achemine chaque clé vers un propriétaire et répartit le travail par cœur, plutôt que de tout canaliser par une unique boucle d'événements. L'effet pratique : le débit en lecture grimpe à mesure que vous ajoutez des cœurs. À travers le front-end RESP, GET tourne à environ 483 000 ops/s sur un cœur et à peu près 946 000 sur quatre, tandis que les moteurs mono-thread comme Redis et Memurai restent plats autour de 740 000–780 000 quel que soit le nombre de cœurs qu'on leur donne.

Soyons honnêtes — cela représente environ 2× le débit pour 4× les cœurs, pas parfaitement linéaire. Mais la direction est tout l'intérêt : un moteur partitionné et multi-thread a de la marge pour croître, et un moteur mono-boucle d'événements n'en a pas. Le détail complet, avec les mises en garde honnêtes sur le benchmarking limité par le client, figure dans Des lectures qui montent en charge avec vos cœurs.

La 2.0.0 resserre aussi le reste du chemin critique : le chemin SET a perdu une lecture-avant-écriture redondante, les opérations de base du client natif (Get/Put/Delete/Expire/Persist/TTL) renvoient désormais un ValueTask de sorte que les complétions synchrones n'allouent rien, et un mode optionnel pour objets volumineux stocke les grosses valeurs fréquemment mises à jour sous forme de morceaux inférieurs au LOH pour alléger la pression sur le GC.

Mise à niveau : il s'agit d'une rupture du protocole filaire​

La 2.0.0 est une version majeure parce qu'elle change le protocole. Le routage natif 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 (1.x) lors du handshake HELLO. C'est délibéré : un client 1.x et un serveur 2.0.0 seraient en désaccord sur l'endroit où réside une clé, nous échouons donc rapidement au moment de la connexion plutôt que de corrompre le placement.

La règle de mise à niveau est simple : faites passer les clients et les serveurs à la 2.0.0 ensemble. Si vous pointez plutôt un client Redis vers le front-end RESP, vous contournez entièrement le couplage de version du client natif — la porte RESP parle un protocole standard et stable.

Pour commencer​

NuGet :

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

Windows : récupérez clustron-zaris-2.0.0-win-x64.zip depuis la page de release (vérifiez-le par rapport à SHA256SUMS.txt).

Docker :

docker pull clustron/zaris-node:2.0.0
docker pull clustron/zaris-manager:2.0.0

Kubernetes (Helm) :

helm install zaris oci://registry-1.docker.io/clustron/zaris --version 2.0.0 \
-n zaris --create-namespace

Déjà sur Redis et vous vous demandez à quoi ressemble un passage en pratique ? Commencez par Vous venez de Redis, ou le guide d'installation si vous voulez simplement un cluster opérationnel.

Zaris reste gratuit à exécuter sous la licence Business Source License 1.1, avec un support commercial disponible sur clustron.io/support. Les notes de version complètes et les téléchargements sont sur GitHub. Nous serions ravis de savoir ce que vous construisez avec.