6 articles tagués avec « Modèles distribués »

L'essentiel de ce blog est allé en profondeur sur une chose à la fois — comparaison-et-échange, transactions multi-clés, structures de données natives, streams, watch, le journal d'opérations en dessous. Chaque article répond à « comment ceci fonctionne ». Celui-ci répond à une question différente, plus pratique : quand vous avez un problème devant vous, lequel choisissez-vous ?

Cette question compte parce que le mauvais choix est rarement un plantage. C'est un système qui marche dans la démo puis perd une mise à jour sous charge, ou qui canalise un millier d'écrivains à travers une seule clé, ou qui utilise une notification tire-et-oublie là où il lui fallait un journal durable. Les primitives ne vous empêchent pas de les mal utiliser. Alors voici un guide de terrain : le modèle mental qui les relie, une table de décision, une descente de chaque branche avec son adéquation honnête et sa limite honnête, et un organigramme à la fin.

Les notifications d'espace de clés sont l'une des fonctionnalités les plus utiles de Redis et l'une de ses plus discrètement fragiles. L'idée est charmante : chaque fois qu'une clé est écrite, supprimée ou expire, le serveur publie un événement sur un canal pub/sub bien connu, et quiconque s'y intéresse peut PSUBSCRIBE et réagir — invalider un cache, réveiller un travailleur, rafraîchir une projection. Pas de scrutation, pas de GET dans une boucle à demander « a-t-elle changé encore ? ».

La fragilité est dans les petits caractères. Les notifications d'espace de clés Redis sont du pub/sub tire-et-oublie, émis par le nœud qui a traité la commande, vers les abonnés connectés à ce même nœud. Dans un déploiement en cluster, cela signifie qu'un abonné n'entend parler que des écritures qui ont justement atterri sur le nœud auquel il est rattaché, et si ce nœud bascule, l'abonnement — et le flux d'événements qu'il portait — part avec lui. La fonctionnalité marche magnifiquement sur une machine unique et devient subtile très vite dès qu'il y en a plus d'une.

Zaris parle exactement le même protocole — CONFIG SET notify-keyspace-events, les canaux __keyspace@0__ et __keyevent@0__, un PSUBSCRIBE ordinaire depuis n'importe quel client Redis dans n'importe quel langage. Mais la plomberie en dessous n'est pas une réimplémentation du notifieur de Redis. C'est un pont mince vers une fonctionnalité que Zaris possédait déjà : un watch natif, à l'échelle du cluster, répliqué. Cela change ce que valent les notifications.

Un article compagnon, Coordination sans course sur le CAS optimiste, a défendu l'idée qu'une primitive unique — une version possédée par le store plus une écriture conditionnelle gardée par la version — porte une quantité remarquable de coordination. Il a aussi tracé une ligne nette : le CAS est atomique sur une clé. Transférez de l'argent du compte A vers le compte B et un seul compare-and-swap ne peut pas couvrir les deux ; le conseil honnête était de modéliser le transfert comme une machine à états sur une clé, ou de recourir à une saga.

Cette ligne est réelle, mais ce n'est pas toute l'histoire. Zaris dispose d'une véritable transaction multi-clés — BeginTransactionAsync, un ensemble de lecture/écriture mis en attente, CommitAsync — et elle commite à travers les clés et à travers les nœuds avec une garantie du tout ou rien. Cet article porte sur ce qu'est réellement cette transaction sous le capot (un commit à deux phases coordonné par le client sur des versions optimistes), précisément ce qu'elle garantit, et la seule subtilité qui décide si votre invariant inter-clés tient réellement.

Voici un fait concernant tout store clé-valeur partitionné que les schémas léchés ont tendance à passer sous silence : le nœud qui possède votre clé va se déplacer. Un nœud tombe en panne et ses partitions basculent vers leurs réplicas. Vous montez en charge et les partitions migrent vers le nouveau membre. Un primaire préféré revient et la propriété lui est rendue. Chacun de ces événements signifie que le nœud auquel votre client parlait tranquillement il y a une milliseconde est, à l'instant présent, le mauvais nœud pour un certain ensemble de clés.

L'expérience client naïve de ce moment est désagréable : une connexion réinitialisée, une « erreur serveur » générique ou — pire — une écriture qui atterrit sur un nœud qui n'est plus le propriétaire actif et qui, discrètement, ne mène nulle part. Le client Zaris .NET est conçu pour que rien de tout cela n'atteigne votre code. Un changement de propriété devient un statut typé, le client redirige vers le nouveau propriétaire, et la nouvelle tentative est bornée à la fois par un budget de tentatives et par une échéance en temps réel. Dans le cas courant, votre PutAsync prend simplement quelques millisecondes de plus et renvoie Ok. Cet article traite de la mécanique qui rend cela vrai et — tout aussi important — des cas qu'elle choisit délibérément de ne pas masquer.

Il est tentant de juger un store de données à la longueur de sa liste de commandes. Redis a INCR, SETNX, MULTI/EXEC, WATCH, Lua, SCAN, pub/sub — un verbe pour chaque occasion. Le client .NET de Zaris, en comparaison, paraît presque austère. Il n'y a pas d'incrément atomique côté serveur. Il n'y a pas de transaction multi-clés générale qui exécute une logique arbitraire. Il n'y a pas de scan de préfixe. Le pub/sub natif n'existe qu'à travers le front-end RESP, pas le client .NET typé.

Ce que le client .NET vous donne à la place est une petite primitive de coordination tranchante : le compare-and-swap versionné optimiste. Cet article porte sur la distance que parcourt réellement cette seule primitive — car la réponse honnête est : étonnamment loin. Un limiteur de débit, un portefeuille qui ne devient jamais négatif sous un millier de débits concurrents, une file de jobs où exactement un worker revendique chaque job, et un jeu de règles de feature-flag qui ne perd jamais une mise à jour sous des éditions d'administration concurrentes. Tous, à partir de la même primitive, sans machinerie supplémentaire côté serveur.

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.