Demandez une clé à un store distribué et le coût est dominé par un seul nombre : l'aller-retour vers le nœud qui la possède. La recherche elle-même est de l'ordre de la nanoseconde ; le réseau est de l'ordre de la microseconde. Demandez maintenant un millier de clés. Si vous bouclez et appelez Get un millier de fois, vous payez cet aller-retour un millier de fois, en série, et le store passe presque tout le temps d'horloge à rester inactif en attendant des paquets. Les clés pourraient être réparties sur quatre nœuds qui auraient pu répondre en parallèle — mais une boucle naïve ne leur en donne jamais la chance.

Zaris a trois API en masse — GetManyAsync, PutManyAsync, DeleteManyAsync — et un ExecuteBatchAsync mixte en dessous, et toute leur raison d'exister est de transformer « un millier de clés » en « une requête par nœud propriétaire, émise en parallèle ». Cet article est le chemin de l'éventail de bout en bout : comment le client regroupe les clés par propriétaire, pourquoi les quatre API se réduisent à un seul moteur, comment un champ Index garde les réponses dans l'ordre à travers deux couches de concurrence, et pourquoi — contrairement à une transaction multi-clés — une opération en masse est par item et le succès partiel est normal.

Le modèle de coût : des allers-retours, pas des opérations​

Ce contre quoi une API en masse se bat n'est pas le CPU. Un GET à clé unique sur un nœud propriétaire est une recherche de dictionnaire — le plancher de latence est d'une microseconde de travail réel dans dix de plomberie. La partie coûteuse est la plomberie : la requête doit traverser le réseau vers le propriétaire et la réponse doit revenir. Appelez ce temps d'aller-retour R, typiquement des dizaines à des centaines de microsecondes sur un réseau de datacenter, des ordres de grandeur de plus que la recherche.

Une boucle en série de N clés coûte environ N × R, car chaque appel attend que le paquet du précédent revienne avant d'envoyer le suivant. C'est le piège. La solution n'est pas une recherche plus rapide — c'est de cesser de payer R par clé. Si les N clés vivent sur M nœuds propriétaires, le plancher est R payé M fois en concurrence, c'est-à-dire environ un R au total quel que soit le nombre de clés que chaque nœud détient. Pour un millier de clés sur quatre nœuds, c'est la différence entre un millier d'allers-retours en série et en pratique un seul. Toute la conception ci-dessous existe pour réduire N × R à ~R.

Un seul moteur : tout est un batch d'items​

La première chose surprenante dans le client de cluster est que GetManyAsync, PutManyAsync et DeleteManyAsync ne sont pas trois implémentations distinctes. Chacune est une fine coquille qui transforme ses arguments en une liste de KvBatchItem et les remet à l'unique méthode qui fait le vrai travail, ExecuteBatchAsync. Voici GetManyAsync faisant exactement cela :

var list = keys.Select((k, i) => new KvBatchItem
{
    Index = i,                 // caller's position — the correlation key
    Op    = KvBatchOp.Get,
    Key   = k,
    GetOptions = options?.ToGetOptions()
}).ToList();

var resp = await ExecuteBatchAsync<T>(
    new KvBatchRequest
    {
        Items = list,
        DefaultConsistency = options?.Consistency ?? Defaults.DefaultConsistency
    }, ct).ConfigureAwait(false);

PutManyAsync et DeleteManyAsync font de même avec KvBatchOp.Put et KvBatchOp.Delete. Donc la distinction que les exemples tracent entre Bulk (un seul type d'opération à la fois) et Batch (un mélange de PUT / GET / DELETE en un appel) est une commodité de surface : les helpers en masse ne sont qu'un batch où chaque item partage par hasard une op. Il y a exactement un moteur d'éventail, et il est agnostique à l'op.

Remarquez Index = i. Chaque item est estampillé de sa position dans la liste de l'appelant avant que quoi que ce soit ne soit groupé, réordonné ou envoyé. Cet estampillage est ce qui survit aux deux sauts concurrents à venir et permet de remettre la réponse finale dans l'ordre. Gardez-le en tête.

L'éventail : regrouper par propriétaire, une requête chacun​

Voici le cœur de tout l'article — le dispatch de batch du client de cluster, pour l'essentiel en entier :

var table   = _routing;
var buckets = new Dictionary<ZarisRemoteClient, List<KvBatchItem>>();

foreach (var item in batch.Items)
{
    var seg    = SegmentMapper.ComputeSegmentId(item.Key, table.TotalSegments);
    var client = GetClientForSegment(seg, table);

    if (!buckets.TryGetValue(client, out var list))
        buckets[client] = list = new List<KvBatchItem>();

    list.Add(item);
}

var tasks = buckets.Select(kv =>
    kv.Key.ExecuteBatchAsync<T>(new KvBatchRequest
    {
        Items = kv.Value,
        DefaultConsistency = batch.DefaultConsistency
    }, ct));

var perOwner = await Task.WhenAll(tasks).ConfigureAwait(false);

return new KvBatchResponse
{
    Results = perOwner.SelectMany(r => r.Results)
                      .OrderBy(r => r.Index)
                      .ToList()
};

Lisez-le comme quatre manœuvres :

1. Résoudre chaque clé vers son propriétaire, localement. SegmentMapper.ComputeSegmentId est la même fonction de placement qu'utilise le chemin à clé unique — CRC16 sur le hash-tag, modulo le nombre de segments — et GetClientForSegment mappe ce segment à la connexion déjà ouverte vers son nœud propriétaire. Pas de proxy, pas de coordinateur : le client calcule la possession lui-même, exactement comme décrit dans un saut vers le propriétaire. La différence est qu'ici il le fait pour chaque clé de l'ensemble d'un coup.

2. Regrouper. Les clés possédées par le même nœud s'empilent dans la liste de ce nœud. Un millier de clés réparties sur quatre propriétaires deviennent quatre listes. C'est là que N opérations deviennent M requêtes.

3. Dispatcher en concurrence. buckets.Select(...) construit un appel ExecuteBatchAsync par propriétaire et Task.WhenAll les laisse tous s'envoler d'un coup. Quatre nœuds répondent en parallèle ; le temps d'horloge est la réponse du nœud le plus lent, pas la somme.

4. Recombiner dans l'ordre. Chaque propriétaire renvoie sa tranche de résultats ; SelectMany les aplatit et OrderBy(r => r.Index) restaure l'ordre original de l'appelant. L'appelant récupère une liste dont la position i est la réponse pour la clé i, même si les clés ont voyagé vers des nœuds différents et sont revenues dans l'ordre où le réseau les a livrées.

C'est la revendication d'amortissement complète rendue concrète : le nombre d'allers-retours égale le nombre de nœuds propriétaires distincts dans l'ensemble de clés, pas le nombre de clés.

À l'intérieur d'un propriétaire : concurrent à nouveau, ordonné à nouveau​

Chaque sous-batch par propriétaire atterrit sur le BatchCommandHandler de ce nœud. Il n'exécute pas non plus les items l'un après l'autre — il les exécute tous d'un coup puis retrie :

var items = batchReq.Request.Items.Cast<KvBatchItemWire>().ToArray();

// Execute every item in the sub-batch concurrently.
var tasks   = items.Select(item => ExecuteItemAsync(item)).ToArray();
var results = await Task.WhenAll(tasks).ConfigureAwait(false);

return new ZarisResponse
{
    Payload = new BatchResponsePayload
    {
        Response = new KvBatchResponse
        {
            Results = results.OrderBy(r => r.Index).ToList()
        }
    }
};

ExecuteItemAsync est un petit switch sur l'op qui dispatche chaque item vers le store — GetRawAsync, PutRawAsync ou DeleteRawAsync — de sorte qu'un batch mixte de lectures et d'écritures est traité item par item à l'intérieur de la même requête. (Pour les routeurs en processus et mono-nœud, la même forme apparaît comme un Parallel.ForEachAsync sur les clés, borné par MaxDegreeOfParallelism — une option MaxParallelism ou Environment.ProcessorCount par défaut — ce qui est pourquoi les lectures montent avec les cœurs : un gros sous-batch garde chaque cœur occupé au lieu d'un seul.)

Donc l'estampillage Index gagne sa place deux fois. La concurrence brouille l'ordre sur le nœud, donc le handler trie par Index avant de répondre. L'éventail brouille l'ordre sur le client, donc le client trie par Index après la fusion. L'appelant ne voit jamais l'un ni l'autre brouillage. Un petit entier, porté sur chaque item dès l'instant où la requête est construite, est tout le mécanisme qui rend « tout balancer au cluster en parallèle » sûr à exposer comme une liste ordonnée.

Une opération en masse n'est pas une transaction​

C'est la distinction que les gens se trompent le plus souvent, alors elle vaut la peine d'être énoncée sans détour. Chaque item d'un batch porte son propre résultat. Le type de résultat par item enregistre le succès, le statut et — pour les opérations qui en ont — la révision, la version et le TTL de cette seule clé :

private static KvBatchItemResult MapKvToBatch(int index, KvBatchOp op, KvResult r) => new()
{
    Index   = index,
    Op      = op,
    Success = r.IsSuccess,
    Status  = r.Status,          // e.g. Success, NotFound, Moved
    Revision = r.Revision?.Value,
    ItemVersion = r.Version?.Version,
    Ttl     = r.TimeToLive
};

Il n'y a pas de point de commit partagé. Un GetMany sur une centaine de clés dont trente n'existent pas renvoie soixante-dix résultats Success et trente résultats NotFound, entrelacés par index — pas une erreur, pas une liste vide. Un PutMany où le segment d'une clé est en pleine migration renvoie cet unique item avec le statut Moved et le reste Success. Le succès partiel est la forme normale et attendue de la réponse, et l'appelant est censé inspecter chaque item.

C'est l'exact opposé d'une transaction multi-clés, qui est tout-ou-rien par construction : un commit à deux phases coordonné par le client sur des versions optimistes où soit chaque clé bouge, soit aucune. Les deux fonctionnalités se ressemblent de l'extérieur — toutes deux prennent de nombreuses clés en un appel — et sont bâties pour des besoins opposés. Optez pour un batch quand les clés sont indépendantes et que vous voulez du débit ; optez pour une transaction quand un invariant s'étend sur les clés et qu'un résultat à moitié appliqué le corromprait. Zaris les garde comme des API séparées précisément pour que la sémantique ne soit jamais ambiguë : un batch ne fait jamais silencieusement un rollback, et une transaction ne commit jamais silencieusement à moitié.

Survivre à une possession qui bouge en plein batch​

Une opération en masse est une cible plus large qu'un seul GET pour le problème de la possession qui change en dessous. Entre le moment où le client regroupe une clé vers le nœud A et le moment où le nœud A traite le sous-batch, un cut-over de partition peut avoir déplacé ce segment vers le nœud B. Le nœud A répondra à ces items avec le statut Moved plutôt que de deviner.

Le client de cluster enveloppe tout l'éventail dans un réessai borné pour exactement cela :

public override async Task<KvBatchResponse> ExecuteBatchAsync<T>(
    KvBatchRequest batch, CancellationToken ct = default)
{
    return await RetryHelper.RetryAsync(
        () => ExecuteBatchClusterAsync<T>(batch, ct),
        maxAttempts: 2,
        backoffMillis: 100,
        logger: _logger).ConfigureAwait(false);
}

Lors d'un réessai, la table de routage s'est généralement rafraîchie, donc le re-regroupement envoie les clés déplacées vers leur nouveau propriétaire. Le réessai est délibérément peu profond — deux tentatives, un bref backoff — car le but est de survivre à une table de routage momentanément périmée, pas de masquer un nœud réellement en panne. C'est la même discipline décrite dans les réessais sous churn de possession, appliquée à tout un ensemble de clés d'un coup : le réessai réexécute le regroupement, pas juste l'envoi, de sorte que chaque tentative reflète la possession la plus récente plutôt que de rejouer un plan périmé.

Un vrai bug, parce que la forme de fil a deux formes​

Il vaut la peine de montrer un endroit où ce chemin a cassé, car il dit quelque chose de spécifique aux opérations en masse. La valeur du résultat d'un GET peut arriver sur le fil sous deux formes — enveloppée dans une enveloppe ZarisEntry, ou comme une valeur sérialisée brute — selon la façon dont elle a été stockée (voir ce qui traverse le fil). Le décodeur de bulk-GET d'origine supposait seulement la forme enveloppée et levait une exception sur la forme brute.

Pour un seul GET c'est un échec à une clé. Pour un GetMany c'était catastrophique d'une façon subtile : chaque clé du batch échouait, car le seul encodage non géré levait avant qu'aucun résultat ne soit décodé. Une exécution de certification l'a signalé comme « échecs de bulk get », et la correction a été de router le décodage à travers un helper partagé de double encodage qui gère les deux formes :

// Decode through the shared helper (handles both the ZarisEntry-wrapper and
// the raw-value forms the server can emit). The old inline code assumed only
// the wrapper and threw, failing every key of a bulk GET.
var obj = KvBatchItemResultExtensions.GetValue<T>(r);

La leçon qui se généralise : dans un chemin en masse, un défaut dans la machinerie partagée par item est multiplié par la taille du batch, et une erreur qui est une gêne pour une clé est une panne pour un millier. Le modèle de résultat par item est ce qui contient le rayon d'explosion — une fois le décodage correct, une valeur malformée échoue un item et laisse les 999 autres intacts.

Ce que l'éventail achète​

Mettez les pièces ensemble et la forme du gain est claire. Un appel en masse estampille chaque item de son index, résout le propriétaire de chaque clé avec la même arithmétique de placement qu'utilise le chemin à clé unique, regroupe les clés pour que N opérations deviennent une requête par nœud propriétaire, tire ces requêtes en concurrence, et réassemble les réponses dans l'ordre de l'appelant — survivant à une table de routage qui se décale en plein vol et rapportant le sort de chaque clé indépendamment. Le nombre d'allers-retours tombe du nombre de clés au nombre de nœuds, qui est le seul nombre qui allait jamais compter.

Rien de tout cela n'a exigé un nouveau chemin de stockage ni un nouvel enregistrement de fil. Les API en masse sont une couche d'ordonnancement par-dessus les primitives que Zaris possède déjà : le placement conscient des partitions qui dit au client qui possède quoi, le contrat par enregistrement que chaque résultat d'item réutilise, et l'exécution parallèle sur les cœurs qui mâche un sous-batch une fois qu'il a atterri. La partie difficile de l'accélération sur de nombreuses clés n'a jamais été les clés — c'était de refuser de payer le réseau une clé à la fois.

Il y a deux façons honnêtes de construire un client de cache distribué. La première est de choisir n'importe quel nœud, de lui envoyer la requête, et de laisser le cluster la relayer en interne vers celui qui possède la clé — simple côté client, mais chaque requête qui atterrit sur le mauvais nœud paie un saut réseau supplémentaire à l'intérieur du cluster. La seconde est de rendre le client assez intelligent pour savoir quel nœud possède la clé avant d'envoyer quoi que ce soit, de sorte que la première socket qu'il touche soit celle qui peut réellement répondre. Zaris prend la seconde voie. Un GET quitte votre processus déjà adressé au nœud qui détient la clé — pas de proxy, pas de saut de relais, pas de coordinateur au milieu.

Cet article est la vue de l'intérieur de son fonctionnement : la fonction qui transforme une clé en propriétaire, la table de correspondance que le client garde en mémoire, et — la partie facile à rater — comment le client reste correct quand la possession bouge pendant que votre trafic est en vol.

La revendication, énoncée précisément​

Quand vous appelez client.GetAsync("user:42"), le client fait trois choses avant qu'aucun octet n'atteigne le réseau :

1. Hacher la clé en un segment. Une fonction pure mappe la chaîne de clé à l'un des segments du cluster.
2. Rechercher le propriétaire du segment. Un tableau en mémoire mappe ce segment directement à l'unique connexion qui atteint son nœud propriétaire actif.
3. Envoyer en direct au propriétaire. La requête passe par cette connexion et nulle part ailleurs.

Aucune étape ne consulte un routeur central. L'étape 1 est de l'arithmétique, les étapes 2 et 3 sont un index de tableau et une écriture de socket. Le client détient une connexion par nœud et une petite table de routage, et c'est tout l'appareillage. L'ingénierie intéressante n'est pas le chemin heureux — c'est de garder cette table honnête.

Étape 1 — la clé devient un segment​

Zaris hache les clés exactement comme le fait un client Redis Cluster, à dessein. La fonction de placement vit dans SegmentMapper, et son commentaire de doc est brutal sur pourquoi elle a l'air de ce qu'elle a l'air :

// Maps a key to its segment. Placement is aligned to the Redis Cluster slot model so a Redis cluster client
// (which routes by CRC16(key) % 16384) and Zaris agree on where a key lives: the key's Redis slot is
// computed the exact Redis way (XMODEM CRC16 over the hash-tag, mod 16384), then the 16384 slots are mapped
// proportionally onto the cluster's segments.
// This is the SINGLE shared placement function used by both the client and the server.

Cette dernière ligne est celle qui compte le plus. Ce n'est pas « le client calcule le placement d'une façon et le serveur le valide d'une autre ». C'est le même code, compilé dans l'assembly client et l'assembly serveur, produisant le même segment pour la même clé à chaque fois. Si le client et le serveur étaient en désaccord sur l'endroit où vit une clé, chaque écriture serait un pile ou face entre atterrir sur le propriétaire et atterrir sur un nœud qui doit la rejeter. Partager la fonction rend cette classe de bug irreprésentable.

Le calcul lui-même est deux manœuvres :

public static ushort ComputeSegmentId(string key, int shardCount, ...)
{
    var slot = ComputeSlot(key);                 // CRC16(hash-tag) % 16384
    return SlotToSegment(slot, shardCount);      // proportional slot -> segment
}

// The Redis Cluster key slot: XMODEM CRC16 over the hash-tag (or the whole key), mod 16384.
public static int ComputeSlot(string key)
{
    var (start, len) = HashTagRange(key);
    return Crc16(key, start, len) % RedisSlots;  // RedisSlots = 16384
}

D'abord la clé est réduite à un slot dans la plage fixe [0, 16384) en utilisant XMODEM CRC16 — le même polynôme CRC16-CCITT (0x1021, init 0x0000) qu'utilise Redis. Puis les 16384 slots sont mappés proportionnellement sur le nombre de segments que le cluster possède réellement :

public static ushort SlotToSegment(int slot, int shardCount)
    => (ushort)((long)slot * shardCount / RedisSlots);

Deux slots peuvent atterrir dans le même segment ; un segment est une plage contiguë de slots. Cet alignement est ce qui permet à Zaris de répondre correctement à CLUSTER SLOTS pour un client Redis Cluster tout en routant par son propre modèle de segment en interne — les deux vues sont la même vue à des résolutions différentes.

Hash tags : décider ce qui se co-localise​

Il y a une échappatoire délibérée dans le hachage des clés. Si une clé contient un groupe {...} avec au moins un caractère à l'intérieur des accolades, seuls les octets à l'intérieur des accolades sont hachés :

// Redis hash tag: if the key contains "{...}" with at least one char between the braces, only that
// substring is hashed (so "{u1}:a" and "{u1}:b" co-locate). Otherwise the whole key is hashed.

C'est ainsi que vous forcez des clés apparentées sur le même segment. {u1}:profile et {u1}:sessions hachent toutes deux sur u1, donc elles partagent un segment et par conséquent un propriétaire — ce qui est exactement ce dont vous avez besoin pour une transaction multi-clés ou toute opération qui doit toucher plusieurs clés atomiquement sur un nœud. Les clés sans tag s'étalent sur tout le keyspace. Le client et le serveur s'accordent là-dessus aussi, car c'est le même HashTagRange des deux côtés.

Un détail de plus à noter pour le chemin chaud : la boucle CRC16 a un chemin rapide tout-ASCII qui hache les caractères comme des octets sans allocation, et ne retombe sur un encodage UTF-8 que pour les clés non-ASCII. Router chaque opération signifie que cela s'exécute à chaque opération, donc il a été écrit pour ne pas allouer dans le cas courant.

Étape 2 — le segment devient une connexion​

Le client a maintenant un numéro de segment. Il lui faut le nœud qui le possède actuellement. Le client garde une RoutingTable immuable dont les champs sont toute l'histoire :

// one live connection per node, keyed by node id
public ImmutableDictionary<string, ZarisRemoteClient> Clients { get; init; }

// segment -> the active-owner client it routes to (the precomputed answer)
public ZarisRemoteClient?[] SegmentMap { get; init; }

// segment -> partition, and partition -> owning node id
public ushort[] SegmentToPartition { get; init; }
public ImmutableDictionary<int, string?> RuntimeOwners { get; init; }

Le choix de conception clé est SegmentMap. C'est un tableau, indexé par segment, dont les entrées sont déjà résolues vers la connexion du propriétaire de ce segment. Router une clé n'est pas un parcours de graphe de segment à partition à nœud à connexion au moment de la requête — cette résolution est faite à l'avance quand la table est construite, de sorte que le coût par requête est un seul index de tableau :

internal ZarisRemoteClient GetClientForKey(string key)
{
    var table = _routing;
    return GetClientForSegment(
        SegmentMapper.ComputeSegmentId(key, table.TotalSegments),
        table);
}

private static ZarisRemoteClient GetClientForSegment(ushort segment, RoutingTable table)
{
    if (segment >= table.SegmentMap.Length)
        throw new InvalidOperationException($"No client mapped for segment {segment} — map may be mid-update, retry");

    if (table.SegmentMap[segment] is not { } client)
    {
        var partitionId = segment < table.SegmentToPartition.Length
            ? table.SegmentToPartition[segment] : -1;
        throw new PartitionUnavailableException(partitionId, segment);
    }
    return client;
}

Clients détient exactement un ZarisRemoteClient — une connexion — par nœud. Le client n'ouvre pas une socket fraîche par requête ou par clé ; il multiplexe tout le trafic d'un nœud sur l'unique connexion de ce nœud, et SegmentMap pointe simplement de nombreux segments vers le même objet de connexion (l'égalité de référence les déduplique quand le client a besoin de l'ensemble distinct des propriétaires actifs, par exemple pour éventailler un scan). Donc le coût mémoire de la conscience des partitions est d'une connexion par nœud plus quelques tableaux dimensionnés au nombre de segments — il ne croît pas avec le nombre de clés ou de requêtes.

Le bénéfice est qu'il n'y a aucun nœud dans le cluster dont le travail est de recevoir des requêtes mal routées et de les relayer. Chaque requête bien routée est servie par le premier nœud qu'elle atteint. Cela retire tout un étage du budget de latence et, tout aussi important, de la surface de défaillance — vous ne pouvez pas perdre une requête dans un saut de relais qui n'existe pas. (La pièce compagnon sur le plancher de latence parcourt ce qui reste dans le budget une fois le saut de proxy parti.)

Étape 3 — la map bouge sous vos pieds​

Voici la partie difficile. La table de routage est un cache d'un fait — « le segment S est possédé par le nœud N » — que le cluster peut changer à tout moment. Un propriétaire peut tomber et un réplica est promu ; une partition peut être migrée pour faire grandir ou drainer un nœud. À l'instant où cela arrive, le SegmentMap[S] du client pointe vers une connexion qui n'est plus le propriétaire. Un client qui ferait aveuglément confiance à sa table enverrait des écritures à un nœud qui les refusera correctement.

Zaris garde la table honnête de trois façons, par ordre de préférence.

Push — le serveur prévient le client. Quand la possession change, le cluster émet un RuntimeOwnershipChangedEvent, et le client a un handler abonné dessus :

public Task HandleAsync(IServerEvent @event)
{
    if (@event is RuntimeOwnershipChangedEvent runtimeEvent)
        _router.TryUpdateRuntimeOwnership(runtimeEvent);
    return Task.CompletedTask;
}

TryUpdateRuntimeOwnership ne reconstruit pas toute la table. Il clone le tableau SegmentMap, repointe seulement les segments dont la partition a réellement changé de propriétaire, et échange la table immuable en place par une seule assignation de référence. Les lecteurs ne voient jamais une table à moitié mise à jour — ils lisent soit l'ancienne soit la nouvelle, jamais un mélange déchiré. C'est du routage copy-on-write : le cas courant (rien n'a changé) ne coûte rien, et un changement ne touche que les segments affectés.

Poll — un garde-fou lent. Un timer rafraîchit la map du cluster toutes les dix secondes quoi qu'il arrive, de sorte que même si un événement push est manqué (une reconnexion, une notification perdue), la vue du client s'auto-répare en un intervalle :

private readonly TimeSpan _pollInterval = TimeSpan.FromSeconds(10);

React — la requête elle-même corrige la map. La dernière ligne de défense est la requête qui route mal. Si le client envoie à un nœud qui n'est plus le propriétaire, le nœud ne la relaie pas silencieusement — il renvoie un statut qui dit au client que sa map est périmée, et le helper de réessai rafraîchit et réessaie :

private static bool RequiresMapRefresh(KvStatus status)
    => status == KvStatus.Moved
       || status == KvStatus.ReplicaWriteRejected
       // Ownership is mid-handoff: the client must force-fetch the updated
       // ownership and retry against the node that now owns the segment.
       || status == KvStatus.OwnershipChanging;

Quand une op réessayable revient Moved, OwnershipChanging ou ReplicaWriteRejected, le client appelle son hook de rafraîchissement et réessaie — une boucle bornée de quelques tentatives avec un bref backoff, pas une rotation sans fin. Il y a une leçon subtile cuite dans le code actuel ici : une version antérieure rafraîchissait la map à chaque tentative de réessai, ce qui, sous un fort churn de nœuds, transformait une seule op défaillante en des dizaines de rafraîchissements tous sérialisés derrière un verrou. La correction a été de ne rafraîchir que lorsque le statut dit réellement « votre map est fausse », pas simplement parce qu'une tentative a échoué. Le traitement plus profond de cette discipline de réessai a son propre article — les réessais sous churn de possession — mais la version en une ligne est : une map périmée est une condition qui se corrige d'elle-même, et la correction est bon marché précisément parce qu'elle est rare et ciblée.

Les trois mécanismes se superposent : le push rend le cas courant instantané, le poll rend un push manqué consistant à terme, et le réessai réactif rend toute obsolescence résiduelle invisible à votre appel — il prend juste un aller-retour supplémentaire à l'instant où la possession a bougé, et est correct dès l'appel suivant.

Pourquoi le faire côté client du tout ?​

Le routage conscient des partitions côté client coûte quelque chose. Le client doit porter un modèle du cluster, le garder frais, et expédier la même logique de placement qu'utilise le serveur. Une conception fondée sur un proxy pousse tout cela dans le cluster et laisse le client rester bête. Alors pourquoi payer ?

Parce que l'alternative paie à chaque requête, à jamais. Un proxy ou une conception « envoyez n'importe où, on le relaiera » ajoute un saut au chemin chaud de chaque opération — un saut qui est pure surcharge, présent même quand rien n'a échoué et rien ne bouge. Zaris paie le coût du routage une fois, d'avance, et seulement à nouveau quand la possession change réellement — ce qui, dans un cluster sain, n'arrive presque jamais. Le régime permanent est un index de tableau et une écriture de socket vers le bon nœud. C'est toute la raison pour laquelle les lectures montent avec vos cœurs au lieu de goulotter sur un étage intermédiaire : il n'y a pas d'étage intermédiaire sur quoi goulotter.

Et cela se compose avec tout le reste. La même résolution GetClientForKey est ce par quoi une surveillance de clé, un incrément de compteur, un compare-and-swap et une opération de structure de données à clé unique routent tous, donc ils héritent tous de la livraison directe au propriétaire et de la même map auto-réparante. Le client n'est pas un tuyau bête avec du routage boulonné dessus ; le routage est ce qu'est le client.

Les compromis honnêtes​

Le routage direct au propriétaire n'est pas sans bords, et il vaut la peine de les nommer.

• Le client doit atteindre chaque nœud. Parce qu'il n'y a pas de proxy, le client ouvre une connexion vers chaque nœud vers lequel il route. Dans un réseau plat c'est un non-problème ; à travers une frontière — disons un client hors de Kubernetes — ces nœuds doivent être adressables individuellement. C'est exactement le problème que l'adressage de client externe existe pour résoudre, et c'est une conséquence directe de l'absence de porte d'entrée unique.
• Un bref retard de map est possible, pas une perte. Dans la fenêtre entre le déplacement de la possession et le moment où le client l'apprend, une requête peut router vers l'ancien propriétaire. Elle est rejetée et réessayée, pas mal appliquée — le chemin réactif ci-dessus garantit que le réessai atterrit sur le vrai propriétaire. Vous payez un aller-retour, pas une mauvaise réponse.
• La fonction de placement est un contrat de compatibilité. Parce que le client et le serveur partagent SegmentMapper, vous ne pouvez pas changer la façon dont les clés hachent vers les segments sans que les deux côtés s'accordent — ce qui est précisément pourquoi le hachage a été aligné sur le modèle de slot Redis stable plutôt que sur un schéma interne qui pourrait dériver.

Dit simplement : le client Zaris sait où vivent vos clés, garde ce savoir à jour sans que vous y pensiez, et dépense un saut réseau — celui qui fait réellement le travail — à chaque opération. L'habileté n'est pas dans le chemin rapide, qui est délibérément ennuyeux. Elle est dans les trois mécanismes discrets qui gardent le chemin rapide correct pendant que le cluster se remodèle en dessous.

Un basculement couvre le moment où un propriétaire meurt : le cluster choisit un survivant et continue de servir. Une migration planifiée couvre le déplacement à dessein de la partition d'un propriétaire sain. Cet article porte sur le troisième acte, celui qui se joue après que les sirènes se taisent — le processus propriétaire d'origine redémarre, rejoint le cluster, et veut récupérer sa partition. Son store rien-sur-disque, tout-en-mémoire est revenu vide. Les données dont il est responsable sont toujours vivantes, mais elles sont vivantes sur les réplicas qui ont continué de servir pendant qu'il était à terre.

Tout le problème de correction tient en une phrase : le propriétaire redémarré ne peut pas être autorisé à faire confiance à sa propre vacuité. Un store vide ressemble exactement à un store que quelqu'un a délibérément vidé. Si le nœud suppose « je suis le propriétaire et je n'ai pas de données, donc cette partition est vide », il servira joyeusement NotFound pour des millions de clés vivantes et, pire, laissera son état vide refluer sur les réplicas et les supprimer. Cet article parcourt les cinq petites politiques pures que Zaris utilise pour s'assurer que cela n'arrive jamais.

Pourquoi la vacuité est indécidable de l'intérieur​

Commençons par le piège, car chaque règle ci-dessous en est façonnée. Un nœud qui démarre en détenant zéro enregistrement pour un segment qu'il possède est dans l'un de deux états, et il ne peut pas dire lequel à partir de la seule information locale :

1. Il est vide parce qu'il vient de redémarrer et n'a jamais retiré ses données. Il doit les retirer.
2. Il est vide parce qu'il a autoritairement vidé ou expiré ces clés, et un réplica qui était brièvement à terre détient encore les copies périmées. S'il retire, il ressuscite des données supprimées.

Ces deux cas sont localement indiscernables — le store est vide dans les deux cas. Une version antérieure de Zaris a tenté de résoudre cela avec un signal d'anomalie EmptyActive et il a été retiré précisément parce que le signal est une supposition. Vous ne pouvez pas demander « suis-je vide pour une bonne raison ? » et obtenir une réponse digne de confiance du nœud vide.

Donc Zaris ne demande rien à la vacuité. Il route la décision à travers un autre fait : un drapeau collant, au niveau de la partition, appelé certified, qui signifie exactement « ma synchronisation de démarrage s'est terminée et mon store fait maintenant autorité ». Un nœud ne le fixe qu'après avoir prouvé la possession. Un propriétaire fraîchement redémarré est, par définition, non certifié — et un propriétaire non certifié n'a aucune autorité à être vide. Il doit retirer les données de quiconque les détient. Un propriétaire certifié fait autorité et est laissé strictement tranquille, de sorte qu'un vidage légitime n'est jamais ressuscité.

Ce seul recadrage — de la vacuité (indécidable) à la certification (un fait prouvé et collant) — est ce qui rend le reste de la récupération sûr.

Étape 1 — le propriétaire redémarré retire, au lieu de supposer​

Quand le nœud rejoint, la map l'assigne toujours comme propriétaire de son ancienne partition. Le déclencheur de reverse-sync décide si chaque segment possédé doit être retiré d'un réplica vivant plutôt que traité comme localement autoritaire :

public static bool ShouldReverseSyncOwnedSegment(
    bool partitionCertified,
    bool isMapPreferredPrimary,
    bool liveNonSelfReplicaExists)
    => !partitionCertified && liveNonSelfReplicaExists;

Trois choses à propos de ce petit prédicat sont porteuses, et chacune est un bug qui a atteint une exécution de certification avant que la règle ne soit écrite.

Il ignore isMapPreferredPrimary. Ce paramètre est toujours passé — comme contexte de décision documenté — mais la décision ne le lit délibérément pas. Une version antérieure ne déclenchait le reverse-sync que lorsque le nœud était aussi le primaire préféré de la map. Un nœud qui est l'actif à l'exécution mais pas le primaire de la map — l'état exact dans lequel atterrit un propriétaire re-domicilié ou promu-après-récupération — voyait ses segments possédés entièrement sautés. Il ne demandait jamais ses données et restait vide à jamais pendant qu'un réplica vivant détenait chaque enregistrement (une exécution de cert : actif détenant 0 contre réplica détenant 4600 sur quinze segments, jamais convergé en huit minutes). La possession du retrait de données ne peut pas être conditionnée au fait d'être le primaire préféré ; elle doit se déclencher pour tout actif non certifié.

Le signal est !partitionCertified, pas la vacuité. C'est la correction d'indécidabilité de la section précédente, en code. Un actif non certifié n'a jamais prouvé la possession, donc il retire ; un certifié fait autorité et est sauté.

liveNonSelfReplicaExists est une garde, pas une gentillesse. Si le réplica configuré est à terre, il n'y a rien à partir de quoi synchroniser. Piloter la récupération contre une source morte tourne à jamais (RECOVERY STUCK source=self synced=0/128). Donc quand aucun réplica vivant n'existe, l'actif est la seule copie survivante — il est l'autorité, et il certifie immédiatement plutôt que d'attendre une source qui ne répondra jamais. Le retrait lui-même est borné par révision et par filigrane (watermark), ce qui en fait un no-op inoffensif quand le réplica ne détient rien.

Étape 2 — ne servez pas une clé que vous n'avez pas encore rattrapée​

Le retrait n'est pas instantané, et la fenêtre pendant qu'il s'exécute est là où les lectures acquittées se transforment discrètement en NotFound. Une barrière naïve est un unique booléen, IsSynced, signifiant « une passe de synchronisation s'est terminée ». Ce booléen ne suffit pas, et trois échecs de cert distincts l'ont prouvé : un actif en train de reprendre a promu avec 34 clés en moins ; une transmission a perdu une clé acquittée ; un actif qui rejoignait a servi NotFound pour 57 clés pendant le churn. Dans chaque cas une passe de synchronisation s'était terminée — mais la source (l'actif temporaire qui a continué de servir) avait depuis accepté davantage d'écritures que le nœud en récupération n'avait pas retirées. IsSynced était vrai et le nœud était toujours en retard.

La correction est de conditionner à une position, pas à un drapeau. La révision de l'op-log est un nombre répliqué et comparable entre nœuds : l'actif l'assigne et l'expédie, de sorte qu'un réplica rattrapé converge vers la même tête. La barrière de service compare les têtes :

public static SegmentServeDecision Decide(bool isSynced, long localHeadRevision, long sourceHeadRevision)
{
    if (!isSynced)
        return SegmentServeDecision.HoldUnsynced;

    // A watermark of 0 carries no information — do not block on it; trust the completed sync pass.
    if (sourceHeadRevision > 0 && localHeadRevision < sourceHeadRevision)
        return SegmentServeDecision.HoldBehindSource;

    return SegmentServeDecision.Serve;
}

HoldBehindSource est le nouvel état qui compte : une passe de synchronisation s'est terminée, mais la tête de la source (capturée à cette synchronisation) est en avance sur la nôtre, donc la source a accepté des écritures que nous n'avons pas retirées. Servir maintenant renverrait NotFound pour exactement ces clés. Le nœud patiente jusqu'à ce que sa tête locale atteigne le filigrane. Notez la dégradation délibérée : un filigrane enregistré de 0 signifie « pas d'information de filigrane », et la barrière retombe sur le comportement basé sur le seul IsSynced plutôt que de bloquer à jamais sur une donnée manquante. La règle ne bloque jamais sur l'absence d'un fait — seulement sur un fait qui dit vous êtes en retard.

Étape 3 — retirez, mais n'écrasez pas​

Maintenant la direction dangereuse : appliquer le snapshot que le réplica renvoie. L'instinct est de vider le store local et de copier le snapshot en bloc. Cet instinct est correct exactement la moitié du temps, et catastrophiquement faux l'autre moitié. La question décisive est dont les révisions sont comparables à celles de qui :

public static ResyncApplyMode Decide(
    bool digestMatches,
    bool isPassiveSubordinateReplica,
    bool priorReconcileShortfall = false)
    => digestMatches
        ? ResyncApplyMode.Skip
        : (isPassiveSubordinateReplica && !priorReconcileShortfall)
            ? ResyncApplyMode.Reconcile
            : ResyncApplyMode.Wipe;

Trois issues :

• Skip — les digests de contenu correspondent déjà. Rien à transférer, rien à appliquer. (Voir le protocole de cut-over pour savoir pourquoi un digest de contenu, pas un décompte de révisions, est la chose qui vaut d'être comparée.)
• Reconcile (non destructif) — le nœud local est un pur subordonné passif de l'unique actif vivant. Ses révisions par clé viennent toutes de ce seul actif, donc elles sont directement comparables. Le snapshot est fusionné borné par révision : un PutRaw garde l'enregistrement localement plus récent et comble les clés manquantes ; les pierres tombales s'appliquent via DeleteRaw. Crucialement, cela préserve les écritures que le réplica a accumulées par le canal vivant pendant un bootstrap lent au lieu de les jeter en vidant d'abord.
• Wipe (vidage destructif + copie) — le nœud local est ou a été lui-même un actif pour cette partition. Deux nœuds indépendamment actifs ont des révisions par clé incomparables : le même numéro de révision sur chacun se réfère à des écritures différentes. Les fusionner entrelacerait silencieusement deux historiques. Donc la seule manœuvre sûre est de déposer l'état local et d'adopter le snapshot faisant autorité en bloc.

Le défaut est la copie destructive sûre ; Reconcile n'est débloqué que en prouvant que le nœud est un subordonné purement passif. C'est la « wipe-guard » : elle empêche la fusion dangereuse entre deux anciens actifs, et symétriquement elle empêche un vidage en bloc de jeter de bonnes écritures du canal vivant sur un simple réplica.

Il y a une ride de plus encodée dans priorReconcileShortfall, et elle vient directement d'un abandon de certification sur douze heures. Une réconciliation bornée par révision peut clôturer dehors (fence out) des enregistrements qu'elle aurait dû appliquer et se terminer tout en restant derrière le snapshot faisant autorité — un segment bloqué à 12643/15435 sur 232 sessions de synchronisation, réconciliant les mêmes enregistrements hors de la fenêtre à chaque fois, bouclant à jamais. Le drapeau dit : si une réconciliation précédente s'est terminée mais nous a laissés en déficit, cesser de réconcilier et escalader vers un wipe pour que le snapshot gelé soit adopté en entier et que nous convergions réellement. Il n'est jamais fixé qu'après un déficit mesuré — un réplica en avance ou à égalité ne le déclenche jamais, donc les écritures du canal vivant ne sont jamais jetées pour poursuivre un fantôme.

Étape 4 — l'autre côté : un propriétaire non certifié peut quand même être une bonne source​

La récupération ne concerne pas seulement le nœud qui est en retard. Considérez le cas miroir : le nœud A redémarre, et le nœud B — un réplica qui était à terre — veut maintenant synchroniser depuis A. A devrait-il servir la requête alors que A est lui-même encore non certifié ?

La garde naïve dit non : « non certifié signifie que mon store est vide, donc servir écraserait les données valides de B avec mon trou ». Mais cette prémisse est fausse à l'instant où A détient réellement la copie faisant autorité — ce qui arrive de deux façons : A était un primaire préféré qui a vérifié le rattrapage avant la promotion mais dont le chemin de promotion n'a jamais appelé CertifyPartition (donc le drapeau collant reste coincé à faux alors que les données sont toutes là), ou A a pris la possession via une récupération de défaillance totale de partition et détient les données complètes comme actif sans jamais avoir été estampillé IsSynced. Dans les deux cas, la copie de A est la source de vérité, et refuser a laissé le réplica bloqué à zéro (un relevé : 1 792 requêtes refusées ; un autre : les 128 segments refusés pour toute une partition).

Donc la garde côté source est rendue consciente des données :

public static bool ShouldRefuse(
    bool selfIsRuntimeOwnerMapPrimary,
    bool partitionCertified,
    bool segmentSynced,
    bool selfHoldsSegmentData)
    => selfIsRuntimeOwnerMapPrimary && !partitionCertified && !segmentSynced && !selfHoldsSegmentData;

Refuser de servir seulement quand le nœud est le propriétaire, est non certifié, et que le segment est à la fois non synchronisé et ne détient aucune donnée — le seul cas véritable « en pleine récupération et réellement vide » où servir un trou pourrait laisser le demandeur se certifier contre lui. Parce que le récepteur applique chaque chunk borné par révision, servir des données réelles est toujours sûr ; la garde réduit le refus au seul état où il n'y a rien de sûr à servir.

Étape 5 — déclarer victoire, exactement une fois​

Enfin l'actif en récupération a retiré chaque segment possédé et a rattrapé chacun jusqu'à la tête de sa source. Il fait à nouveau autorité, et il a besoin de le dire — basculer le drapeau certifié collant — pour que le déclencheur de reverse-sync de l'Étape 1 cesse de re-céder ses segments et que le cluster enregistre la partition comme convergée.

public static bool ShouldCertify(
    bool selfIsRuntimeActive,
    bool partitionCertified,
    int ownedSegmentCount,
    int syncedSegmentCount)
    => selfIsRuntimeActive
       && !partitionCertified
       && ownedSegmentCount > 0
       && syncedSegmentCount >= ownedSegmentCount;

La certification est le pendant symétrique du déclencheur : le déclencheur met en file les segments d'un actif non certifié à retirer ; celui-ci bascule le drapeau une fois que chaque segment possédé est synchronisé, et la partition se stabilise. Le chemin de certification préexistant ne s'exécutait que pour le primaire préféré de la map, donc un actif re-domicilié non-primaire retirait toutes ses données correctement puis ne certifiait jamais — il re-mettait en file le reverse-sync à jamais, et le cluster ne s'enregistrait jamais comme convergé (une exécution : 30 points de contrôle expirant ~106 secondes après le début, alors que Missing=0 et que les décomptes ne divergeaient jamais — les données étaient justes, seule la stabilisation manquait).

Et notez le seul raccourci que cette politique refuse délibérément : il n'y a pas de chemin « pas de réplica vivant, donc certifie ma vacuité comme autorité » pour un actif non-primaire. Un actif non-primaire n'est pas l'autorité de la map ; le certifier vide alors qu'un réplica temporairement à terre détient encore les données laisserait ce réplica plus tard synchroniser depuis ce nœud vide et tout perdre. Le raccourci de l'autorité-à-être-vide n'appartient qu'au primaire préféré de la map, dans son propre chemin de réconciliation. Partout ailleurs, la vacuité ne gagne rien.

La forme de l'ensemble​

Prenez du recul et les cinq politiques sont une seule idée appliquée en cinq endroits : la possession est prouvée, jamais supposée.

• Un propriétaire redémarré est non certifié, donc il retire au lieu de faire confiance à son store vide (Étape 1).
• Il ne servira pas un segment tant que la tête de son op-log n'aura pas atteint celle de la source — une passe de synchronisation terminée n'est pas la même chose qu'être rattrapé (Étape 2).
• Il fusionne plutôt que d'écraser quand les révisions sont comparables, et écrase plutôt qu'entrelace quand elles ne le sont pas (Étape 3).
• En tant que source, il sert chaque fois qu'il détient véritablement les données, et ne refuse que lorsqu'il est réellement vide en pleine récupération (Étape 4).
• Il certifie — bascule le drapeau collant d'autorité — seulement sur preuve que chaque segment possédé est synchronisé, sans raccourci de vacuité-comme-autorité pour un non-primaire (Étape 5).

Chacune de ces règles est un prédicat pur et sans E/S — une poignée de booléens et deux numéros de révision en entrée, une décision en sortie — ce qui est pourquoi elles sont testables unitairement en isolation et pourquoi chacune a pu être épinglée à l'échec de certification exact qui l'a motivée. Elles sont la vue de l'intérieur de l'invariant que la certification du chaos sur douze heures prouve depuis l'extérieur : tuer un propriétaire en plein vol, laisser ses réplicas porter la charge, le ramener, et regarder Missing=0 tenir sur des millions d'opérations acquittées. La raison pour laquelle le redémarrage ne perd pas une écriture est que le propriétaire de retour n'est jamais une seule fois autorisé à croire sa propre vacuité. Il doit regagner ses données — des réplicas qui les ont gardées en sécurité.

Si vous voulez les pièces sur lesquelles ceci s'appuie : l'op-log rejouable est ce qui fait de « rattraper ma tête jusqu'à la tête de la source » une opération réelle et sans trou, et lire vos propres écritures est la promesse côté client que la barrière de service de l'Étape 2 existe pour tenir.

La plupart des écrits sur les stores distribués traitent du régime permanent — lectures, écritures, réplication — ou des défaillances spectaculaires : un basculement quand un propriétaire meurt, un cut-over quand une partition se déplace. Mais il existe un moment plus discret qui décide si tout cela fonctionne : le moment où le cluster démarre. Avant qu'une seule clé puisse être routée, les nœuds doivent s'accorder sur qui fait partie du cluster, qui possède quelle tranche du keyspace et — l'étape que la plupart des systèmes ratent — s'il est seulement sûr de commencer à servir.

Cet article suit cette séquence de démarrage dans l'ordre où Zaris l'exécute réellement : l'appartenance, la partition map, et les barrières de disponibilité qui se dressent entre « le processus est lancé » et « le nœud prend du trafic ». Il trace aussi, honnêtement, une ligne autour de ce que Zaris implémente lui-même par rapport à ce qu'il hérite du runtime de cluster sous-jacent sur lequel il est construit.

Qui fait partie du cluster : l'appartenance​

La première chose honnête à dire est où se situe la frontière. Le transport d'appartenance de bas niveau — heartbeats entre pairs, détection de défaillance et élection du leader — est fourni par la couche Clustron.Nodus sur laquelle Zaris est construit. Zaris la consomme via une interface INodusNode : il demande à Nodus qui sont les membres, lequel détient le leadership, et il est notifié quand le heartbeat d'un pair est manqué ou échoue. Zaris ne réimplémente pas Raft ni un protocole de découverte par gossip ; il superpose son propre plan de contrôle de partition et de possession par-dessus ce socle.

Ce que Zaris ajoute, c'est une machine à états d'appartenance explicite qui traduit les événements bruts de heartbeat en décisions pertinentes pour la possession. Elle vit dans MembershipStateTracker, et ses états sont délibérément plus nuancés que « actif / inactif » :

Les états se répartissent en deux groupes, et cette division est tout l'enjeu. Alive, Suspected et Unreachable n'affectent que la possession à l'exécution — ils peuvent déclencher la promotion d'un réplica ou marquer une partition temporairement indisponible, mais ils ne modifient jamais la partition map. Seuls Lost, Evicted et Decommissioned rendent un nœud éligible à la régénération de la map.

Cette distinction existe parce que régénérer la partition map coûte cher et, fait trop hâtivement, est dangereux — cela peut rebrasser inutilement des partitions saines. Donc quand le heartbeat d'un nœud échoue, Zaris ne réécrit pas immédiatement la map. Il fait passer le nœud en Unreachable et démarre une fenêtre de grâce (30 secondes par défaut). Pendant cette fenêtre, le cluster ne fait que du basculement à l'exécution — promouvoir un réplica pour que lectures et écritures continuent de circuler — tout en laissant au nœud une chance de revenir. Un flapping, une pause de GC, un bref hoquet réseau : rien de tout cela ne devrait réécrire la possession. Ce n'est que si la fenêtre de grâce expire que le nœud passe à Lost, et ce n'est que lorsqu'un groupe de partition entier a été évincé que l'unique chemin de régénération de map piloté par la défaillance se déclenche. La règle de conception, énoncée sans détour dans le code qui l'assemble, est : un nœud qui part ne régénère jamais la map à lui seul.

Comment les nœuds se trouvent​

La découverte est fondée sur un registre, pas sur une découverte par gossip. La liste faisant autorité des nœuds est de la configuration, pas quelque chose que le cluster renifle à l'exécution. Dans une configuration écrite à la main, c'est le tableau nodes — chaque entrée déclarant un id, un hôte, un port de cluster (pair) et un port client. Sur Kubernetes, ce registre est synthétisé à partir des ordinaux de pod du StatefulSet plutôt que maintenu à la main, le rôle de primaire préféré d'un nœud étant dérivé directement de son ordinal.

Il existe bien un mécanisme de gossip dans Zaris, mais il fait un autre travail — c'est ainsi que les nœuds maintiennent leur vue de l'état du cluster convergée, pas ainsi qu'ils découvrent que des pairs existent. Nous y reviendrons quand nous parlerons de disponibilité.

Qui possède quoi : la partition map​

Une fois l'appartenance connue, le cluster a besoin d'un plan pour le keyspace. Ce plan, c'est la partition map — un document unique et versionné contre lequel chaque nœud route.

D'une clé à un propriétaire, en deux sauts​

Une clé ne se mappe pas directement à une partition. Zaris utilise un mapping à deux niveaux délibérément aligné octet pour octet avec Redis Cluster afin que la même arithmétique de routage fonctionne aussi bien pour les clients natifs que pour le front-end RESP :

key --CRC16--> slot (0..16383) --proportional--> segment (0..255) --SegmentToPartition[]--> partition

Le premier saut hache la clé avec CRC16 (CCITT/XMODEM, polynôme 0x1021) modulo 16384 — la fonction exacte qu'utilise Redis Cluster, y compris le respect de la co-localisation par hash-tag, où une clé écrite user:{42}:profile ne hache que la portion entre accolades afin que les clés apparentées atterrissent ensemble. Les 16384 slots sont ensuite mappés proportionnellement sur les segments du cluster — 256 par défaut, fixés pour la durée de vie du cluster — et une table SegmentToPartition affecte chaque segment à une partition. La partition, enfin, est ce qui a des propriétaires.

Pourquoi cette couche de segment supplémentaire plutôt que de hacher directement vers les partitions ? Parce que les segments sont une unité stable et à grain fin que l'on peut déplacer entre partitions quand le cluster grandit ou se rééquilibre, sans re-hacher chaque clé. L'étape CRC16-vers-slot ne change jamais ; seule l'affectation segment-vers-partition change.

Ce que contient une partition map​

La map elle-même est un PartitionMap — un enregistrement sérialisé en MessagePack dont la forme révèle avec quel soin la possession est suivie. Les champs qui valent d'être connus :

• Version — un compteur monotone qui s'incrémente à chaque changement de map. C'est le nombre qui rend le commit sûr (plus de détails ci-dessous).
• TopologyVersion — ne s'incrémente que lors d'un véritable changement structurel (un nœud ou une partition qui rejoint ou quitte, un re-découpage), pas lors d'un cut-over de migration de routine. Séparer « la forme a changé » de « un propriétaire a changé » laisse le reste du système réagir proportionnellement.
• TotalSegments — 256 par défaut, constant pour la vie du cluster.
• Partitions — la liste des affectations, chacune portant un PrimaryNodeId (le primaire de placement), des ReplicaNodeIds, et une PartitionIdentity stable (un GUID frappé à la naissance qui survit à un renumérotage) plus les champs de bail de possession : ActiveOwnerNodeId, une OwnershipGeneration frappée par le leader, et le LeaderTerm qui a accordé le bail — ce qui permet au cluster de clôturer un ex-leader périmé hors de la rédaction de la possession.

Notez la scission délibérée entre PrimaryNodeId (où la map préfère qu'une partition réside) et ActiveOwnerNodeId (qui la sert réellement en ce moment). Ces deux peuvent différer pendant un basculement ou une migration, et les garder comme des champs distincts est ce qui rend ces transitions représentables sans mentir sur le plan de régime permanent. L'article sur le modèle de cohérence explique pourquoi les lectures routent vers cet unique propriétaire actif.

Comment la map est planifiée​

La map n'est pas assemblée de façon gloutonne. Elle est produite par un planificateur pur et déterministe — DesiredMapPlanner — qui prend les ids des nœuds membres, le nombre de segments, un nombre de partitions souhaité et le facteur de réplication, et renvoie un plan. Deux propriétés valent d'être soulignées :

1. Des découpages de segments équilibrés et contigus. Les segments sont divisés aussi uniformément que possible, en plages contiguës, les premières partitions absorbant le reste quand la division n'est pas nette.
2. Un placement en groupes disjoints. Les N premiers membres deviennent les primaires distincts des partitions ; les membres restants remplissent les emplacements de réplica en round-robin, de sorte qu'aucun nœud ne se retrouve dans deux groupes de partition différents.

La raison pour laquelle le planificateur est écrit comme une fonction pure de ses entrées est chèrement acquise : cela rend toute une classe de maps défectueuses — une partition avec un primaire en double, une plage de segments non contiguë, une affectation dégénérée — irreprésentables par construction, plutôt que quelque chose que l'on rattrape après coup avec un validateur. Il vaut aussi la peine d'être honnête sur la limite actuelle : le placement d'aujourd'hui est positionnel et en groupes disjoints ; un placement de style rendezvous minimisant le churn, qui déplace le moins de données possible à chaque régénération, est un raffinement futur explicite, pas quelque chose de livré. Ce qui est livré, c'est une étape de placement collant qui, lors d'une régénération due au churn d'appartenance, maintient en place un propriétaire vivant qui sert, afin qu'une partition saine ne soit pas déplacée sans raison.

Ce que « commit » signifie​

La map est rédigée par un seul nœud — le leader du plan de contrôle — et personne d'autre. Le leader génère une map candidate, la fait passer par une projection du log de possession (le leader est l'unique rédacteur du log de possession, et la map servie est un repli de ce log), puis la valide localement avant d'en informer qui que ce soit. Le commit est une règle unique et stricte imposée dans TopologyManager.ApplyMap :

// A map is accepted only if it is strictly newer.
if (_currentMap != null && map.Version <= _currentMap.Version)
    return false;

Une map dont la version est inférieure ou égale à celle que vous détenez déjà est rejetée, point final. Ce n'est qu'après que le leader a validé qu'il diffuse un MapChangedEvent, pousse des snapshots de map directs vers les pairs, et publie le changement de routage aux clients. Les suiveurs récupèrent la map (au démarrage à froid ils la demandent aux pairs déjà connus, en réessayant jusqu'à ce que l'un réponde) et l'appliquent via la même garde monotone. Parce que chaque nœud n'accepte jamais qu'une version strictement supérieure, deux nœuds ne peuvent jamais se fixer sur des maps conflictuelles de même version — le numéro de version est le point de sérialisation.

Une ride honnête au démarrage à froid : un nœud sans leader qui démarre seul peut frapper une map provisoire à un seul nœud pour ne pas rester dans l'impasse, marquée comme provisoire et plus tard remplacée par la map multi-nœuds faisant autorité une fois le cluster formé. C'est un confort de disponibilité, pas le chemin de régime permanent.

Est-il sûr de servir : la disponibilité conditionnée par la convergence​

Voici l'étape qui sépare un store auquel on peut se fier d'un store qui se contente de démarrer. Avoir un processus lancé, et même avoir une map, ne signifie pas qu'un nœud doive prendre du trafic. Si un nœud commence à servir avant que sa possession à l'exécution n'ait rattrapé la map qu'il vient d'appliquer, il peut router une requête vers une partition qu'il ne détient pas encore réellement. Zaris refuse de le faire, avec deux barrières distinctes.

Barrière un : la stabilité de la formation du cluster​

La première barrière décide quand le leader est autorisé à générer la première vraie map. ClusterReadinessGate attend que l'appartenance soit stable — au moins un nombre minimum de nœuds présents continûment pendant une fenêtre de durée de stabilité (3 secondes par défaut) — avant de valider une map. Cela empêche le leader de rédiger une map contre un cluster à moitié formé où les nœuds rejoignent encore un par un, ce qui signifierait une régénération immédiate une seconde plus tard. Si la stabilité n'est pas atteinte dans le délai imparti (30 secondes par défaut), la barrière force le bootstrap quand même : la disponibilité l'emporte sur une attente éternelle. Le cluster préfère démarrer légèrement en avance plutôt que de se bloquer.

Barrière deux : la barrière de trafic par nœud​

La seconde barrière est celle qui décide réellement si un nœud ouvre son listener client. ClusterTrafficReadinessGate.IsReady() ne renvoie vrai que lorsque toutes les conditions suivantes sont réunies :

• une map validée existe,
• sa table segment-vers-partition est entièrement peuplée (length == TotalSegments),
• une map de possession à l'exécution existe,
• runtime.MapVersion == map.Version — la possession à l'exécution du nœud est alignée sur la version exacte de la map qu'il a validée,
• et chaque partition a une entrée à l'exécution.

Cette quatrième condition en est le cœur. Un nœud ne s'annoncera pas comme prêt à servir tant que sa propre map validée et sa propre possession à l'exécution ne sont pas sur la même version. C'est ce que pointe l'image d'en-tête tout en haut. Il y a un garde-fou de 60 secondes pour qu'un nœud incapable de converger ne bloque pas le démarrage indéfiniment — passé ce délai il poursuit avec un avertissement plutôt que de se coincer — mais dans le cas normal, la barrière tient la porte jusqu'à ce que les deux plans concordent.

Rester convergé : digests et détection-réparation​

La disponibilité est une propriété de démarrage ; rester convergé est une propriété de régime permanent, et c'est là que le gossip de Zaris gagne vraiment sa place. Chaque heartbeat transporte un petit ClusterStateDigest — l'epoch du nœud, qui il pense être le leader, sa version de map, son nombre de nœuds, et les générations de possession par partition. Aucun RPC supplémentaire ; il voyage avec le trafic que le cluster envoie déjà.

Un DigestAccumulator collecte les digests des pairs et, toutes les quelques secondes, les compare. Si un nœud diverge de la majorité pendant deux cycles d'évaluation consécutifs, il lève un signal de dérive, et un HealingOrchestrator y réagit — le leader envoie des directives correctives (avec un délai d'apaisement pour qu'il ne s'emballe pas), et un nœud qui se retrouve l'unique cas isolé s'auto-répare en re-récupérant la map. C'est de la convergence par détection-réparation, pas par un vote de quorum avant de servir.

Cette distinction importe pour l'honnêteté, alors soyons précis. En production, l'accord sur la version de map à travers tout le cluster est maintenu par la barrière de trafic par nœud plus cette boucle de réparation pilotée par les digests — pas par une barrière globale qui bloque tout service tant que chaque nœud n'a pas voté sur une version. L'assertion plus forte — chaque snapshot de nœud s'accordant sur un seul leader, une seule epoch de leader et une seule version de map — est ce que le harnais de certification du chaos sur 12 heures vérifie en continu comme un invariant pass/fail. La certification prouve que la propriété tient ; le runtime l'atteint par barrière et réparation plutôt que par un tour de consensus bloquant sur le chemin de service.

Facteur de réplication, et une valeur par défaut honnête​

Une dernière pièce de l'histoire de la formation, car elle change ce que « prêt » signifie pour votre durabilité. Le facteur de réplication vaut 1 par défaut. Avec RF=1, chaque partition a un primaire et aucun réplica — une seule copie. Le planificateur place RF - 1 réplicas par partition, donc à la valeur par défaut c'est zéro. Un cluster à RF=1 se forme, converge et sert parfaitement bien, mais la perte d'un nœud est une perte de données pour les partitions qu'il possédait, par conception, pas par accident. Si vous voulez qu'une partition survive à une défaillance de nœud, vous mettez RF >= 2, et il vous faut assez de nœuds pour placer effectivement ces réplicas sur des machines distinctes — l'article sur le dimensionnement de durabilité Kubernetes détaille exactement combien de pods cela demande. Le nombre de partitions a une valeur par défaut tout aussi honnête : laissé non défini, le cluster utilise une partition par nœud.

La séquence, de bout en bout​

Mis bout à bout, un cluster Zaris démarre ainsi :

1. L'appartenance se résout à partir du registre de configuration (ou des ordinaux k8s), et Nodus élit un leader de plan de contrôle.
2. Le leader attend derrière la barrière de formation une appartenance stable, puis planifie une map avec DesiredMapPlanner et la valide localement sous la garde de version strictement monotone.
3. Le leader diffuse la map ; les suiveurs la récupèrent et l'appliquent sous la même garde, n'acceptant que des versions strictement supérieures.
4. Chaque nœud patiente derrière sa barrière de trafic jusqu'à ce que runtime.MapVersion == map.Version et que le routage soit entièrement peuplé — seulement alors il ouvre son listener client.
5. En régime permanent, les digests portés par les heartbeats maintiennent la vue de chaque nœud convergée, avec détection de dérive et réparation pilotée par le leader comblant tout écart.

Aucune de ces étapes n'est spectaculaire en soi. Ensemble, elles sont la différence entre un cluster qui tourne et un cluster qui est prêt — et l'écart entre ces deux mots est là où un store perd silencieusement des données s'il ne prend pas la question au sérieux.

Zaris est le store clé-valeur distribué de Clustron. Si vous voulez voir le plan de contrôle du côté de l'opérateur, la présentation PowerShell crée, démarre et inspecte un cluster en direct ; et la mise à l'échelle élastique couvre ce qui arrive à la map quand vous ajoutez un serveur à un cluster qui sert déjà.

Tôt ou tard, quelqu'un pose la question : nous avons un cluster dans une région et des utilisateurs dans une autre — ne peut-on pas simplement ajouter quelques nœuds là-bas et laisser un seul cluster couvrir les deux ? C'est un réflexe raisonnable. Un cluster, un espace de noms, une chaîne de connexion, des données partout. Ce réflexe est aussi un piège, et il vaut la peine d'être précis sur le pourquoi.

Un cluster Zaris est conçu pour un réseau de datacenter. L'appartenance est suivie avec des heartbeats sur des minuteries courtes. La possession d'une partition se déplace entre nœuds via une poignée de main qui suppose que l'autre côté répond vite. Le basculement clôture un propriétaire suspecté mort et promeut un réplica à l'échelle de quelques secondes. Chacun de ces mécanismes est calibré pour une liaison où l'aller-retour se mesure en microsecondes et où un nœud « lent » est véritablement malade — et non simplement à quatre-vingts millisecondes et un océan de distance. Mettez la moitié des nœuds de l'autre côté d'un WAN et vous n'avez pas construit un cluster géo-distribué ; vous avez construit un seul cluster qui prend désormais la latence WAN normale pour une défaillance, fait flapper la possession, et risque le split-brain au premier hoquet de la liaison entre régions.

La bonne forme n'est donc pas un seul cluster étiré. Ce sont deux clusters indépendants — chacun autonome, chacun gardant sa possession et son basculement entièrement sur son propre LAN — reliés par un change feed asynchrone et reprenable. Cet article porte sur ce motif : pourquoi l'indépendance est la décision porteuse, et comment le log d'opérations de Zaris vous remet déjà la seule chose dont un réplicateur WAN a réellement besoin — un curseur depuis lequel reprendre.

Pourquoi un cluster étiré est le mauvais outil​

Il est utile de nommer les hypothèses précises qu'un cluster unique formule, car chacune se brise différemment sur un WAN.

• L'appartenance fondée sur les heartbeats décide qu'un nœud a disparu quand il manque quelques battements. Une liaison inter-régions qui ajoute de la latence et la partition occasionnelle déclenchera ce détecteur en fonctionnement sain. Le cluster déclarera morts des nœuds vivants.
• Le protocole de possession déplace les partitions entre nœuds avec une poignée de main qui attend une réponse rapide. À travers un WAN, ces transitions calent, réessaient et se concurrencent — exactement le churn que la machinerie de possession et de cut-over est conçue pour résoudre rapidement sur un LAN.
• Les minuteries de basculement promeuvent un réplica quand le propriétaire semble mort. Sur un WAN, « semble mort » et « est juste très loin » deviennent indiscernables, d'où des promotions parasites — et si la liaison se rétablit avec un réplica promu de chaque côté, vous avez deux propriétaires pour une même partition.

Rien de tout cela n'est un défaut. C'est un store qui fait exactement ce qu'un store intra-datacenter à faible latence devrait faire, appliqué à un réseau qu'il n'a jamais été destiné à couvrir. La solution n'est pas de relâcher chaque minuterie jusqu'à ce que le cluster tolère un WAN — cela le rendrait aussi beaucoup trop lent à tolérer de vraies défaillances. La solution est de cesser de demander à un seul cluster de le faire.

La brique que vous possédez déjà : un log rejouable​

Zaris conserve, par segment, un log d'opérations ordonné par révision. Chaque écriture acceptée fait avancer une révision monotone et ajoute une entrée. Ce log est le substrat que les réplicas et les nouveaux propriétaires de partition utilisent pour se remettre à niveau sans geler les écritures : un consommateur qui connaît la dernière révision qu'il a vue peut rejouer en avant depuis ce point et converger vers la vérité courante.

Cette propriété — rejouer en avant depuis une révision connue — est tout le fondement d'un réplicateur WAN. Un change feed n'est rien de plus qu'un lecteur de longue durée de ce log qui diffuse les entrées dans l'ordre des révisions et se souvient de l'endroit où il s'est arrêté. Ce dont il se souvient est un curseur : la révision la plus haute qu'il a durablement appliquée, par segment.

Parce que le log est ordonné par révision et que la relecture démarre d'un point que vous choisissez, le feed possède les deux traits qu'exige une liaison WAN :

1. Reprenable. La liaison va tomber — c'est le fait qui définit un WAN. Quand elle revient, le suiveur se reconnecte et demande tout ce qui suit son curseur stocké. Pas de re-copie complète, pas de coordination, juste « reprendre à la révision N ».
2. Idempotent à la relecture. N'appliquez une entrée que lorsque sa révision est supérieure à la dernière appliquée pour ce segment. Si une reconnexion redélivre la queue, le suiveur saute ce qu'il possède déjà. La livraison en double devient un no-op, ce qui permet au feed d'être au-moins-une-fois au lieu de devoir être exactement-une-fois.

Le motif, de bout en bout​

Deux clusters. Appelons-les A (la source) et B (le suiveur). Chacun est un cluster Zaris ordinaire et indépendant qui ne sait rien des rouages internes de l'autre.

Dans le cluster B, vous exécutez un suiveur de réplication — un client qui consomme le change feed de A et écrit les opérations dans B localement. Son état est minuscule et durable : un curseur par segment. La boucle est sans gloire, ce qui est tout l'intérêt :

1. Se connecter à A, demander le change feed pour les segments (ou préfixes de clé) que vous voulez répliquer, en commençant après le curseur stocké de chaque segment.
2. Recevoir les entrées dans l'ordre des révisions. Pour chacune, appliquer l'opération à B — SET, DELETE, expiration — gardée par la vérification de révision afin que la redélivraison soit inoffensive.
3. Faire avancer et persister le curseur au fur et à mesure que les entrées sont durablement appliquées.
4. À toute déconnexion, revenir à l'étape 1. Le curseur est là où vous vous êtes arrêté.

Tout ce dont le suiveur a besoin pour survivre à une interruption vit dans ce curseur. Il n'y a pas de transaction distribuée à travers le WAN, pas d'appartenance partagée, pas de quorum inter-régions. Un hoquet sur la liaison ne vous coûte qu'un peu de fraîcheur.

Ce que vous échangez : le RPO n'est pas nul, et c'est le marché​

Cette réplication est asynchrone. Le suiveur est toujours à quelque distance derrière la source — autant de révisions produites dans A mais pas encore appliquées dans B. Cette distance est votre Objectif de point de récupération (Recovery Point Objective) : si la région A disparaît à l'instant, vous perdez tout ce qui n'avait pas encore atteint B.

Ce n'est pas un défaut dont il faut s'excuser ; c'est le compromis que vous choisissez explicitement. L'alternative — faire attendre aux écritures de A un accusé de réception de B avant de valider — mettrait un aller-retour WAN sur votre chemin d'écriture et abandonnerait la faible latence qui est toute la raison pour laquelle vous exécutez Zaris. La réplication inter-régions synchrone transforme chaque écriture en une requête transcontinentale. Presque personne n'en veut réellement une fois la facture de latence vue.

Le cadrage honnête est donc : vous choisissez le RPO. Un suiveur bien alimenté sur une liaison saine reste à quelques révisions près — une obsolescence inférieure à la seconde en pratique. Une liaison saturée ou qui flappe le laisse dériver davantage. Le curseur rend la dérive bornée et visible — vous pouvez mesurer exactement à quelle distance B est derrière en comparant son curseur à la révision courante de A — mais il ne la rend pas nulle. Dimensionnez votre tolérance en conséquence, et alertez sur le retard de curseur comme vous alerteriez sur le retard d'un réplica à l'intérieur d'un cluster.

Quand la source bascule, le feed s'en moque​

Voici où le fait de bâtir sur le log d'opérations paie une seconde fois. À l'intérieur du cluster A, la partition que lit votre feed changera occasionnellement de propriétaire — un nœud meurt, un réplica est promu, une partition migre. Le log survit à cela : il est indexé par révision, et un nouveau propriétaire poursuit la même séquence de révisions. Pour le suiveur, un basculement côté source n'est qu'une reconnexion de plus. Il rétablit le feed contre la topologie courante de A et reprend depuis son curseur. Les révisions qu'il a déjà appliquées sont toujours les révisions qu'il a déjà appliquées ; celles qui lui manquent sont toujours après le curseur. Le suiveur n'a jamais à comprendre qui, dans A, possède la partition — seulement quelle révision il a vue en dernier.

C'est la raison discrète pour laquelle la conception curseur-sur-log vaut plus qu'un relais naïf « lire la queue des écritures et les expédier ». Un relais qui diffuse les écritures en direct sans position durable indexée par révision n'a rien depuis quoi reprendre quand la topologie source change. Le log donne au suiveur un système de coordonnées stable qui survit à n'importe quel propriétaire individuel.

La portée est un choix, et les conflits sont une frontière​

Deux autres choses à décider délibérément.

Portée des données. Vous n'avez pas à tout répliquer. Le feed est par segment, et vous pouvez sélectionner les segments ou préfixes de clé qui comptent — un locataire spécifique, un jeu de données spécifique, la tranche dont une région de reprise après sinistre a réellement besoin. Répliquer moins signifie moins de trafic WAN et un suiveur plus petit ; répliquer tout vous donne un secours chaud complet. Décidez à dessein plutôt que par défaut.

Direction et conflits. Le motif ci-dessus est unidirectionnel : A est la source de vérité, B est un suiveur / secours majoritairement en lecture. C'est le cas propre, et il n'a pas de problème de conflit — il y a exactement un rédacteur par clé. Au moment où vous le rendez bidirectionnel — les deux régions acceptant des écritures pour les mêmes clés — vous avez introduit des rédacteurs concurrents séparés par un WAN, et aucune plomberie de change feed ne résout cela pour vous. Vous devez désormais une politique de résolution de conflits : last-writer-wins sur une horloge en laquelle vous avez confiance, possession par clé pour que les deux régions n'écrivent jamais la même clé, ou fusion au niveau applicatif. L'actif-actif est une conception réelle et parfois nécessaire, mais c'est une décision de modélisation des données, pas une fonctionnalité de transport. Optez d'abord pour l'unidirectionnel ; n'adoptez le bidirectionnel que lorsque vous avez décidé, explicitement, comment deux rédacteurs se réconcilient.

La forme à retenir​

Un WAN n'est pas un LAN lent ; c'est un médium différent où les partitions sont un événement normal plutôt qu'une urgence. Un cluster unique, à juste titre, refuse de prétendre le contraire — ses minuteries et son protocole de possession sont réglés pour traiter un long silence comme une défaillance, car à l'intérieur d'un datacenter c'en est presque toujours une. Donc vous n'étirez pas le cluster. Vous en exécutez deux, chacun souverain sur son propre réseau, et vous les reliez avec la seule primitive bâtie pour tolérer une liaison qui va et vient : un log ordonné par révision que vous pouvez rejouer, et un curseur qui se souvient d'où vous en étiez.

L'indépendance est la décision qui rend le reste sûr. Le change feed n'est que le tuyau. Le log d'opérations vous a déjà donné le curseur.

Voici un nombre qui recadre la façon dont vous pensez un store clé/valeur. Quand nous isolons le store en mémoire de Zaris et lui envoyons des opérations sans rien d'autre sur le chemin — pas de socket, pas de sérialisation, pas de routage — un seul thread sert les lectures à plus d'un million par seconde, et monte proprement à plus de huit millions sur huit threads. Le store, autrement dit, fait le travail réel d'un GET en moins de deux microsecondes, et il n'est emphatiquement pas le goulet d'étranglement.

Et pourtant un GET complet sur une vraie connexion TCP, sur la même machine, plafonne à quelques centaines de milliers par seconde. Le store peut faire le travail cinq fois plus vite que le serveur ne peut le délivrer. La question de performance intéressante au sujet de Zaris n'est donc pas « à quelle vitesse va le store ? ». C'est l'inverse : où part tout le temps entre la socket et le store ? Cet article en est la réponse, tracée opération par opération, car l'écart entre 1,7 microseconde de logique et 10 à 13 microsecondes de CPU serveur par opération n'est pas du bruit — c'est le plancher de latence, et il est presque entièrement de la plomberie.

La mesure qui lance toute l'enquête​

On ne peut pas optimiser un chemin qu'on n'a pas séparé en couches, donc la première chose que nous avons construite fut un ensemble de benchmarks d'ablation — des harnais qui dépouillent le système jusqu'à une couche à la fois.

• Store seul. Appeler directement le store en processus de la partition, en processus, sans réseau. Résultat : ~1,15M GET/s et ~0,5M PUT/s par thread, montant linéairement à ~8,2M / ~2,0M sur huit threads.
• Écho de socket nu. Une simple socket .NET faisant des trames de même forme, sans logique Zaris : ~7,2M trames/s sur la même machine.
• Chemin TCP natif complet. Le vrai client parlant au vrai serveur : ~300-324K ops/s, avec seulement environ trois cœurs logiques sur quatorze occupés de chaque côté.

Lisez ces trois résultats ensemble et deux suspects habituels s'écartent immédiatement. Le store n'est pas la limite — il est 3 à 4 fois plus rapide que le chemin complet. Le système d'exploitation et le loopback ne sont pas non plus la limite — une socket nue déplace des trames vingt fois plus vite. Ce qui reste au milieu, entre une socket qui peut faire des millions et un store qui peut faire des millions, c'est la plomberie de requête propre à Zaris, et elle dépense environ 10 à 13 microsecondes de CPU serveur par opération pour envelopper environ 1,7 microseconde de travail réel.

Ce ratio est le sujet. Suivons un GET à travers lui.

Le chemin d'un seul GET​

Rien dans ce diagramme n'est faux ou gaspilleur au premier regard — c'est la forme honnête d'un store en réseau. Le coût est dans les détails de chaque flèche : combien de fois un thread doit se réveiller, combien de fois les octets sont copiés, et combien de travail fixe par requête voyage avec, sans aucun rapport avec la clé lue. Ces détails sont là où vivent les onze microsecondes, et ils se regroupent en trois ensembles.

Goulet d'étranglement un : la chaîne de sauts en sortie​

Le plus gros coût n'est pas la lecture de la valeur — c'est sa livraison. Renvoyer une réponse au client, telle qu'actuellement structurée, traverse trois canaux internes, réveille trois threads et copie la charge utile quatre fois sur son chemin de sortie :

1. La réponse est passée du shard worker au chemin d'envoi du pipeline serveur.
2. Le chemin d'envoi la passe à une boucle d'écriture par connexion, qui l'encode dans un buffer poolé.
3. La boucle d'écriture la met en file dans la file d'envoi de la connexion de transport.
4. Le transport fusionne les buffers en file en un flux et écrit sur la socket.

Chaque transmission est un réveil de thread, et chaque réveil est un événement d'ordonnancement que l'OS doit traiter — bon marché individuellement, ruineux à des centaines de milliers par seconde. Et à chaque étape les octets sont copiés à nouveau : buffer d'encodage poolé, file d'envoi, buffer de fusion, socket. Côté entrée il y a un coût symétrique : chaque requête qui arrive sur un thread de complétion IOCP est transmise à un shard worker avant qu'aucun travail n'ait lieu, ce qui est un autre réveil et une autre file.

La raison pour laquelle cette structure existe est raisonnable — découpler réception, dispatch, encodage et transmission rend chaque couche plus simple à raisonner et laisse les consommateurs lents exercer une contre-pression sans bloquer la socket. Mais pour le cas courant — une lecture RF1 dont la réponse est déjà en mémoire sur le nœud qui a reçu la requête — c'est énormément plus de machinerie que le travail ne le mérite. La réponse pourrait, en principe, être calculée et réécrite sur le chemin de réception lui-même, avec une copie dans le buffer de socket et aucune transmission du tout.

C'est la première et la plus grosse pièce de travail structurel que la mesure désigne : réduire la sortie à un saut et une copie pour le chemin chaud, et exécuter la lecture/écriture RF1 en ligne sur le thread de réception plutôt que de la faire rebondir à travers le pool de workers. C'est la différence entre une conception facile à dessiner et une conception peu coûteuse à exécuter, et les deux ne sont pas la même chose.

Goulet d'étranglement deux : hachage redondant et un verrou par requête​

Le deuxième ensemble est la surcharge fixe par opération — du travail qui a lieu à chaque requête quelle que soit la clé touchée, et qui pour l'essentiel ne devrait pas.

CRC16, trois fois, bit par bit. Zaris route les clés vers les partitions avec un hachage CRC16 — la même famille de hachage qu'utilise Redis Cluster, ce qui est comment le front-end RESP reste compatible slots. Le problème n'est pas le choix du hachage ; c'est que l'implémentation est bit-sérielle (en bouclant bit par bit plutôt qu'avec une table de correspondance) et qu'un seul GET le calcule trois fois lorsque la requête traverse le routage. À environ 260 nanosecondes par calcul, cela fait ~784 ns par GET passées à hacher — plus que tout l'aller-retour de décodage-plus-encodage MessagePack, qui tourne autour de 533 ns. Un CRC16 piloté par table calculé une seule fois et transporté ensuite transformerait le plus gros coût fixe en une erreur d'arrondi.

Une vérification de licence qui prend un verrou, à chaque requête. Plus surprenant : le point d'entrée de la requête consulte le service de licence à chaque opération, et cette consultation prend un verrou à l'échelle du processus et lit l'horloge murale (DateTime.UtcNow) pour décider si le bail courant est toujours valide. Un verrou sur le chemin chaud est exactement le genre de chose qui ne se montre pas dans un micro-benchmark mono-thread puis sérialise silencieusement tout en concurrence. Le verdict de licence change au plus quelques fois sur la vie d'un processus — quand un bail est accordé, renouvelé ou expire. Il n'a rien à faire à être recalculé sous un verrou à chaque GET. La correction consiste à publier le verdict dans un unique champ volatile qu'un renouvellement en arrière-plan met à jour, et à laisser le chemin chaud le lire sans verrou ni appel d'horloge. (La machinerie de bail elle-même fait l'objet de l'article sur le cycle de vie des licences ; le point ici est purement que lire le verdict doit être gratuit.)

Aucun de ces deux problèmes n'est un problème algorithmique profond. Ce sont le genre de coût qui s'accumule quand chaque pièce est écrite correctement en isolation et que personne n'a encore mesuré ce que la somme coûte sur le chemin qui s'exécute un million de fois par seconde.

Goulet d'étranglement trois : le client dépense autant que le serveur​

Il serait commode de tout mettre sur le dos du serveur, mais l'ablation dit le contraire : les benchmarks locaux sont limités par le client, et épingler le client sur les cœurs performants seuls l'a fait passer de 169K à 299K ops/s. Le client dépense environ 9 microsecondes et 1,8 Ko par GET, et les coûts riment avec ceux du serveur :

• Les complétions rebondissent à travers le thread pool. Chaque requête en attente est suivie par un TaskCompletionSource configuré pour exécuter sa continuation de façon asynchrone, de sorte que lorsque la réponse arrive la complétion est postée sur le thread pool plutôt que reprise en ligne — un autre saut d'ordonnancement, à chaque opération.
• Une variable d'environnement est lue à chaque opération. Le client appelle Environment.GetEnvironmentVariable("ZARIS_REQUEST_TIMEOUT") par requête pour décider de son échéance. Lire une variable d'environnement parcourt le bloc d'environnement du processus ; le faire un million de fois par seconde est la plus grosse trame rédigée par Zaris côté client. Elle devrait être lue une fois au démarrage et mise en cache.
• Un sémaphore et un verrou de canal par opération, plus des allocations par requête — un id client estampillé sur chaque requête, des métadonnées d'entrée demandées et renvoyées même quand l'appelant ne les a pas demandées.

Le fil conducteur avec le serveur est identique : le travail d'un GET est minuscule, et il est entouré de sauts d'ordonnancement, de verrous et d'allocations qui semblaient chacun gratuits en isolation. Le chemin chaud du client a déjà emprunté la bonne voie — le passage à ValueTask pour les opérations de base a supprimé une allocation par appel lors d'une complétion synchrone — et le reste de la liste est la même idée appliquée plus loin : mettre en cache la variable d'environnement, compléter sans le rebond sur le thread pool, recevoir sur la socket avec un ValueTask, et cesser d'allouer des choses que personne n'a demandées.

Alors, quel est le plancher, vraiment ?​

Faites l'addition et l'image honnête est celle-ci. Sur un ordinateur portable, le chemin TCP natif plafonne autour de 300K ops/s non pas parce que le store est lent — il peut faire des millions — mais parce que chaque opération traîne 10 à 13 microsecondes de CPU serveur et ~9 microsecondes de CPU client à travers une chaîne de sauts, de copies, de hachages redondants et de verrous. Le plancher est fixé par la plomberie, pas par le travail.

Le corollaire encourageant est que le plancher est fait de choses réparables, et l'estimation de ce que leur réparation rapporte est concrète. La liste structurelle est :

1. Réduire la sortie à un saut et une copie.
2. Exécuter le chemin chaud RF1 en ligne sur le thread de réception, ou par lots à chaque réception.
3. CRC16 piloté par table, haché une fois par opération.
4. Complétions client sans allocation ni rebond sur le thread pool.
5. Réception de socket fondée sur ValueTask côté client.
6. Mettre en cache la variable d'environnement de timeout de requête plutôt que de la lire par opération.
7. Publier le verdict de licence dans un champ volatile — pas de verrou, pas d'horloge, sur le chemin chaud.
8. Un régime d'allocation général : réponses poolées, pas d'id client par requête, pas de métadonnées non demandées.

Ensemble, on estime que cela fait passer le CPU serveur par opération de ~10 à ~3-4 microsecondes — ce qui est la différence entre avoir besoin d'une douzaine de cœurs occupés pour un million d'ops/s et en avoir besoin d'environ quatre.

Les mises en garde honnêtes​

Deux choses gardent cet article véridique plutôt que triomphant.

Premièrement, les nombres absolus ici sont des nombres d'ordinateur portable, et ils sont probablement 2 à 4 fois trop bas face à du vrai matériel serveur avec des machines client dédiées. Ce qui se transfère entre environnements n'est pas le débit absolu — c'est l'attribution relative : le store n'est pas le goulet d'étranglement, la sortie est le plus gros coût serveur, et le client dépense autant que le serveur. Ces conclusions sont indépendantes de la machine ; le chiffre final d'ops/s ne l'est pas, et la vraie validation se fait à l'échelle sur Kubernetes, pas sur un poste de travail.

Deuxièmement, la réplication change le plafond. Tout ce qui précède est l'histoire RF1 — une seule copie, le cas rapide. Un PUT RF2 doit répliquer durablement vers une sauvegarde avant de pouvoir accuser réception, et c'est un chemin véritablement différent et plus coûteux ; une cible réaliste pour lui est de 400-500K par nœud, pas un million. Et quand vous n'avez pas besoin d'allers-retours par opération du tout, le chemin par lots amortit presque tout ce coût fixe sur de nombreuses opérations et peut atteindre un million par nœud dès aujourd'hui. Le chiffre d'un million d'ops par nœud unique pour des opérations individuelles est une cible que le travail structurel ci-dessus est censé atteindre — pas un nombre que nous citons comme livré.

Cette distinction est toute la discipline d'un travail de performance digne de confiance : séparer ce que la mesure prouve (le store est rapide, la plomberie est le plancher, et voici où part chaque microseconde) de ce qu'elle promet (un nombre précis après une liste précise de changements). La première est faite et solide. Le second est de l'ingénierie que nous pouvons désormais faire avec une carte au lieu d'une supposition — ce qui est toute la raison pour laquelle on instrumente le chemin avant d'y toucher.

Un basculement, c'est ce qui arrive quand un propriétaire meurt — le cluster a quelques secondes pour choisir un survivant et la partition map ne bouge jamais. La migration est le cousin plus calme et plus dangereux : le propriétaire est parfaitement sain, et vous voulez déplacer une partition hors de lui à dessein — pour faire grandir le cluster, pour rééquilibrer, pour drainer un nœud que vous êtes sur le point de retirer. Rien n'a échoué, ce qui est exactement pourquoi la barre est plus haute. Un basculement a droit à quelques écritures de queue honnêtement perdues dans le pire des cas ; une migration planifiée, non. Si déplacer une partition du nœud A au nœud B peut perdre une seule écriture acquittée, la migration n'est pas une fonctionnalité, c'est un passif.

Cet article parcourt le protocole de cut-over que Zaris exécute réellement, dans l'ordre, et passe l'essentiel de son temps sur l'étape que tout le monde rate : le moment où la source est enfin « libre » de déposer sa copie. Cette étape est un pistolet armé, et l'ingénierie intéressante est la sécurité dessus.

La forme du problème​

Une partition est un ensemble de segments, et un segment est un sac d'enregistrements clé-valeur, chacun portant une révision monotone. La migration déplace les données d'un segment d'un nœud source vers un nœud cible puis bascule la possession pour que les clients routent vers la cible. Le tout se produit pendant que le segment est vivant : lectures et écritures continuent d'atterrir tout du long.

Cette vivacité est le problème. Si vous prenez un snapshot de la source, expédiez les octets, et basculez la possession, chaque écriture qui a atterri pendant l'expédition est sur la source et pas sur la cible — et à l'instant où vous basculez, ces écritures disparaissent de la vue routée. Vous les avez acquittées ; on a dit au client « validé » ; maintenant elles sont perdues. La migration naïve perd exactement les écritures survenues pendant qu'elle était occupée à être prudente à propos de celles survenues avant.

Le protocole doit donc faire deux choses en tension : continuer de servir les écritures sur la source jusqu'au basculement, et garantir que la cible détient chacune de ces écritures avant que le basculement ne prenne effet. La façon dont Zaris réconcilie cette tension est une séquence de cinq étapes, dont chacune refuse d'avancer tant que la précédente n'est pas prouvée complète.

Étape 1 — un snapshot ancré sur une révision, avec le plancher de trim épinglé​

La cible démarre en demandant à la source les données du segment (SegmentMigrationRequest). La source ne sérialise pas simplement son dictionnaire courant ; elle prend un snapshot ancré sur une révision. Elle enregistre la révision courante du segment — appelons-la R — et capture les enregistrements vivants à hauteur de R.

Deux subtilités vivent dans cette seule étape. D'abord, la source arme son op-log avant de capturer l'ancre. Zaris peut sauter l'op-log pour un segment à primaire unique (RF1) comme optimisation du chemin d'écriture ; l'armer d'abord signifie que chaque écriture à partir de ce point est loguée, de sorte qu'une écriture précédemment non loguée (skip-logged) a toujours une révision à ou en dessous de R et est portée par le snapshot lui-même. Le delta que nous calculons plus tard — « les ops après R » — est alors prouvé sans trou.

Ensuite, la source épingle le plancher de trim de son op-log à R :

var (snapshotRevision, snapshotEntries) = _store.CreateSegmentSnapshot(segmentId);
// Pin BEFORE streaming so any op the source acks between the snapshot and the
// new owner's final-delta request is still replayable — the floor cannot advance past R.
_store.PinSegmentTrim(segmentId, snapshotRevision.Value);

Normalement l'op-log élague les anciennes entrées pour récupérer de la mémoire. Pendant une migration ce serait un désastre : si le plancher avançait au-delà de R pendant que le transfert en masse est en vol, les écritures entre R et le basculement seraient non-rejouables, et le delta final serait silencieusement partiel. Épingler le plancher à R garantit que ces écritures survivent jusqu'à ce que la cible les ait. La source diffuse ensuite les entrées du snapshot — et continue de servir lectures et écritures tout du long. Elle est toujours le propriétaire routé. Rien n'a encore bougé.

Étape 2 — la cible attend, délibérément​

La cible applique le snapshot en masse puis fait quelque chose qui ressemble à de l'inaction mais qui est le cœur de la conception : elle fait passer le segment dans un état en attente de cut-over et s'arrête. Elle n'accuse pas réception à la source. Elle ne revendique pas la possession. Elle ne dit pas au leader qu'elle a terminé. Le commentaire dans le code est brutal sur le pourquoi :

NO Ack to the source (it is still the routed owner), NO ownership claim, and NO completion notify yet — the completion is withheld until the fenced final delta confirms this node holds everything the source acked.

C'est le contrat « ancien-propriétaire-autoritaire ». Jusqu'au basculement, exactement un nœud répond pour le segment, et c'est la source. Une cible qui aurait brûlé l'étape — commencé à servir à partir d'un snapshot déjà périmé de quelques centaines d'écritures — serait un split-brain. La cible patiente donc, et demande la seule chose qui lui permettra de prouver qu'elle est à jour : le delta final.

Étape 3 — le delta final sous barrière d'écriture et la preuve par digest​

La cible envoie un SegmentMigrationFinalDeltaRequest ancré à R. C'est là que la source fait la partie délicate.

// Fence FIRST, then capture a revision after the fence — so no acked write can exist beyond it.
var fenceEpoch = _topologyManager.EngageMigrationWriteFence(seg, request.CreationMapVersion);
var fenceRevision = _localStore.GetSegmentCurrentRevision(seg);

Elle engage une barrière d'écriture sur le segment puis lit la révision courante. L'ordre compte : barrière d'abord, mesure ensuite, pour qu'il n'y ait aucune fenêtre où une écriture se glisse après la mesure. Puis elle lit chaque entrée d'op-log après R — le delta de tout ce qui a atterri pendant le transfert en masse — et calcule un digest de contenu de l'état vivant du segment. Ce digest est le pivot de tout le protocole, donc la source l'enregistre comme la preuve de cut-over :

response.Operations = finalOps.ToList();
response.SourceDigest = _localStore.ComputeSegmentLiveDigest(seg);
// Record this served digest as the cut-over PROOF: the post-cut-over orphan drop will refuse to
// destroy this segment's data unless its live digest still equals this exact value.
_localStore.RecordCutoverProofDigest(seg, response.SourceDigest);

Un mode de défaillance honnête est câblé juste ici. Si le plancher de trim avait d'une manière ou d'une autre avancé au-delà de R — un épinglage perdu ou régressé — alors « les ops après R » seraient incomplètes, et expédier ce delta perdrait silencieusement des écritures acquittées. La source refuse :

if (!_localStore.TryGetSegmentOperationsAfter(seg, request.SnapshotRevision, out var finalOps))
{
    response.Aborted = true;
    response.AbortReason = "FinalDeltaBelowTrimFloor";
    // release the fence, re-snapshot, retry — a loud abort, never a silent partial cut-over.
}

Un abandon sous le plancher n'est pas une perte ; il démantèle et re-snapshote depuis une ancre fraîche. La règle que le code respecte est un abandon bruyant plutôt qu'un partiel silencieux — la migration préfère recommencer que basculer sur un delta incomplet.

Étape 4 — la barrière : la cible prouve qu'elle domine​

La cible applique le delta, puis recalcule son propre digest de contenu du segment et le compare à celui de la source :

var localDigest = _localStore.ComputeSegmentLiveDigest(seg);
var matchesSource = string.Equals(localDigest, response.SourceDigest, StringComparison.Ordinal);

Si les deux digests sont égaux, la cible détient octet pour octet ce que la source détenait à la barrière — l'état de la cible est un sur-ensemble de chaque écriture que la source a acquittée. S'ils diffèrent, c'est presque toujours parce que le snapshot diffusé est encore en cours d'application quand le premier delta est calculé (le signal de complétion peut dépasser des lots de données en file), donc la cible reste en attente et laisse un réessai espacé redemander le delta plutôt que de tourner à vide. Une divergence ne bascule jamais. Le basculement est conditionné par une preuve positive d'égalité, pas par l'absence d'une erreur.

Il y a une chose de plus que la cible fait avant de crier victoire, et c'est une garantie que la plupart des implémentations de migration sautent. La source n'est pas la seule copie qui pourrait être en avance — un réplica du segment pourrait détenir une écriture que la source sous barrière a manquée. Donc avant de terminer, la cible intègre la queue en lecture seule de chaque réplica vivant :

The flip may fire only when the new owner's digest dominates the source and every live replica of the segment.

L'intégration préserve les révisions : les enregistrements plus anciens d'un réplica en retard sont ignorés par la garde de révision, et un réplica en avance contribue exactement l'écriture que la source n'avait pas. Ce n'est que lorsque la cible domine la source et chaque réplica vivant qu'elle poursuit. C'est l'invariant « durabilité avant possession » — la possession est une récompense pour une possession prouvable, pas une condition préalable à celle-ci.

Étape 5 — le basculement, et le drop qui perd presque vos données​

Maintenant la cible dit au leader qu'elle a terminé (SegmentMigrationCompletionNotify). Le leader valide la complétion contre l'override de migration vivant et arme une régénération atomique de cut-over de la partition map — un unique changement de map versionné qui bascule le propriétaire du segment vers la cible et retire l'override de migration. Après que cette map s'applique, la cible est le propriétaire routé. Les clients routent vers elle. Le déplacement est, du point de vue du cluster, terminé.

Et la source, qui détient désormais un segment dont elle ne possède plus de rôle, exécute un balayage de ménage pour déposer la copie orpheline et récupérer la mémoire. C'est le pistolet armé.

Voici le piège, et il est assez subtil pour avoir survécu jusque dans une exécution de certification avant d'être attrapé (Missing=8629 clés acquittées disparues). Une barrière d'écriture réduit l'acquittement mais, sur un segment à copie unique sous charge, ne le met pas parfaitement et instantanément à zéro. Cette séquence est donc possible :

1. La source sert le digest du delta final comme preuve. La cible le fait correspondre et bascule.
2. Dans l'infime intervalle entre le service de la preuve et l'atterrissage du basculement, une écriture de plus est acquittée sur la source.
3. La cible n'a jamais reçu cette écriture — la preuve qu'elle a fait correspondre date d'avant elle.
4. La source, désormais orpheline, dépose sa copie pour récupérer de l'espace.
5. Cette dernière écriture n'existait que sur la source. Elle est perdue. On a dit à un client qu'elle était validée.

La correction consiste à rendre le drop conditionnel au fait que la preuve soit toujours vraie. La source ne détruit pas aveuglément un segment orphelin. Elle compare le digest vivant courant du segment au digest qu'elle a enregistré comme preuve de cut-over, et ne détruit les données que s'ils correspondent toujours :

public static bool ShouldRetainAfterCutover(bool hasCutoverProof, string? currentLiveDigest, string? proofDigest)
{
    if (!hasCutoverProof || string.IsNullOrEmpty(proofDigest))
        return false; // not a proof-carrying cut-over segment -> this policy does not intervene
    return !string.Equals(currentLiveDigest, proofDigest, System.StringComparison.Ordinal);
}

Si une écriture a atterri après la preuve, le digest courant diffère du digest de preuve, ShouldRetainAfterCutover renvoie true, et la source conserve sa copie :

if (CutoverDropSafetyPolicy.ShouldRetainAfterCutover(hasProof, currentDigest, proofDigest))
{
    Log.CutoverDropRetainedUnprovenTail(_logger, store.Count, segmentId);
    continue; // keep the store — a post-proof tail exists that the new owner has not received
}

L'asymétrie est tout l'enjeu. La conservation est toujours sûre : la source n'est plus le propriétaire routé, donc une copie conservée est un orphelin redondant et non servi — elle ne peut jamais causer de split-brain, elle coûte juste un peu de mémoire jusqu'à ce qu'un re-service redélivre la queue au nouveau propriétaire et qu'un balayage ultérieur, constatant que les digests concordent à nouveau, la dépose proprement. La destruction sur une preuve périmée n'est jamais sûre : c'est la seule opération qui peut supprimer définitivement une écriture acquittée. La politique est donc délibérément étroite — elle ne fait jamais qu'outrepasser un drop qui aurait autrement lieu, et seulement pour un segment portant une preuve enregistrée dont le digest ne correspond plus. Les segments sans preuve (une éviction, un basculement immédiat, un segment jamais migré) conservent leur comportement existant intact. La barrière ajoute une conservation ; elle n'ajoute jamais un drop.

Pourquoi le digest, et pas un numéro de révision ?​

Vous pourriez demander pourquoi la preuve est un digest de contenu et pas simplement « la révision la plus haute que la cible a acquittée ». La réponse est qu'un numéro de révision vous dit jusqu'où la cible est allée, mais un digest vous dit si ce qu'elle a obtenu est ce que vous aviez. Les deux peuvent diverger dans les coutures — une intégration de réplica, un réessai ré-ancré, un snapshot encore en train de se vider — et la seule question qui garde les données en sécurité est la question de contenu : le nouveau propriétaire détient-il exactement ceci ? Un digest y répond directement. Un filigrane (watermark) ne répond qu'à un proxy de cette question, et les proxys sont là où les écritures acquittées vont mourir.

Ce que cela achète, honnêtement​

Dit simplement, la garantie est : une migration de partition planifiée ne perd pas d'écriture acquittée. Chaque écriture que la source a acquittée avant la barrière est dans le snapshot ou le delta ; chaque écriture qu'elle a acquittée après la preuve garde la copie de la source en vie jusqu'à ce que le nouveau propriétaire l'ait aussi. Le protocole abandonnera et recommencera bruyamment plutôt que de basculer sur un delta incomplet, et il intègre les réplicas vivants pour que le nouveau propriétaire domine chaque copie, pas seulement la source.

Ce qu'il n'est pas, c'est gratuit. Le delta final sous barrière est un aller-retour synchrone qui met brièvement les écritures sous barrière sur le segment en cours de cut-over — une pause courte et bornée sur un segment, pas sur la partition ni sur le cluster. Une migration qui ne peut pas converger (un plancher de trim qui n'arrête pas d'avancer, une queue de réplica qui ne peut pas être exprimée depuis son log) re-snapshote et réessaie plutôt que de forcer le progrès, ce qui, sous un churn pathologique, signifie qu'une migration prend plus de temps plutôt que de prendre un raccourci à travers vos données. Ce sont les bons compromis pour une opération planifiée : un déplacement que vous avez choisi de faire ne devrait jamais être la raison pour laquelle une écriture validée disparaît.

C'est la même colonne vertébrale que la certification du chaos sur douze heures exerce depuis l'extérieur — arrêter un nœud en pleine migration, brasser la map, et regarder les écritures acquittées survivre. Cet article est la vue de l'intérieur de l'une des coutures que cette exécution prouve fermée : le moment où une partition change de main, et la sécurité sur la détente qui empêche la transmission de dévorer les écritures mêmes qu'elle a été bâtie pour protéger. Il s'appuie sur deux autres pièces qui valent la lecture à elles seules — l'op-log rejouable qui fait de « les ops après la révision R » une requête réelle et sans trou, et la mise à l'échelle élastique qui est la raison la plus courante pour laquelle une partition a besoin de se déplacer un jour.

Un GET à clé unique est facile à raisonner : hacher la clé, trouver son propriétaire, demander à ce seul nœud. SCAN est le genre d'opération opposé. Il n'a pas de clé — il pose une question sur tout le keyspace : donne-moi chaque clé dans cette plage, une page à la fois. Et dans un store partitionné et répliqué, ce keyspace n'est pas une seule chose en un seul endroit. Il est réparti sur 256 segments étalés sur autant de nœuds que vous en exécutez, chaque nœud ne détenant que les tranches qu'il possède actuellement, et l'ensemble est en cours d'écriture pendant que vous itérez. Il n'y a pas d'index trié global à parcourir. Alors d'où vient l'ordre, que pointe exactement un jeton de reprise, et qu'arrive-t-il à votre scan quand une clé est écrite — ou qu'une partition se déplace — en plein milieu ?

Cet article suit un SCAN à travers les trois couches qui le servent réellement : un seul segment, un seul nœud, et le client qui recoud les nœuds ensemble. Chaque couche résout une pièce du problème, et les limites honnêtes de l'opération découlent de la façon dont ces pièces s'emboîtent.

La requête : une plage et une taille de page, pas une clé​

Un scan est décrit par deux petits objets. Un KeyRange dit quelles clés — un début, une fin ou un préfixe, chacun optionnel :

public sealed class KeyRange
{
    public string? Start  { get; set; }
    public string? End    { get; set; }
    public string? Prefix { get; set; }
}

Et ScanOptions dit comment les délivrer — quelle taille de page, s'il faut expédier les valeurs ou juste les clés, une limite stricte optionnelle, et un jeton de reprise pour continuer un appel précédent :

public sealed class ScanOptions
{
    public int     PageSize       { get; set; } = 100;
    public bool    IncludeValues  { get; set; } = true;
    public bool    IncludeMetadata{ get; set; } = false;
    public string? ResumeToken    { get; set; }
    public int?    LimitCount     { get; set; }
}

Rien ici ne nomme un nœud ou un segment. C'est tout l'enjeu : l'appelant décrit ce qu'il veut, et les trois couches en dessous déterminent où cela réside et dans quel ordre le rendre.

Couche un : un segment se scanne lui-même, sans verrou et dans l'ordre​

La plus petite unité qui peut répondre à une partie d'un scan est un segment — l'unité de stockage partitionné de Zaris, soutenue par un ConcurrentDictionary d'enregistrements vivants. Un dictionnaire n'a pas d'ordre, donc la première chose dont un scan de segment a besoin est une vue triée de ses clés. La construire à chaque page serait ruineux, donc chaque segment conserve un snapshot trié de clés, immuable et mis en cache et ne le reconstruit que lorsque le jeu de clés change :

// No lock held during scan — the snapshot is immutable once built.
var sortedKeys = GetOrBuildSortedKeys();

int startIdx = BinarySearchKey(sortedKeys, startKey, StringComparer.Ordinal);
if (startIdx < 0) startIdx = ~startIdx;

Le tableau est assigné une fois et jamais muté ; une reconstruction concurrente produit simplement un nouveau tableau et échange la référence. Cela signifie que le parcours du scan lui-même ne prend aucun verrou du tout — il fait une recherche binaire jusqu'à la clé de départ et avance dans l'ordre ordinal, lisant les enregistrements vivants depuis le dictionnaire concurrent au fur et à mesure. Les lectures et écritures sur le segment ne bloquent jamais le scan, et le scan ne les bloque jamais.

Deux sortes de clés sont silencieusement passées au fil du parcours :

if (!_data.TryGetValue(key, out var record)) continue;        // vanished since snapshot
if (record.IsDeleted || ExpirationManager.IsExpired(record, now)) continue;  // tombstone / TTL

Une clé supprimée est une pierre tombale (tombstone) — un enregistrement réel marqué IsDeleted, car une suppression doit être un enregistrement, pas une absence, pour que la réplication la transporte. Le scan les filtre, ainsi que les clés dont le TTL est écoulé mais dont le balayeur ne s'est pas encore déclenché. Le snapshot trié de clés est donc un sur-ensemble de ce que vous verrez ; expiration et suppression sont résolues contre l'enregistrement vivant au moment de la lecture, pas figées dans le snapshot.

Le parcours s'arrête à PageSize et renvoie un ResumeToken. Voici le premier détail honnête : au niveau du segment, le jeton est essentiellement un décalage (offset) — un décompte du nombre d'entrées correspondantes déjà renvoyées (ReturnedSoFar). Un scan de segment repris refait une recherche binaire jusqu'à la même clé de départ et saute ce nombre de correspondances avant d'émettre. C'est une position-par-décompte, pas une position-par-clé.

cursor.ReturnedSoFar += taken;
bool hasMore = results.Count >= pageSize && cursor.ReturnedSoFar < totalLimit;

Ce choix compte pour ce que l'opération promet, et nous y reviendrons.

Couche deux : un nœud fusionne ses segments en un seul flux ordonné​

Un nœud possède de nombreux segments — pas les 256, juste ceux mappés aux partitions qu'il sert actuellement. Un scan au niveau du nœud doit présenter tous ces segments comme un seul résultat ordonné, car l'appelant a demandé une plage, pas le segment 42. C'est un problème de fusion classique : chaque segment peut produire ses clés dans l'ordre trié, et vous voulez l'union triée.

Donc la première page d'un scan de nœud fait exactement cela. Elle rassemble un fetcher pour chaque segment possédé localement et exécute une fusion k-voies à travers eux avec une file de priorité, comparant les clés de façon ordinale :

var heap = new PriorityQueue<(KvResult<ZarisEntry> Item, int Source), KvResult<ZarisEntry>>(comparison);
// seed with the head of each segment, then repeatedly pop the smallest
// key and pull the next from that segment's enumerator

Le résultat fusionné et ordonné est matérialisé dans un buffer détenu par un RouterQueryCoordinator — une session côté serveur de courte durée enregistrée sous un QueryId fraîchement frappé :

coord = new RouterQueryCoordinator();
await coord.InitScanAsync(fetchers, ct);     // drains + merges every owned segment
var id = _coordManager.Register(coord);
cursor = new QueryCursor { QueryId = id, ReturnedSoFar = 0 };

Chaque page suivante n'est qu'une tranche de ce buffer, et le jeton de reprise du nœud porte le QueryId pour que l'appel suivant retrouve la même session :

if (!string.IsNullOrEmpty(options?.ResumeToken))
{
    cursor = QueryCursor.Deserialize(options.ResumeToken);
    if (!_coordManager.TryGet(cursor.QueryId, out coord))
        throw new InvalidOperationException($"Search session {cursor.QueryId} not found (expired or cleaned).");
}

C'est le deuxième détail honnête, et c'est un vrai compromis. Un scan au niveau du nœud est à état (stateful) : la pagination est stable et l'ordre par nœud est exact, mais le prix est que le nœud matérialise tout son keyspace possédé et fusionné dans un buffer quand le scan commence, et détient une session pour la durée de vie de l'itération. Les scans sont un outil d'administration et d'itération en masse, pas un curseur de streaming à mémoire constante sur des milliards de clés — et un jeton de reprise n'est valable que contre le nœud et la session qui l'ont frappé. Laissez cette session expirer, ou tentez de la reprendre ailleurs, et vous obtenez un bruyant « session not found » plutôt qu'une réponse silencieusement fausse.

Couche trois : le client s'éventaille et entrelace les propriétaires​

Un nœud répond pour les segments qu'il possède. Un scan de cluster doit couvrir chaque propriétaire, donc le ScanClusterClient côté client ouvre un scan contre chaque nœud en parallèle et entrelace leurs pages à mesure qu'elles arrivent, plutôt que de vider un nœud avant de commencer le suivant :

var enumerators = clients
    .Select(c => c.Scan.ScanAsync(range, options, ct).GetAsyncEnumerator(ct))
    .ToList();

// advance all owners concurrently; yield whichever produces next
var finishedTask = await Task.WhenAny(pending.Select(p => p.Task));

Ce parallélisme est pourquoi LimitCount demande du soin. Chaque nœud traite la limite comme un plafond par nœud ; si le client ne l'imposait pas aussi, un LimitCount de 1 000 contre quatre propriétaires pourrait renvoyer jusqu'à 4 000 lignes une fois fusionnées. Donc la couche cluster applique la limite comme un plafond total strict et cesse d'émettre une fois qu'elle est atteinte — tout en continuant à vider jusqu'au bout la page en vol de chaque propriétaire, car disposer d'un énumérateur asynchrone en plein déplacement n'est pas permis et les résultats par nœud sont de toute façon déjà bornés :

if (emitted < limit)
{
    yield return enumerator.Current;
    emitted++;
}
// keep draining siblings even past the cap; do not yield-break mid-move

La conséquence à clarifier : au sein de la contribution d'un seul nœud, les clés arrivent dans l'ordre ; entre les nœuds elles sont entrelacées par ordre d'arrivée, donc un scan de cluster complet n'est pas trié globalement sauf si vous le demandez explicitement. (Le chemin Search apparenté porte bien SortFields et fusionne avec un comparateur pour exactement cette raison.) Si vous avez besoin de chaque clé du cluster dans l'ordre ordinal, triez le résultat assemblé ; SCAN lui-même garantit l'ordre par propriétaire et l'exhaustivité, pas un tri global.

Ce qu'un SCAN promet — et ne promet pas​

Mettez les trois couches ensemble et le vrai contrat de l'opération est visible, sans que rien n'en soit caché :

• Ce n'est pas un snapshot ponctuel du cluster. Chaque nœud matérialise son propre buffer fusionné quand son scan commence, et ces moments ne coïncident pas. Les écritures qui atterrissent sur un nœud avant que son buffer ne soit construit sont incluses ; celles d'après ne le sont pas. Il n'y a pas de gel à l'échelle du cluster.
• Les clés supprimées et expirées ne font jamais surface. Les pierres tombales et les enregistrements au TTL écoulé sont filtrés contre l'enregistrement vivant au fil du parcours du segment, donc un scan reflète le contenu logique, pas physique.
• La reprise est position-par-décompte à l'intérieur d'une session. Parce que le curseur par segment est un décalage, une clé insérée ou retirée avant la position courante entre deux pages peut décaler la frontière — un scan concurrent à une forte mutation de la plage scannée peut, en principe, répéter ou sauter une clé autour de la couture. Un scan d'une plage au repos est exact. C'est la même famille de garantie que donne le SCAN de Redis — une itération complète au mieux, pas un niveau d'isolation snapshot — et c'est le bon compromis pour un store non ordonné et écrit en concurrence.
• Le keyspace peut bouger sous vos pieds. Le client s'éventaille vers les propriétaires qui existent au démarrage du scan. Les partitions peuvent migrer ou basculer en pleine itération ; un scan est un balayage au mieux d'un cluster vivant, ce qui est pourquoi c'est l'outil de l'export en masse, de la réindexation et des requêtes d'administration plutôt que des lectures transactionnelles. Pour le read-your-writes sur une clé unique, routez vers le propriétaire à la place.

Aucune de ces propriétés n'est un bug à masquer ; ce sont la forme honnête de l'itération d'un keyspace non ordonné, partitionné et en mutation sans arrêter le monde. La conception rend le cas courant et bon marché rapide — un snapshot trié sans verrou et une fusion par nœud — et est explicite sur les bords.

Une note sur le front-end RESP​

Les clients Redis atteignent la même machinerie via KEYS et SCAN sur le front-end RESP, qui se mappent sur le scan natif. Une mise en garde à énoncer sans détour : le SCAN RESP est aujourd'hui en un seul coup — il vide le scan natif et répond avec le curseur 0 (itération terminée) en un aller-retour, plutôt que de filer le curseur incrémental de Redis à travers chaque appel. Il est honnête sur l'exhaustivité, pas encore incrémental. Le client natif est celui qui pagine avec un jeton de reprise.

Une opération, trois couches honnêtes​

Un GET touche un propriétaire et une clé ; un SCAN touche chaque propriétaire et demande à chacun de produire sa tranche d'un tout ordonné. Le travail se divise proprement : un segment transforme un dictionnaire non ordonné en un parcours trié sans verrou ; un nœud fusionne ses segments en un seul flux ordonné et paginé de façon stable derrière un curseur de session ; le client s'éventaille sur les propriétaires, entrelace leurs pages, et impose le seul plafond que l'éventail casserait autrement. Chaque couche est simple en soi, et les garanties de l'opération — ordre par propriétaire, exhaustivité sur une plage au repos, pas d'isolation snapshot, pas de gel global — sont exactement ce que ces trois couches simples peuvent honnêtement délivrer ensemble.

Voici une question qui semble simple et ne l'est pas : qu'arrive-t-il quand un store en mémoire tombe à court de mémoire ?

La réponse naïve est « il plante » — le processus grimpe jusqu'à ce que le système d'exploitation le tue. La réponse un peu moins naïve est « il refuse les écritures ». Zaris ne fait ni l'un ni l'autre par défaut. Un nœud Zaris est un store en mémoire, mais il n'est délibérément pas illimité : chaque nœud est un buffer borné avec un plafond dur, et quand les données qu'il possède approchent ce plafond, le nœud évince ses données les plus froides pour faire de la place. Les écritures continuent de réussir ; la limite tient ; le processus ne gonfle pas. Le nœud se comporte comme un cache, parce qu'en dessous, c'en est un.

Chaque nœud est un buffer borné​

Un nœud Zaris ne croît pas sans limite. Chaque nœud comptabilise en continu la taille des données qu'il possède activement et maintient ce total courant sous un plafond configuré. La comptabilité n'est jamais optionnelle — un nœud est toujours un buffer borné. Les seules choses que vous configurez sont la taille du plafond et, en principe, ce que le nœud fait quand il l'atteint.

Le plafond par défaut est de 1 Gio de données activement possédées par nœud. Il n'y a, par conception, aucun réglage « illimité ». Si vous ne fixez pas de plafond, vous obtenez la valeur par défaut — vous n'obtenez jamais l'infini par accident.

Une subtilité compte pour la façon de raisonner l'empreinte d'un cluster : le plafond couvre les données qu'un nœud possède activement — les copies primaires qu'il sert aux clients. Les copies de réplica qu'un nœud détient pour d'autres partitions sont suivies séparément et ne comptent pas contre le plafond de propriétaire actif. La vraie mémoire résidente d'un nœud est donc son jeu de travail possédé plus les copies de réplica qu'il porte pour ses pairs ; le plafond régit le premier, pas la somme.

Deux façons de tenir la ligne​

Il y a exactement deux choses qu'un buffer borné peut faire quand une écriture le pousserait au-delà de son plafond : déposer quelque chose d'ancien pour faire de la place, ou refuser la nouvelle écriture.

Avec l'éviction activée, un nœud est un cache : sous pression il dépose les données les moins précieuses pour que les écritures continuent de circuler. Avec l'éviction désactivée, c'est un store qui rejette à capacité et protège les données existantes en refoulant les nouvelles écritures.

Voici la partie honnête. Dans la version actuelle, un nœud fonctionne toujours avec l'éviction activée, en utilisant la politique LRU. Le mode sans éviction et les politiques alternatives (LFU, TTL-aware) existent dans le moteur, mais ils ne sont pas encore sélectionnables par configuration. La conséquence pratique est que CapacityExceeded — le statut de rejet à capacité — est essentiellement inatteignable aujourd'hui : un nœud plein évince plutôt que de refuser. C'est un statut réel et typé contre lequel vous pouvez écrire du code, mais sous la politique LRU toujours active vous ne le verrez normalement pas. Le seul bouton mémoire que vous contrôlez réellement en ce moment est la taille du plafond lui-même, memory.maxSizeBytes.

L'exécution d'éviction chevauche une bande calme​

L'ingénierie intéressante n'est pas *qu'*un nœud évince — c'est comment, car une conception naïve « évincer à chaque écriture une fois plein » s'emballe misérablement. Imaginez un nœud posé exactement à son plafond : chaque écriture entrante déclencherait une éviction pour se faire de la place, et vous paieriez ce coût sur le chemin chaud à jamais.

Zaris évite cela avec deux manœuvres. D'abord, l'éviction est pilotée par une boucle d'arrière-plan, pas par l'écriture individuelle — l'écriture qui fait basculer un nœud par-dessus bord est admise, et la boucle récupère l'espace peu après, hors du chemin de requête. Ensuite, la boucle utilise l'hystérésis : un seuil de déclenchement haut et une cible plus basse, de sorte qu'elle récupère par rafales puis se tait au lieu de tirer continûment au bord.

• Déclenchement : une exécution démarre quand l'usage actif dépasse 80 % du plafond.
• Cible : une fois démarrée, l'exécution continue d'évincer jusqu'à ce qu'environ 30 % du plafond soit à nouveau libre — jusqu'à ce que l'usage retombe à environ 70 %.
• Cadence : la boucle se réveille à intervalle fixe (une seconde par défaut) et échantillonne un ensemble borné d'items candidats à chaque cycle.

Parce que la cible post-éviction (70 %) se situe strictement en dessous du déclenchement (80 %), chaque exécution fait retomber l'usage dans une bande calme plutôt que de s'arrêter juste au point qui le re-déclencherait immédiatement. C'est la dent de scie dans l'image d'en-tête : l'usage grimpe à 80 %, une exécution le ramène à 70 %, puis il remonte — jamais plaqué contre le plafond, jamais d'emballement d'une éviction par écriture.

La politique d'éviction elle-même est LRU — least recently used, la moins récemment utilisée — et elle est échantillonnée, pas stricte. Plutôt que de maintenir une liste globalement ordonnée de chaque clé (ce qui coûterait de la mémoire et de la contention de verrou sur le chemin chaud), Zaris estampille des signaux de récence approximatifs sur place sur le chemin de lecture et, quand une exécution se déclenche, échantillonne un petit ensemble de candidats et dépose ceux au plus bas score. C'est la même approche échantillonnée qu'utilise Redis, et le même compromis : vous abandonnez l'ordre parfait « évincer la plus ancienne clé unique » en échange d'une éviction qui ne coûte presque rien à maintenir et n'a jamais besoin d'un index séparé.

L'autre plafond : la taille par item​

Le plafond de mémoire global est une limite sur le total. Il y a une seconde limite indépendante sur tout item unique : par défaut une valeur ne peut pas dépasser 4 Mio. Elle est vérifiée à chaque écriture quel que soit le mode d'éviction, et c'est là qu'une écriture atteint un rejet véritablement atteignable.

La distinction compte parce que les deux défaillances signifient des choses opposées et veulent des réponses opposées :

var result = await client.PutAsync("report:2026-07", payload);

if (!result.IsSuccess)
{
    switch (result.Status)
    {
        case KvStatus.ItemTooLarge:
            // This one value is too big. No amount of eviction helps —
            // split it, or store a reference to it elsewhere.
            break;

        case KvStatus.CapacityExceeded:
            // The node is full and eviction is disabled (not the default).
            // Retry later or shed load.
            break;
    }
}

ItemTooLarge est un résultat vivant et atteignable dans tous les modes — l'éviction ne peut pas faire de place pour une valeur qui dépasse le plafond par item, car le plafond n'est pas une question d'espace libre, c'est une question de valeur pathologique unique. CapacityExceeded, comme couvert ci-dessus, n'apparaît que dans le mode sans éviction que vous ne pouvez pas encore sélectionner. Les traiter de façon identique est un bug qui attend d'arriver : réessayer une écriture ItemTooLarge éternellement ne réussira jamais.

Une ride apparentée vit à la frontière entre ce plafond par item et le runtime .NET : les valeurs d'environ 85 000 octets et plus atterrissent sur le Large Object Heap, donc relever maxItemSizeBytes pour admettre de grosses valeurs est une décision délibérée avec des conséquences GC, pas un cadran gratuit. Si vous mettez à jour à chaud de grosses valeurs simples, les découper en morceaux sous-LOH est le mécanisme qui empêche le LOH de s'agiter — une fonctionnalité séparée avec ses propres compromis, que nous avons détaillée dans Stocker de gros objets sans agiter le heap.

Ce que vous configurez, et ce que vous ne configurez pas​

Le plafond de mémoire vit dans la configuration du store sous la section memory :

{
  "memory": {
    "maxSizeBytes": 2147483648
  }
}

Cela fait 2 Gio. Mettez maxSizeBytes à null, ou omettez-le, et vous obtenez la valeur par défaut de 1 Gio. Dans la version actuelle c'est le réglage de mémoire que vous contrôlez — la politique LRU, les seuils d'hystérésis 80 %/70 % et la cadence d'une seconde sont des valeurs par défaut fixes, pas des boutons. Il vaut la peine d'être lucide à ce sujet : les articles de blog et le moteur décrivent un espace de politiques plus riche que ce que la surface de configuration expose actuellement, et cet article décrit ce que vous pouvez réellement régler aujourd'hui.

Ce que cela signifie pour dimensionner un cluster​

Parce que chaque nœud est un buffer borné, la capacité totale d'un store est à peu près le plafond par nœud multiplié par le nombre de partitions qu'un nœud possède, ajusté par le facteur de réplication (les réplicas détiennent des copies supplémentaires qui vivent hors du plafond de propriétaire actif). Deux conséquences pratiques en découlent :

• Dimensionnez le plafond sur votre jeu de travail plus une marge d'éviction, pas sur vos données totales. Un nœud exécute aujourd'hui un cache LRU toujours actif, donc les données froides sont déposées sous pression plutôt que rejetées. Si votre jeu de travail tient sous ~70 % du plafond avec de la place pour que la bande respire, l'éviction reste calme et le jeu chaud reste résident. Si vous dimensionnez le plafond en dessous de votre jeu de travail, vous avez construit un cache qui évince constamment des données dont il va avoir à nouveau besoin — correct, mais lent, et la dent de scie se transforme en meule.
• N'oubliez pas l'empreinte des réplicas. Le plafond régit les données possédées, mais la RAM réelle d'un nœud est les données possédées plus les copies de réplica. Quand vous provisionnez la mémoire par pod ou par machine, budgétez pour les deux, ou un nœud dimensionné « à son plafond » tournera quand même plus chaud que le plafond ne le laisse entendre.

Pour le calcul de capacité dans le contexte des partitions, du facteur de réplication et des nombres de pods, Dimensionner un cluster Zaris pour la durabilité sur Kubernetes parcourt le calcul complet.

À retenir​

Un store en mémoire qui croît sans borne n'est pas une fonctionnalité — c'est une panne qui attend un pic de trafic. Zaris traite chaque nœud comme un buffer borné avec un vrai plafond (1 Gio par défaut, aucune option illimitée), un cache LRU échantillonné toujours actif en dessous, et une bande d'hystérésis qui récupère l'espace par rafales calmes plutôt que de s'emballer avec une éviction par écriture au bord. Le plafond total et le plafond par item sont deux limites différentes avec deux statuts typés différents, et celui qui est réellement atteignable aujourd'hui — ItemTooLarge — veut une réponse différente d'une boucle de réessai. Dimensionnez le plafond sur votre jeu de travail, budgétez les copies de réplica en plus, et le nœud tient sa ligne sans que vous ayez à le surveiller.

Le modèle complet, y compris les politiques que le moteur porte mais n'expose pas encore, est dans Mémoire et éviction ; les champs et valeurs par défaut exacts sont dans la référence de configuration, et chaque statut de capacité est catalogué dans la référence des statuts et exceptions.

L'essentiel de ce que Zaris fait bien — répliquer une écriture vers une sauvegarde, remettre à niveau un réplica en retard, faire basculer une partition vers un nouveau propriétaire — se ramène à une question discrète : quelle est, exactement, l'unité de données qui se déplace entre les nœuds ? Si cette unité est juste, la convergence est presque ennuyeuse. Si elle oublie un champ ou en porte un faux, vous obtenez une clé supprimée ressuscitée, un réplica incapable de distinguer le périmé du frais, ou la comptabilité d'un nœud qui fuit sur un autre.

Dans Zaris cette unité est un seul type — StoredRecord — et il vaut la peine de le démonter champ par champ, car chaque décision qu'il contient est porteuse. Cet article est l'anatomie : ce qu'il y a dans l'enregistrement, comment il est encadré sur le fil, pourquoi une suppression voyage comme un enregistrement au lieu d'une absence, pourquoi il y a deux numéros de version différents, et — tout aussi important — ce qui est délibérément laissé sur chaque nœud et ne traverse jamais le fil du tout.

Une charge utile, partout​

Un store clé/valeur a un nombre surprenant d'endroits où « une valeur » doit être décrite précisément : la map en mémoire, le flux de réplication, le snapshot de migration, le log d'opérations. Zaris utilise la même forme d'enregistrement pour tous. La chose posée dans le dictionnaire du segment est la même chose qu'un réplica reçoit, est la même chose qu'un nouveau propriétaire reçoit pendant le cut-over. Cette uniformité est pourquoi le log d'opérations peut faire deux travaux à la fois et pourquoi un snapshot de migration et un backfill de réplica n'ont pas besoin d'encodages séparés.

Voici le type entier, réduit à sa surface de fil :

[MessagePackObject]
public class StoredRecord
{
    [Key(0)] public ZarisEntry Entry { get; set; }     // key + value + metadata
    [Key(1)] public Revision Revision { get; set; }    // segment-wide ordering
    [Key(2)] public ItemVersion Version { get; set; }  // per-key CAS version
    [Key(3)] public DateTime TimestampUtc { get; set; }
    [Key(4)] public bool IsDeleted { get; set; } = false;  // tombstone flag

    [IgnoreMember] public long AccountedBytes { get; set; }      // node-local
    [IgnoreMember] public object? MaterializedValue { get; set; } // node-local
}

Cinq champs traversent le fil. Deux autres vivent sur l'objet mais sont marqués [IgnoreMember] et ne voyagent jamais. Le reste de cet article explique pourquoi chacun est là où il est.

L'encadrement : MessagePack avec clés positionnelles​

Zaris sérialise les enregistrements avec MessagePack, et les attributs [Key(N)] sont la raison pour laquelle le fil reste petit. MessagePack peut sérialiser un objet de deux façons : comme une map de nom-de-champ → valeur (auto-descriptive, mais chaque message répète chaque nom de champ en chaîne), ou comme un tableau positionnel où chaque champ est identifié par un index entier. Les attributs [Key(0)], [Key(1)], … sélectionnent la forme tableau. Sur le fil, un enregistrement est un court tableau de valeurs dans un ordre fixe — pas de noms de champs, pas de ponctuation style JSON, juste les charges utiles.

Cela compte parce que cet enregistrement est la structure de données chaude de tout le système. Il est sérialisé à chaque écriture répliquée et à chaque clé migrée ; à des centaines de milliers d'écritures par seconde, la différence entre expédier "TimestampUtc" comme une chaîne un million de fois et n'expédier que la position n'est pas une micro-optimisation, c'est le budget.

Le schéma positionnel fixe aussi la règle pour faire évoluer le format en toute sécurité : les clés entières sont en ajout seul (append-only). Un nouveau champ reçoit le prochain index inutilisé ; les index existants ne changent jamais de sens. Un nœud plus ancien qui ne connaît pas l'index 7 l'ignore simplement ; un nœud plus récent lisant un ancien enregistrement trouve l'index 7 absent et retombe sur une valeur par défaut. Nous verrons un champ — les labels à la clé de map 3 à l'intérieur des métadonnées — qui s'appuie sur exactement ce comportement « absent signifie défaut » pour ne rien coûter quand il n'est pas utilisé.

À l'intérieur de l'entry : clé, valeur et métadonnées non nulles​

ZarisEntry est le champ Entry — la partie qu'un utilisateur reconnaîtrait comme « ses données » :

[MessagePackObject]
public class ZarisEntry
{
    [Key(0)] public string Key { get; set; } = string.Empty;
    [Key(1)] public object Value { get; set; } = default!;
    [Key(2)] public EntryMetadata Metadata { get; }  // getter guarantees non-null
}

Deux détails ici sont le genre de chose qu'on n'apprend qu'en se brûlant une fois. D'abord, Value est typé object, pas byte[] ni string — la forme concrète de la valeur est ce que le rédacteur y a mis, encadrée à l'intérieur de l'entry, ce qui est comment le même type d'enregistrement transporte une simple chaîne, un compteur ou une collection répliquée entière sans que l'enregistrement ait besoin de savoir laquelle.

Ensuite, Metadata est servie via un getter qui ne peut jamais renvoyer null :

private EntryMetadata? _metadata;
[Key(2)]
public EntryMetadata Metadata
{
    get => _metadata ??= new EntryMetadata();
    set => _metadata = value;
}

MessagePack contourne le constructeur pendant la désérialisation et appelle directement les setters, donc un simple initialiseur = new() ne survivrait pas à un aller-retour — un enregistrement arrivé sans métadonnées se désérialiserait avec une métadonnée null, et chaque site d'appel en aval aurait besoin d'une vérification de null. Le getter rend la garantie structurelle à la place : les métadonnées sont toujours là, même quand le fil n'en a porté aucune. Un seul endroit pour imposer l'invariant, zéro garde de null partout ailleurs.

Des métadonnées qui ne coûtent rien quand elles sont vides​

EntryMetadata porte les attributs optionnels d'une clé — CreatedAt, Ttl, ContentType, un bail ou verrou optionnel, et des labels. Le champ des labels est une petite leçon magistrale sur l'art de ne pas payer pour ce qu'on n'utilise pas. La plupart des clés n'ont pas de labels, et un Dictionary naïf initialisé par entry est du pur gaspillage — dans un store réel, 390 000 entrées sans label détenaient chacune un dictionnaire vide de 80 octets, environ 31 Mo de rien.

La correction a deux faces. Sur le heap, les entrées sans label partagent un unique dictionnaire vide statique, de sorte que les lecteurs voient toujours une map non nulle (vide) mais n'allouent rien. Sur le fil, la surface sérialisée est null quand il n'y a pas de labels :

[Key(3)]
public Dictionary<string, LabelValue>? LabelsSerialized
{
    get => _labels != null && _labels.Count > 0 ? _labels : null;
    set => _labels = value != null && value.Count > 0 ? value : null;
}

Une entrée sans label écrit nil à l'index 3 et le lecteur en restaure « pas de labels ». C'est le schéma de clés append-only qui gagne sa place : le cas courant coûte un octet, et la fonctionnalité est là en entier à l'instant où une clé a réellement besoin d'un label.

Deux nombres, deux travaux : Revision et ItemVersion​

Le point de confusion le plus courant à propos des enregistrements Zaris est qu'ils portent deux nombres monotones croissants. Ils ne sont pas redondants — ils répondent à des questions différentes, et les confondre casserait l'un ou l'autre travail.

ItemVersion est par clé. Il démarre à 1 et s'incrémente de un chaque fois que cette clé est écrite. C'est le nombre que le client voit et le nombre contre lequel le compare-and-swap optimiste vérifie : « ne valide que si cette clé est toujours à la version 7 ». Quand le store applique un put, la nouvelle version est simplement la version de l'ancienne clé plus un :

long newVersion = (existing?.Version.Version ?? 0) + 1;

Revision est par segment. C'est un unique compteur partagé par chaque clé de la partition, incrémenté à chaque écriture et à chaque suppression :

revision = new Revision(Interlocked.Increment(ref _storeRevision));

Cela fait de Revision un ordre total sur toutes les mutations d'un segment, ce qui est exactement ce dont la réplication et la récupération ont besoin. Un réplica se moque que la clé user:1 en soit à sa 7e version ; ce qui l'intéresse est quelles révisions à l'échelle du segment il a déjà vues afin de pouvoir demander tout ce qui suit ce point. Le log d'opérations est indexé par révision, le protocole de rattrapage demande « tout après la révision R », et la résolution de conflit entre un enregistrement entrant et un enregistrement local compare les révisions, pas les versions par clé :

// An incoming record older than what we already hold is stale — ignore it.
if (existing is not null && existing.Revision.Value >= record.Revision.Value)
    return;

Donc : ItemVersion est l'unité de la concurrence optimiste visible par le client sur une clé ; Revision est l'unité de l'ordonnancement et de la convergence inter-nœuds sur tout le segment. Même enregistrement, deux horloges, chacune faisant un travail que l'autre ne peut pas.

Une suppression est un enregistrement, pas une absence​

Voici le champ qui surprend le plus : IsDeleted. Quand vous supprimez une clé dans Zaris, le store ne retire pas simplement l'entrée de son dictionnaire. Il écrit un StoredRecord avec IsDeleted = true — une pierre tombale (tombstone) — l'estampille de la prochaine révision du segment, et l'ajoute au log d'opérations comme une suppression :

var revision = new Revision(Interlocked.Increment(ref _storeRevision));
_deleteRevisions[key] = revision.Value;
AppendOperationLog(revision.Value, key, ReplicationOperation.Delete, new StoredRecord
{
    // ...
    Revision = revision,
    IsDeleted = true,
});

La raison est tout l'enjeu du format d'enregistrement. Si une suppression n'était qu'une absence — la clé disparaissant discrètement d'une map — il n'y aurait rien à répliquer. Un réplica qui a manqué le moment de la suppression continuerait de servir l'ancienne valeur à jamais, car « rien » ne voyage pas et ne peut pas être ordonné par rapport aux écritures qui l'entourent. En faisant de la suppression un enregistrement de première classe avec sa propre révision, la suppression circule par le même chemin de réplication et de rattrapage qu'une écriture, et se glisse dans l'ordre total du segment à la bonne place.

Les pierres tombales défendent aussi contre une défaillance plus subtile : une écriture périmée ressuscitante. Imaginez une suppression à la révision 50 et un put plus ancien pour la même clé, révision 48, encore en vol à travers le réseau. Sans mémoire de la suppression, le put tardif atterrirait et ramènerait la clé d'entre les morts. Zaris enregistre la révision de suppression et rejette tout ce qui lui est antérieur ou égal :

private bool HasDeleteRevisionAtOrAfter(string key, long revision)
    => _deleteRevisions.TryGetValue(key, out var deleteRevision)
       && deleteRevision >= revision;

Le revers des pierres tombales est qu'elles ne peuvent pas s'accumuler à jamais, sinon une charge à forte suppression fuirait de la mémoire. Zaris élague les révisions de suppression une fois qu'elles sont en sécurité en dessous de la plus ancienne révision dont un réplica a encore besoin — la même logique de low-water-mark qui élague le log d'opérations — de sorte que la pierre tombale fait son travail de convergence puis est récupérée. (La discipline d'élagage fait l'objet de l'article sur le log d'opérations.)

Ce qui reste à la maison : les champs [IgnoreMember]​

Les deux champs que l'enregistrement porte mais ne sérialise jamais sont aussi délibérés que les cinq qu'il sérialise. Les deux sont marqués [IgnoreMember], et les deux sont node-local par conception — corrects seulement pour le nœud qui les a calculés.

AccountedBytes est la mémoire dont cet enregistrement est débité contre le budget du store, estampillée une fois au moment de l'écriture pour que le store puisse rapporter les deltas d'octets sans remesurer l'enregistrement précédent. Elle n'est explicitement pas sérialisée, car chaque nœud la calcule à partir de la clé et de la valeur de l'enregistrement sous ses propres règles de comptabilité. Si elle chevauchait le fil, un enregistrement répliqué depuis le nœud A porterait l'estimation d'octets de A sur les comptes du nœud B — la comptabilité d'un nœud faussant silencieusement celle d'un autre. La garder [IgnoreMember] signifie que chaque nœud la recalcule indépendamment, et un enregistrement arrivant par réplication ou migration est comptabilisé par le nœud qui le détient désormais.

MaterializedValue est une forme en mémoire vivante, construite paresseusement, d'une collection native (un hash, une list, un set ou un sorted set) mise en cache pour que les opérations par élément ne re-désérialisent pas toute la valeur à chaque fois. C'est de la pure accélération locale. La forme faisant autorité est toujours les octets de valeur encadrés à l'intérieur d'Entry ; un enregistrement qui arrive d'un autre nœud matérialise ce cache paresseusement au premier accès. Le sérialiser reviendrait à expédier l'état de brouillon privé d'un nœud comme s'il s'agissait de données.

La discipline ici est nette et vaut la peine d'être énoncée à voix haute : le fil porte la vérité, le nœud porte les commodités. Tout ce qu'un nœud peut recalculer depuis l'enregistrement lui-même — son coût mémoire, sa structure matérialisée — reste local et est marqué [IgnoreMember]. Tout ce qui fait partie de l'identité et de l'ordonnancement de l'enregistrement — clé, valeur, métadonnées, les deux numéros de version, le drapeau de pierre tombale — traverse le fil. La frontière des attributs est exactement la frontière vérité/commodité, et la garder nette est ce qui rend l'enregistrement sûr à copier entre nœuds sans y repenser à deux fois.

Pourquoi c'est testable, et testé​

Parce que la forme de l'enregistrement est porteuse pour la convergence, son comportement sur le fil est épinglé par des tests plutôt que laissé à l'inspection. Deux invariants en particulier gagnent leurs propres assertions : le drapeau de pierre tombale doit survivre à un aller-retour (un IsDeleted perdu ressuscite une clé supprimée sur un réplica), et AccountedBytes doit revenir à zéro après un aller-retour (prouvant qu'il n'a jamais voyagé) :

back.IsDeleted.Should().BeTrue(
    "a dropped tombstone flag resurrects a deleted key on the replica");

back.AccountedBytes.Should().Be(0,
    "AccountedBytes is [IgnoreMember]; each node recomputes it, it must not cross the wire");

Ces assertions se lisent presque comme la thèse de tout l'article écrite sous forme d'assertions : les choses qui doivent traverser le fil sont prouvées y survivre, et celles qui ne le doivent pas sont prouvées disparaître.

L'enregistrement est le contrat​

Il est facile de penser que les problèmes difficiles d'un store distribué vivent dans les parties élégantes — le protocole de basculement, la poignée de main de cut-over, le test du chaos. C'est vrai. Mais ces protocoles ne sont corrects que dans la mesure où la chose qu'ils déplacent l'est, et la chose qu'ils déplacent est ce petit enregistrement unique. Une pierre tombale au lieu d'une absence est pourquoi une suppression converge. Deux numéros de version sont pourquoi la concurrence optimiste d'une clé et l'ordonnancement de tout un segment restent démêlés. Des clés MessagePack positionnelles sont pourquoi le chemin chaud reste bon marché et le format peut quand même grandir. Et une paire de champs [IgnoreMember] sont pourquoi la réplication peut copier un enregistrement entre nœuds et avoir confiance que rien de node-local n'est venu faire le voyage.

Obtenez la bonne unité de données et les grands protocoles ont quelque chose de solide sur quoi se tenir. C'est tout l'argument pour consacrer un article de blog à cinq champs et deux qui restent à la maison.

Voici un résultat de benchmark qui ressemble à une contradiction. Un nœud Zaris servant une charge majoritairement en lecture plafonne à un peu moins d'un demi-million d'ops/s et refuse de grimper — ajoutez plus de connexions client, plus de générateurs de charge, et le nombre ne bouge pas. Le diagnostic évident est « il est saturé ». Sauf que le graphe de CPU dit le contraire : le nœud est posé à environ un quart de son CPU disponible. Trois cœurs sur quatre sont inactifs, et le débit est plat.

Ce n'est pas un nœud limité par les cœurs, et — si vous l'avez écarté avec soin — ce n'est pas non plus un benchmark limité par le client. C'est une troisième chose, et c'est un classique : le worker pool de dispatch des requêtes était plus étroit que le travail ne le voulait, donc les requêtes faisaient la queue pendant que les cœurs se tournaient les pouces.

D'abord, écartez les suspects habituels​

Deux explications doivent partir avant que celle-ci ne soit même sur la table, car elles sont bien plus courantes.

Limité par les cœurs. Si le nœud est à ou près de 100 % de CPU et que le débit est plat, vous êtes véritablement à court de CPU — la réponse est plus de cœurs ou plus de nœuds, et Zaris met à l'échelle les lectures en ajoutant des cœurs. Ce n'est pas ce cas : ici le CPU est inactif.

Limité par le client. Un seul générateur de charge sature bien avant le serveur, et alors vous mesurez votre client, pas Zaris. Si le débit est plat quand vous ajoutez des cœurs serveur, suspectez d'abord votre client — ajoutez des générateurs et des connexions jusqu'à ce que le nombre côté serveur réponde réellement. Nous avons couvert ce piège dans l'article sur les lectures, et c'est celui à éliminer avant d'aller plus loin.

Ce qui reste après ces deux-là est le cas intéressant : assez de charge offerte pour garder le nœud occupé, beaucoup de marge de CPU, et un débit toujours plat. Quand le goulet d'étranglement est à l'intérieur du serveur mais que ce n'est pas le CPU, la chose à regarder est la concurrence — combien de requêtes le nœud traitera en même temps.

Le pool de dispatch est la limite de concurrence​

Chaque requête qui arrive à un nœud Zaris est remise à un worker pool de dispatch de requêtes. Un worker la ramasse, la route vers la partition qui possède la clé, exécute l'opération contre le store en processus de cette partition, et réécrit la réponse. Pour une lecture, l'opération elle-même est une recherche en mémoire à l'échelle de la microseconde — véritablement minuscule.

La largeur de ce pool — combien de workers peuvent être en pleine requête simultanément — fixe un plafond dur sur les requêtes en vol, et c'est un nombre différent de « à quelle vitesse va une opération ». La valeur par défaut d'origine dérivait la largeur d'un petit multiple de Environment.ProcessorCount. Sur un nœud à 4 vCPU, un pool à quelques fois les cœurs n'est qu'une poignée de workers.

Voici la subtilité qui fait paraître le graphe de CPU faux. Si chaque worker passait toute sa tranche à brûler du CPU sur la recherche, un pool dimensionné aux cœurs serait exactement juste et le nœud atteindrait 100 % de CPU. Mais les workers ne passent pas toute leur tranche sur le CPU. Un worker se met occasionnellement en pause — une continuation await, une écriture de socket qui ne se termine pas de façon synchrone, un bref verrou sur une structure partagée. Un worker en pause ne brûle aucun CPU, mais il garde quand même son emplacement de pool. Avec seulement une poignée d'emplacements, quelques workers en pause suffisent à bloquer tout le nœud : les nouvelles requêtes font la queue derrière eux, et parce que les workers occupés attendent surtout plutôt que de calculer, les cœurs ne s'allument jamais. Débit plat, CPU inactif. La largeur du pool était le plafond, pas le silicium.

L'indice qui distingue cela d'un benchmark limité par le client : les requêtes font la queue au serveur (la latence grimpe, le débit est plat) pendant que le CPU serveur reste bas. Le cas limité par le client a l'air différent — le serveur est inactif parce que rien n'arrive assez vite. Ici, le travail arrive ; le nœud refuse juste d'en prendre assez à la fois.

La correction : dimensionner le pool pour le travail, pas pour le nombre de cœurs​

La réparation n'est pas exotique. Les lectures sont des recherches en mémoire à la microseconde, donc le pool devrait être fixé large par défaut — assez large pour qu'une poignée de workers en pause ne puisse pas affamer le nœud — et il devrait être réglable, car la bonne largeur dépend du nœud et de la charge, pas d'un multiple fixe du nombre de cœurs.

La largeur de pool par défaut est désormais nombre de CPU × 16, bornée dans une plage saine de 64 à 1024, avec un plancher de max(4, nombre de CPU × 4). Deux variables d'environnement la remplacent :

# A node with spare CPU and requests queuing — widen the pool.
ZARIS_SERVER_MAX_WORKERS=512 ZARIS_SERVER_MIN_WORKERS=64 \
  dotnet Clustron.Zaris.Server.dll

Une propriété qui mérite d'être soulignée : c'est un changement côté serveur et rien d'autre. Le protocole de fil ne change pas, le SDK client ne change pas, et il n'y a pas de bump NuGet à poursuivre — vous réglez un nœud en le redémarrant avec un environnement différent, et chaque client existant continue de lui parler sans changement.

Réglez-le honnêtement — élargir n'est pas gratuit​

Le réflexe après avoir lu ceci est de pousser ZARIS_SERVER_MAX_WORKERS au plafond sur chaque nœud. Ne le faites pas. Un pool plus large aide dans exactement une situation et ne fait rien — ou nuit légèrement — dans les autres.

• Il aide quand les requêtes font la queue pendant que le CPU est inactif. C'est le cas de tout cet article : la concurrence en vol est la limite, donc en admettre davantage remplit les cœurs. C'est là que vous verrez le débit bondir.
• Il ne fait rien quand vous êtes déjà limité par le CPU. Si le nœud est à 100 % de CPU, plus de workers ne feront pas surgir du débit de nulle part — ils ajoutent juste de la surcharge de changement de contexte à une machine qui n'a aucun cycle en réserve. Plus de workers n'est pas plus de calcul.
• Il peut nuire si vous le poussez à une largeur absurde. Des milliers de workers malmenant un nœud à 2 vCPU passent du vrai temps à changer de contexte au lieu de servir. C'est pourquoi il y a une borne, et pourquoi le bouton plafonne à 4096 plutôt qu'à l'infini.

La boucle de réglage honnête est : guetter la signature — latence qui grimpe et débit plat pendant que le CPU est bien en dessous de la saturation — relever MAX_WORKERS, et mesurer. Si le CPU grimpe et que le débit suit, le pool était votre plafond. Si rien ne bouge, ce n'était pas lui, et vous devriez remettre le bouton et chercher ailleurs (le chemin réseau, le client, ou un besoin véritable de plus de nœuds).

Mesurez le CPU là où c'est réellement vrai​

Toute cette enquête repose sur la confiance dans le nombre de CPU, et ce nombre est facile à obtenir faux.

• Lisez le CPU depuis le cgroup, pas depuis une estimation de metrics-server de cluster. Sur Kubernetes surtout, le chiffre du metrics-server est en retard et lissé — il vous dira qu'un nœud est à 40 % alors que la comptabilité du cgroup dit qu'il est saturé, ou l'inverse. Diagnostiquez un cas « débit plat, CPU inactif » depuis le cgroup, ou vous poursuivrez un nombre qui n'est pas réel.
• Les benchmarks locaux sont limités par l'hôte et cacheront le plafond. Sur un ordinateur portable, le générateur de charge et le serveur se disputent les mêmes cœurs, donc vous ne présentez jamais au serveur une charge propre et suffisante — le plateau que vous mesurez est votre banc d'essai, pas Zaris. Le vrai plafond du worker pool est apparu à l'échelle sur un cluster managé avec la charge pilotée depuis des machines séparées, pas sur une machine de développeur. Validez le débit là où le client ne peut pas être le goulet d'étranglement.

À retenir​

Une courbe de débit plate a trois causes très différentes, et le graphe de CPU vous dit laquelle vous regardez. À 100 % de CPU, vous êtes limité par les cœurs — ajoutez des nœuds. Avec le serveur inactif parce que rien n'arrive assez vite, vous êtes limité par le client — corrigez le test. Mais un nœud plat au quart de son CPU, avec des requêtes qui font visiblement la queue, n'est ni l'un ni l'autre : c'est une limite de concurrence, et sur Zaris c'est le worker pool de dispatch. La valeur par défaut est désormais assez large pour que la plupart des charges ne le rencontrent jamais, et ZARIS_SERVER_MAX_WORKERS est là pour celles qui le rencontrent — à relever délibérément, quand le graphe de CPU l'a mérité.

Pour la surface complète des variables d'environnement et les valeurs par défaut exactes, voir la référence de configuration. Si vous dimensionnez un cluster pour le débit, le guide de benchmarking parcourt les réglages qui font réellement bouger les nombres, et Des lectures qui montent avec vos cœurs couvre l'autre moitié de l'histoire — pourquoi, une fois le pool hors du chemin, ajouter des cœurs ajoute de la capacité de lecture au lieu de buter contre un mur à boucle d'événements unique.

Un basculement est le moment où un store distribué est le plus honnête sur ce qu'il est réellement. En régime permanent, tout store se ressemble : une écriture atterrit sur un propriétaire, est acquittée, vous passez à la suite. La conception ne se montre que lorsque le propriétaire disparaît au milieu d'une phrase — un nœud détient la copie active de l'une de vos partitions, des écritures y atterrissent à l'instant même, puis il n'est plus là. Tué net. Partitionné par le réseau. OOM. Le cluster a quelques secondes pour s'en apercevoir, s'accorder sur un nouveau propriétaire et faire repartir le trafic — et le fait de s'y prendre correctement décide si votre écriture acquittée survit ou s'évapore discrètement.

Cet article suit cette séquence de bout en bout, dans l'ordre où Zaris l'exécute réellement, et nomme les cas où la réponse est véritablement « l'écriture est perdue » — car un article sur le basculement qui ne décrit que le chemin heureux ne vaut pas la lecture.

L'unique invariant qui rend le reste traitable​

Avant la chronologie, l'unique décision de conception dont tout le reste dépend : Zaris sépare la carte de partitions du runtime de partitions.

La carte de partitions est l'affectation lente et délibérée — quels nœuds sont responsables de la partition P : un primaire préféré et ses réplicas. Elle ne change que lors d'événements topologiques réels (un nœud rejoint ou quitte définitivement, une montée en charge, un rééquilibrage) et elle change par une régénération planifiée et versionnée.

Le runtime est la réponse rapide et vivante à une question différente — quel nœud affecté est le propriétaire actif servant P à l'instant présent, et dans quelle santé. Pendant un basculement, la carte ne bouge pas du tout. Seul le primaire actif du runtime bouge. C'est l'invariant énoncé dans le service de basculement lui-même : un signal de défaillance indépendant ouvre la barrière de basculement du runtime, « PartitionMap remains stable and only PartitionRuntimeMap.Active is allowed to move during failover. »

Pourquoi cela importe : régénérer une carte de partitions est coûteux et dangereux — cela peut rebrasser des partitions saines et déclencher une migration de données. Un nœud qui meurt ne devrait pas déclencher cela. Il devrait déclencher une décision de runtime bon marché et locale : choisir un réplica survivant de la même partition et en faire le primaire actif. La carte dit toujours « P est possédé par n1, n2, n3 » ; le runtime bascule de « actif = n1 » à « actif = n2 ». Garder ces deux plans séparés est ce qui permet au basculement d'être rapide sans être téméraire.

Étape 1 — détecter, mais ne pas croire la première rumeur​

Le basculement est coordonné par le leader. Un nœud du cluster est le leader élu, et seul le leader promeut — un non-leader qui entend un événement node-left l'ignore simplement. Cela évite que deux nœuds n'élisent indépendamment deux nouveaux propriétaires différents pour la même partition.

Lorsque le leader reçoit un signal NodeLeft pour un nœud, il ne promeut pas immédiatement des réplicas pour chaque partition que ce nœud possédait. La promotion est désignée dans le code comme « an irreversible, high-impact action », et elle est protégée :

if (string.Equals(activeOwner, nodeId, StringComparison.Ordinal))
{
    // A NodeLeft message can race ahead of the peer-table update.
    // If the "dead" owner is in fact still reachable, do NOT fail it over.
    if (IsNodeAlive(nodeId))
    {
        Log.NodeUnavailableRejectedReachable(/* ... */);
        continue;
    }
    await PromoteOrMarkUnavailableAsync(partition, nodeId, runtime, ct);
}

La garde existe parce que le message de défaillance et la table de pairs de la couche d'appartenance se mettent à jour de façon asynchrone. Un NodeLeft peut arriver un battement de cœur avant que la table de pairs ne le reflète — ou être tout simplement faux. Donc, avant l'action à fort impact, le leader revérifie directement la vivacité. Un propriétaire « mort » encore joignable est laissé exactement où il est.

Il existe un second chemin, plus lent, pour le cas que le premier ne peut pas couvrir : un propriétaire actif devenu silencieux sans un NodeLeft propre. Un balayage de réconciliation périodique (HandleUnavailableActiveOwnersAsync) parcourt chaque partition, et pour un propriétaire qui n'est pas vivant mais n'a pas été confirmé en panne, il démarre une minuterie de suspicion plutôt que d'agir :

var suspectedSince = _suspectedUnavailableSinceUtc.GetOrAdd(activeOwner, _ => DateTime.UtcNow);
if (DateTime.UtcNow - suspectedSince < _suspectEscalationTimeout)
{
    Log.UnconfirmedActiveOwnerFailure(/* ... */);
    continue;   // not yet — give it until the escalation timeout
}
ConfirmNodeUnavailable(activeOwner, "RuntimeOwnershipSuspectEscalationTimeout");

Ce n'est qu'après que le propriétaire a été injoignable pendant toute la fenêtre d'escalade (dix secondes par défaut) que le leader le confirme en panne et poursuit. La conception est délibérément asymétrique : marquer une partition dégradée pour perte de réplica est bon marché et réversible, donc cela se déclenche immédiatement ; promouvoir un nouveau primaire actif est irréversible, donc cela attend une preuve.

Étape 2 — choisir un survivant, et incrémenter l'époque​

Une fois le propriétaire confirmé en panne, le leader choisit un réplica à promouvoir. La sélection est disponibilité d'abord : parmi les réplicas affectés de la partition, il préfère celui qui a synchronisé le plus de segments — le nœud le plus susceptible de pouvoir servir bientôt.

La promotion elle-même est une unique diffusion qui fait avancer une époque par partition :

var nextEpoch = GenerateNextEpoch(partition.PartitionId, runtime, "ReplicaPromotion");
// ...
await _runtimeOwnership.BroadcastAsync(
    partition.PartitionId, promotedNodeId, nextEpoch.Value, promotionState, ct);

L'époque est le jeton de protection, et c'est le héros discret de tout le mécanisme. Elle est monotone par partition, et le générateur refuse de revenir en arrière — une époque proposée qui n'est pas strictement supérieure à la plus haute déjà observée est rejetée d'emblée :

var nextEpoch = baseEpoch + 1;
if (nextEpoch <= highestObservedEpoch)
{
    Log.StaleEpochGenerationRejected(/* ... */);
    return null;   // never regress ownership
}

Ainsi, après la promotion, le primaire actif de la partition est « n2 à l'époque 8 ». Si l'ancien propriétaire n1 était simplement partitionné (pas mort) et revient en pensant qu'il est toujours le primaire actif à l'époque 7, son époque périmée perd toutes les comparaisons. Il ne peut pas récupérer la propriété, et toute écriture qu'il essaie d'accepter en tant que « actif » est écartée. C'est ainsi que Zaris évite le split-brain à deux primaires qui laisserait sinon un ancien propriétaire guéri-mais-confus accepter des écritures que personne ne reverra jamais.

Étape 3 — la preuve de possession : servir, ou se synchroniser d'abord ?​

Voici la partie subtile, et celle qui a demandé un vrai débogage pour être correcte. Ayant choisi le réplica le plus disponible, peut-il réellement commencer à servir les lectures immédiatement ?

Pas nécessairement — car « le plus de segments synchronisés » n'est pas la même chose que « détient chaque clé acquittée ». Un réplica peut être à jour sur le nombre de segments tout en étant encore en retard sur les vraies données des segments qu'il détient. Promouvez un tel nœud directement vers un état servant et il devient un primaire actif incomplet : il répond NotFound pour des clés qui étaient durablement acquittées sur le propriétaire mort et qui existent sur un frère plus complet. C'est une perte de données silencieuse déguisée en lecture réussie.

Donc, avant que le nœud promu ne soit autorisé à servir, Zaris applique une preuve de possession. Le leader tient une table fraîche, alignée sur le terme, du nombre de clés que chaque nœud déclare détenir pour la partition. La règle est une pure comparaison :

public static PartitionHealthState ResolvePromotionState(
    long candidateHeldKeys, long bestOtherLiveHolderKeys)
    => bestOtherLiveHolderKeys > candidateHeldKeys
        ? PartitionHealthState.Recovering   // a more-complete live peer exists: sync first, do NOT serve
        : PartitionHealthState.Degraded;    // candidate is the authority: serve now

Deux issues :

• Aucun détenteur vivant strictement plus complet n'existe — le candidat est le nœud le plus complet, ou un véritable unique survivant n'ayant rien avec quoi se synchroniser. Il est promu en Degraded : un état servant. Il n'a rien de mieux à attendre, donc le bloquer en non-servant ne ferait que rendre la partition inutilement indisponible. Il sert immédiatement.
• Un détenteur vivant strictement plus complet existe — le candidat est promu en Recovering : un état non servant. Il se synchronise d'abord depuis cette meilleure source et ne commence à servir qu'une fois sa complétude prouvée. On dit aux clients que la partition est encore en train de démarrer plutôt que de leur remettre un nœud qui leur mentirait.

La distinction entre Degraded et Recovering est exactement la distinction entre « la redondance est réduite mais la vérité est servie » et « ne faites pas encore confiance à ce propriétaire pour les lectures ». Amener correctement un unique survivant en Degraded importe tout autant que maintenir un nœud incomplet en Recovering — une unique copie restante ne doit jamais être bloquée en non-servant pour toujours simplement parce que c'est la seule copie qui reste.

Une note rapide sur l'honnêteté : cette preuve est fondée sur le décompte, tirée des rapports de clés détenues par nœud avec un filigrane de fraîcheur (un rapport d'un nœud devenu silencieux n'est pas compté comme source vivante). C'est une garde forte et bon marché contre la promotion d'un nœud manifestement en retard pour servir ; ce n'est pas une attestation cryptographique que deux nœuds détiennent des données identiques octet pour octet. La convergence qui rend les copies réellement identiques est le chemin de synchronisation des réplicas, couvert ci-dessous.

Étape 4 — le client redirige, et votre nouvelle tentative atterrit​

Pendant que tout cela se produit sur le serveur, que voit le client qui était en pleine écriture ?

Il voit la vérité, sous forme de statut typé. Une requête qui atteint l'ancien propriétaire (désormais écarté, ou simplement parti) ne reste pas suspendue et ne lève pas d'erreur vague — elle revient en Moved ou OwnershipChanging. Le client Zaris traite ceux-ci comme des signaux de redirection réessayables : il rafraîchit sa carte de propriété, découvre le nouveau primaire actif et rejoue l'opération là-bas. Dans le cas courant, votre PutAsync prend simplement quelques millisecondes de plus et renvoie Ok — face au propriétaire nouvellement promu, à la nouvelle époque. Le code de l'application n'apprend jamais que le propriétaire a bougé.

Cette mécanique côté client — la taxonomie des statuts, la nouvelle tentative avec budget-de-tentatives-et-échéance, le rafraîchissement de la carte — est une histoire en soi, racontée dans Les tentatives que vous n'écrivez pas. Pour cet article, le point est simplement que l'incrément d'époque du serveur et la redirection du client sont les deux moitiés d'un seul transfert : le serveur rend l'ancien propriétaire non-autoritaire, et le client cesse de lui parler.

Étape 5 — converger, puis guérir jusqu'à Healthy​

La promotion restaure la disponibilité ; elle ne restaure pas la redondance. Juste après un basculement, la partition tourne en Degraded avec une copie de moins que sa cible. Deux choses se produisent alors en arrière-plan.

D'abord, le nœud promu (s'il est monté en Recovering) ainsi que tout réplica en retard ou de retour rattrapent en rejouant le journal d'opérations par segment depuis une révision connue — le même substrat rejouable qui pilote la réplication ordinaire. Un nœud qui vient d'hériter du rôle actif et un réplica simplement en retard convergent par le mécanisme identique ; c'est le sujet de Un journal, deux rôles.

Ensuite, une fois que chaque participant affecté est de nouveau vivant et synchronisé, le balayage de récupération du leader fait repasser la partition en Healthy — mais uniquement via la même diffusion qui fait avancer l'époque, et uniquement après une courte temporisation afin qu'un nœud instable ne puisse pas entraîner le runtime à travers une tempête de transitions. La machine à états de santé est donc une petite boucle fermée : Healthy → Degraded/Recovering → Healthy, chaque arête un incrément d'époque, chaque promotion protégée.

Si aucun réplica éligible ne survit du tout — chaque nœud affecté à la partition est en panne — le leader fait la seule chose honnête : il marque la partition Unavailable (aucun propriétaire, aucune fausse promotion) et démarre un compte à rebours d'éviction qui, si personne ne revient à temps, laisse une régénération de carte planifiée reloger la partition. Une partition Unavailable échoue bruyamment les lectures et écritures plutôt que de servir un mensonge.

Là où une écriture est véritablement perdue — énoncé clairement​

Un mécanisme de basculement gagne la confiance en étant précis sur ses limites, et non en laissant entendre qu'il n'y en a pas.

• Facteur de réplication 1. Une partition avec une unique copie et aucun réplica n'a rien à promouvoir. Lorsque ce nœud meurt, la partition passe en Unavailable jusqu'à son retour ; les données ne sont pas perdues (elles sont dans la mémoire de ce nœud) mais elles sont indisponibles, et si le nœud ne revient jamais, elles sont disparues. Le RF1 est non durable par conception — c'est un choix délibéré pour des données que vous pouvez vous permettre de perdre, pas une garantie que le chemin de basculement peut sauver.
• Acquittement asynchrone. Zaris permet qu'une écriture soit acquittée sur le propriétaire actif avant qu'elle n'ait atteint un réplica, pour la latence. C'est le chemin rapide — et son coût honnête est une fenêtre : si le primaire actif meurt dans l'intervalle entre l'acquittement au client et l'arrivée de l'opération sur un détenteur survivant, cette écriture acquittée est perdue. La preuve de possession vous protège de la promotion pour servir d'un nœud connu en retard ; elle ne peut pas faire apparaître une opération qui n'a jamais quitté le nœud mort. Si vous avez besoin qu'une écriture survive à la perte de son propriétaire, elle ne doit être acquittée qu'après être durable sur un réplica — le chemin synchrone échange un peu de latence contre exactement cette garantie. Choisissez par charge de travail, les yeux ouverts.
• La fenêtre de confirmation elle-même. Pendant le délai d'escalade après qu'un propriétaire devient silencieux, les écritures de la partition sont dans les limbes — réessayées par le client, pas encore en train d'atterrir sur un nouveau propriétaire. La correction est préservée (rien n'est promu à tort), mais la disponibilité baisse pendant cette fenêtre. Resserrer le délai échange un basculement plus rapide contre davantage de fausses promotions sous des hoquets transitoires ; c'est un cadran, pas un repas gratuit.

Aucun de ces cas n'est un bug que le chemin de basculement peut concevoir pour l'éliminer — ce sont les véritables compromis entre disponibilité, durabilité et latence, et le travail de Zaris est de faire du choix sûr le défaut et du choix rapide l'explicite, jamais de prétendre que la fenêtre n'existe pas.

La forme de la chose​

Réduisez le basculement à l'essentiel et ce sont quatre mouvements au-dessus d'un invariant. L'invariant : la carte reste immobile ; seul le primaire actif du runtime bouge. Les mouvements : confirmer la mort avant d'agir, promouvoir un survivant derrière une époque monotone qui écarte l'ancien propriétaire, prouver la possession pour que le nouveau propriétaire serve la vérité ou se synchronise avant de servir tout court, et rediriger le client pour que sa nouvelle tentative atterrisse sur le nouveau propriétaire. Puis converger les copies et guérir jusqu'à Healthy.

Que cela tienne n'est pas affaire d'argument — c'est mesuré. Le même chemin de promotion, de possession et de convergence s'exécute en continu sous un chaos délibéré de mise à mort de nœuds pendant des heures d'affilée, avec le registre vérifié pour une seule écriture acquittée perdue à la fin. Cette certification est sa propre histoire : Aucune écriture acquittée laissée pour compte.

La plupart des raisons de recourir à un cache distribué dans une application .NET ne mentionnent jamais un cache par son nom. Vous ajoutez du cache de sortie et il réclame un IDistributedCache. Vous activez les sessions et l'intergiciel réclame un store de secours. Vous activez le partage des clés de protection des données entre instances et, là encore, il réclame un endroit où mettre des octets que chaque nœud peut voir. Le code de l'application est écrit contre une abstraction ; la seule question est quelle implémentation vous enregistrez au démarrage.

Zaris répond à cette question avec trois petits paquets NuGet, chacun ciblant une couture ASP.NET Core spécifique : un IDistributedCache nu, un HybridCache à deux niveaux et un store de session. Vous enregistrez une ligne au démarrage et le reste de votre application — y compris les bibliothèques tierces qui ne connaissent que l'abstraction — met en cache sur un cluster Zaris sans un seul changement dans le code qui utilise le cache. Cet article passe en revue les trois, et est délibéré sur l'endroit où chacun s'arrête honnêtement.

Les trois paquets​

Les trois reposent sur le même client Zaris .NET. Ils n'inventent pas de canal parallèle — ils résolvent un client Zaris normal à partir d'une chaîne de connexion et traduisent Get/Set/Remove en GetAsync/PutAsync/DeleteAsync du client. Si vous avez lu Une chaîne de connexion, n'importe quelle plateforme, le câblage vous paraîtra familier : le cache n'est qu'un autre consommateur d'un store nommé.

1. Le IDistributedCache standard​

C'est le prêt-à-l'emploi. IDistributedCache est l'interface que Microsoft.Extensions.Caching.Abstractions expose depuis des années, et une grande partie de l'écosystème .NET — session, cache de sortie, stores de tickets d'authentification, bibliothèques tierces — dépend exactement de cette interface et de rien de plus. Enregistrez Zaris comme implémentation et tout cela est adossé à votre cluster.

builder.Services.AddClustronZaris("app-cache", "zaris://cache-host:7861/app-cache");

builder.Services.AddClustronDistributedCache(
    storeName: "app-cache",
    configure: o => o.KeyPrefix = "myapp:");

La première ligne enregistre un client Zaris sous la clé DI app-cache ; la seconde enregistre un IDistributedCache qui l'utilise. À partir de là, tout ce qui prend un IDistributedCache — y compris du code que vous n'avez pas écrit — fonctionne :

public sealed class WeatherController(IDistributedCache cache)
{
    public async Task<Forecast> Get(string city)
    {
        var cached = await cache.GetAsync($"forecast:{city}");
        if (cached is not null)
            return Deserialize(cached);

        var fresh = await FetchForecastAsync(city);
        await cache.SetAsync(
            $"forecast:{city}",
            Serialize(fresh),
            new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10)
            });
        return fresh;
    }
}

Sous le capot, GetAsync est un client.GetAsync<byte[]> avec le préfixe configuré appliqué, et un défaut de cache (la clé n'existe pas) renvoie null — exactement le contrat que l'interface promet. SetAsync avec AbsoluteExpirationRelativeToNow fait correspondre cette fenêtre directement à un TTL Zaris, de sorte que le store expire l'entrée pour vous.

Deux limites honnêtes​

Seule l'expiration absolue relative est prise en charge. Le IDistributedCache de Zaris lit AbsoluteExpirationRelativeToNow et le transforme en TTL. Si vous ne définissez aucune expiration, l'entrée est écrite sans TTL et vit jusqu'à être évincée ou écrasée. SlidingExpiration sur ce cache polyvalent n'est pas honoré — son Refresh/RefreshAsync est une opération nulle. C'est un choix de périmètre délibéré, pas un oubli : l'expiration glissante est une préoccupation de session, et le paquet de session ci-dessous l'implémente correctement plutôt que de la demi-implémenter ici.

Vous pouvez en enregistrer plusieurs, et le premier l'emporte par défaut. Chaque appel à AddClustronDistributedCache enregistre une instance de cache nommée liée à un store spécifique. Le premier enregistré devient le IDistributedCache à l'échelle de l'application ; passez setAsDefault: true pour faire d'un enregistrement ultérieur le défaut à la place. Si vous voulez plusieurs caches sur différents stores, résolvez-les explicitement via IClustronCacheProvider.GetCache("other-store") plutôt que de vous reposer sur le défaut ambiant.

2. HybridCache — un niveau en cours de processus devant le cluster​

L'abstraction plus récente HybridCache de .NET résout un problème que IDistributedCache vous laisse : la combinaison d'un cache local rapide (L1) et d'un cache distribué partagé (L2), plus la protection contre les ruées — s'assurer que, lorsqu'une clé populaire expire, une horde de requêtes concurrentes n'exécute pas toutes la fabrique coûteuse en même temps.

Zaris implémente directement la classe abstraite HybridCache. La particularité est que les deux niveaux sont des stores Zaris que vous nommez — vous pointez le L1 vers un store embarqué en cours de processus (aucun réseau, aucun saut de sérialisation hors machine) et le L2 vers le cluster distribué :

builder.Services.AddClustronZaris("l1", "zaris://inproc/l1");          // embedded, in-process
builder.Services.AddClustronZaris("l2", "zaris://cache-host:7861/l2"); // the cluster

builder.Services.AddClustronHybridCache(l1Store: "l1", l2Store: "l2");

Le chemin de lecture est la recherche classique à deux niveaux, et il vaut la peine d'être vu en entier car chaque garantie ci-dessous en découle :

var product = await cache.GetOrCreateAsync(
    $"product:{id}",
    state: id,
    factory: async (pid, ct) => await db.LoadProductAsync(pid, ct),
    options: new HybridCacheEntryOptions
    {
        Expiration = TimeSpan.FromMinutes(10),          // L2 TTL
        LocalCacheExpiration = TimeSpan.FromMinutes(1)  // L1 TTL (shorter)
    },
    tags: new[] { "catalog" });

Le L1 est vérifié en premier sans verrou. En cas de défaut, l'appelant prend un verrou par clé, revérifie le L1 (au cas où un autre appelant viendrait de le remplir), puis le L2 ; ce n'est que si les deux échouent qu'il exécute la fabrique, écrit le L2, puis écrit le L1. Les TTL proviennent de HybridCacheEntryOptions — Expiration pour le L2, LocalCacheExpiration pour le L1 — et l'implémentation borne le L1 pour qu'il ne soit jamais plus long que le L2, de sorte que vous ne pouvez jamais avoir une copie locale qui survit à la copie partagée. Omettez les options et les deux prennent par défaut cinq minutes.

Protection contre les ruées, mesurée​

Le verrou par clé est la protection contre les ruées. Le propre test du paquet déclenche vingt appels GetOrCreateAsync concurrents sur une seule clé froide, chacun avec une fabrique qui dort 100 ms, et vérifie que la fabrique s'est exécutée exactement une fois — dix-neuf appelants attendent sur le verrou, et celui qui a rempli le cache les sert tous. Cela transforme un marteau potentiel à vingt sur votre base de données en un unique chargement.

La limite honnête : ce verrou vit dans un ConcurrentDictionary<string, SemaphoreSlim> à l'intérieur du processus. Il effondre la ruée au sein d'une instance d'application. Avec dix instances d'application toutes froides sur la même clé au même instant, vous pouvez encore voir jusqu'à dix exécutions de fabrique, une par processus — pas une à l'échelle du cluster. C'est la forme normale de la protection contre les ruées côté client, et pour le cas courant (une poignée d'instances, une fabrique coûteuse mais pas catastrophique à exécuter quelques fois) c'est exactement ce que vous voulez. Si vous avez besoin d'un chargement strictement unique sur toute la flotte, c'est un problème de verrou distribué, pas une fonctionnalité de cache — et une tâche mieux modélisée avec le motif de revendication par comparaison-et-échange de Coordination sans course.

Invalidation par étiquette, et pourquoi elle est paresseuse​

HybridCache vous laisse étiqueter des entrées et invalider tout un groupe d'un coup :

await cache.RemoveByTagAsync("catalog");   // every entry tagged "catalog" is now stale

Zaris implémente cela avec des horodatages plutôt qu'avec un balayage actif. Chaque entrée est écrite avec deux étiquettes de métadonnées : l'instant où elle a été créée, et ses étiquettes. RemoveByTagAsync("catalog") écrit simplement une clé enregistrant « catalog a été invalidé à l'instant T. » À la prochaine lecture d'une entrée étiquetée, le cache compare : si l'une des étiquettes de l'entrée a été invalidée après la création de l'entrée, l'entrée est traitée comme un défaut et la fabrique se réexécute. Le test le confirme — étiquetez une entrée, invalidez l'étiquette, relisez, et la fabrique est appelée une deuxième fois.

Le compromis de conception à connaître : l'invalidation est paresseuse et déclenchée par la lecture, pas une purge immédiate. Appeler RemoveByTagAsync est en O(1) — il écrit un marqueur et retourne — mais les entrées périmées elles-mêmes restent résidentes dans le store jusqu'à ce que quelque chose les lise (et obtienne une valeur fraîche) ou que leur TTL expire. Vous obtenez une invalidation logique bon marché et instantanée ; vous n'obtenez pas une récupération immédiate de la mémoire que ces entrées détiennent. Pour des données de cache, c'est exactement le bon marché. Ne vous appuyez simplement pas dessus comme moyen de forcer la suppression de données pour des raisons de correction — pour cela, RemoveAsync(key) supprime les deux niveaux d'emblée.

3. Sessions, avec une vraie expiration glissante​

Les sessions ASP.NET Core ont besoin d'un store qui fait quelque chose que le cache général ne fait délibérément pas : faire glisser l'expiration à chaque requête qui touche la session, de sorte que la session d'un utilisateur actif n'expire jamais sous ses pieds tandis qu'une session inactive finit par le faire. Le paquet de session est un IDistributedCache conçu spécialement qui honore exactement cette sémantique, câblé en un seul appel :

builder.Services.AddZarisSession(o =>
{
    o.StoreName        = "sessions";
    o.ConnectionString = "zaris://cache-host:7861/sessions";
    o.IdleTimeout      = TimeSpan.FromMinutes(30);
    o.CookieName       = ".MyApp.Session";
});

// ... later in the pipeline, as usual:
app.UseSession();

Donnez-lui une chaîne de connexion et il enregistre le store Zaris de secours pour vous ; omettez-la et il se lie à un store que vous avez déjà enregistré sous StoreName. Dans les deux cas, vous utilisez ensuite HttpContext.Session exactement comme vous l'avez toujours fait.

La pièce qui compte est Refresh. Lorsque l'intergiciel de session charge une session lue mais non modifiée, il appelle RefreshAsync pour la maintenir en vie. Le cache de session Zaris implémente cela comme une lecture-puis-réécriture avec un TTL frais égal au timeout d'inactivité — de sorte que chaque requête qui touche la session fait glisser la fenêtre de 30 minutes vers l'avant. Une écriture (SetAsync) résout son TTL à partir de l'expiration glissante ou absolue de l'entrée, en se rabattant sur le timeout d'inactivité configuré. Le résultat est un comportement de session ASP.NET Core standard, adossé à un cluster Zaris, survivant à un redémarrage d'instance d'application parce que les données de session vivent dans le store et non dans la mémoire de l'instance.

Une note d'implémentation délibérée issue du code lui-même : Refresh est une lecture-plus-réécriture plutôt qu'un appel natif « réinitialise simplement le TTL ». Cela coûte un aller-retour supplémentaire, mais cela garde le glissement correct sur chaque déploiement Zaris — y compris celui embarqué en cours de processus — sans dépendre d'une primitive serveur de réinitialisation de TTL. La correction sur chaque topologie l'a emporté sur l'économie d'un aller-retour sur l'une d'elles.

Choisir le bon​

• Recourez à IDistributedCache quand quelque chose le réclame déjà, ou quand vous voulez le cache partagé le plus simple et qu'une bibliothèque va le consommer pour vous. C'est la couture de compatibilité maximale.
• Recourez à HybridCache sur un chemin de lecture véritablement chaud où un L1 en cours de processus gagne son pain et où une ruée sur une clé populaire froide ferait mal. Vous payez une pièce mobile supplémentaire (deux stores, mémoire locale pour le L1) ; vous obtenez des lectures répétées à latence quasi nulle et une horde effondrée à un chargement par instance.
• Recourez à AddZarisSession pour les sessions ASP.NET Core spécifiquement — c'est celui avec une vraie expiration glissante, et il reste à l'écart du propre IDistributedCache de votre application.

Aucun des trois ne vous demande d'apprendre une API spécifique au cache. Ils rencontrent le framework là où il définit déjà l'abstraction, s'enregistrent en une ligne, et mettent les octets sur un cluster que vous pouvez mettre à l'échelle, sécuriser et exécuter sur Kubernetes indépendamment de l'application qui est devant. La meilleure intégration est celle que le code de votre application n'a jamais à remarquer — et, ce qui est agréable, c'est souvent exactement celle que vous obtenez.

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.

Un cœur, plusieurs vues​

Commencez par la chose sur laquelle tout le reste est bâti. Sous chaque fonctionnalité de cet article, Zaris est un store clé-valeur partitionné et répliqué, et chaque valeur porte une version monotone appartenant au store. C'est tout. C'est le cœur.

Tout le reste est l'une de deux choses :

• Une vue typée, côté serveur, sur les clés — un hash, une liste, un set, un sorted set, un stream. Ce ne sont pas des blobs que vous récupérez et mutez dans votre processus ; ce sont de vraies collections côté serveur qui vivent sur la partition qui possède leur clé, et elles se répliquent exactement comme une valeur nue le fait.
• Une couche de coordination au-dessus de la version — comparaison-et-échange, transactions multi-clés, verrous, watch. Celles-ci utilisent la version (et la mécanique de propriété autour d'elle) pour laisser de nombreux clients s'accorder sur ce qui s'est passé sans se marcher dessus.

Gardez cette image et toute la surface cesse de ressembler à un fourre-tout de fonctionnalités et commence à ressembler à ce qu'elle est : un petit cœur, et un ensemble d'outils conçus à dessein qui résolvent chacun une classe spécifique de problème par-dessus. Choisissez par la forme de votre problème, pas par le nom qui sonne le plus proche.

La table de décision​

Le reste de cet article est cette table, ralentie.

KV et cache : quand une valeur n'est qu'une valeur​

Si tout ce dont vous avez besoin est de mettre des octets quelque part où chaque nœud peut les lire — un fragment rendu, un DTO sérialisé, un instantané de config — vous n'avez pas besoin d'une couche de coordination. PutAsync(key, value) et GetAsync<T>(key) sont toute l'histoire, et côté serveur ces octets sont partitionnés et répliqués pour vous.

Deux notes honnêtes. D'abord, l'expiration n'est pas définie à l'écriture. Il n'y a pas de champ TTL sur les options d'écriture ; vous définissez une durée de vie avec un appel séparé — ExpireAsync(key, ttl) — et vous l'effacez avec PersistAsync(key), ou vous lisez ce qu'il reste avec GetTimeToLiveAsync(key). Ensuite, si votre cas d'usage est littéralement « un cache distribué pour mon application ASP.NET Core », ne le fabriquez pas à la main : enregistrez l'un des paquets de cache prêts à l'emploi et le IDistributedCache du framework (ou HybridCache, ou le store de session) est adossé à votre cluster avec un changement de démarrage d'une ligne et aucun code touchant l'abstraction de cache.

Choisissez le KV nu quand la valeur n'a pas d'invariant de concurrence — le dernier écrivain qui gagne convient, ou il n'y a qu'un seul écrivain. Ne le faites pas dès l'instant où deux écrivains peuvent entrer en course sur la même clé et où vous seriez gêné si l'un écrasait silencieusement l'autre. C'est le travail de l'outil suivant.

Comparaison-et-échange : quand une valeur doit rester correcte sous concurrence​

Un compteur avec un plafond, un solde qui ne peut pas devenir négatif, un objet de config que deux administrateurs modifient en même temps. La défaillance que vous cherchez à éviter est la mise à jour perdue — lecture, lecture, écriture, écriture, et la seconde écriture efface la première. Le CAS transforme cette perte silencieuse en un conflit détecté et réessayable : lisez une valeur et sa version, réécrivez seulement si la version n'a pas bougé, et obtenez un Conflict plutôt qu'un écrasement si quelqu'un vous a devancé.

KvResult<int> read = await client.GetAsync<int>("counter:api");
var put = await client.PutAsync(
    "counter:api", read.Value + 1,
    new PutOptions { IfMatchVersion = read.Version });

// put.Status == KvStatus.Success  -> you won this round
// put.Status == KvStatus.Conflict -> someone wrote first; re-read and retry

C'est tout le mécanisme, et le guide de terrain du CAS montre jusqu'où il va — un limiteur de débit, un portefeuille qui ne se met jamais à découvert sous un millier de débits concurrents, une revendication de tâche à un seul gagnant (via « créer seulement si absent »), une config sans mise à jour perdue, et le crochet d'idempotence qui vient gratuitement avec.

Choisissez le CAS quand l'invariant vit sur une clé et que vous voulez la correction sans tenir de verrou. Ne pointez pas une foule d'écrivains vers une unique clé chaude en espérant que ça passe à l'échelle — le CAS laisse délibérément exactement un écrivain gagner par tour, de sorte qu'une clé chaude devient un point de sérialisation. Fragmentez-la (un seau par client-seconde, un solde scindé en sous-soldes réconciliés) et la contention fond.

Transactions multi-clés : quand l'invariant s'étend sur plusieurs clés​

La ligne dure que trace le CAS est qu'il est atomique sur une clé. Transférer de l'argent du compte A au compte B, ou maintenir un index secondaire au pas avec l'enregistrement qu'il pointe, et aucune comparaison-et-échange unique ne couvre les deux. Ce n'est pas une raison de faire semblant avec deux écritures CAS en espérant — c'est le cas exact pour lequel la transaction multi-clés existe.

Vous ouvrez une transaction, y préparez des lectures et des écritures, et validez. Sous le capot, c'est une validation en deux phases coordonnée par le client sur des versions optimistes : les clés peuvent vivre sur différents nœuds, donc le client groupe l'ensemble d'écriture par propriétaire, chaque nœud vérifie que chaque clé que vous avez lue est encore à la version à laquelle vous l'avez lue et prend un verrou à courte durée de vie, et ce n'est que si tout le monde vote oui que l'ensemble complet s'applique. La moindre version qui a bougé, et la validation renvoie Conflict sans rien changer.

Choisissez une transaction quand deux clés ou plus doivent bouger ensemble ou pas du tout. Ne l'utilisez pas comme votre chemin d'écriture par défaut — c'est un vrai 2PC avec des allers-retours prepare/commit et des verrous à courte durée de vie, plus lourd qu'un seul CAS. Si l'invariant tient honnêtement sur une clé, gardez-le sur une clé.

Structures de données natives : quand la donnée est une collection​

Parfois la valeur n'est pas un scalaire que vous protégez — c'est une forme. Un profil utilisateur est une map de champs. Un flux d'activité récente est une liste. Une appartenance d'étiquette est un set. Un classement est un ranking. Vous pourriez sérialiser chacun comme un seul blob et le CAS, mais alors chaque modification d'un seul champ réécrit l'objet entier, et vous avez transformé une mise à jour en O(1) en une mise à jour en O(n).

Zaris leur donne leurs propres types de collection natifs, côté serveur — hashes, listes, sets, sorted sets — où une opération sur un seul champ ou un seul élément ne touche que cet élément sur le serveur, pas la valeur entière dans votre processus. Ils partitionnent et se répliquent comme n'importe quelle clé, et parce que la façade RESP fait correspondre les mêmes commandes Redis aux mêmes collections côté serveur, un service .NET et un service Python utilisant HSET touchent le hash identique.

Choisissez une collection quand votre motif d'accès est par élément — définir un champ, pousser une entrée, tester une appartenance, lire le top N par score. Ne choisissez pas un sorted set quand ce dont vous avez réellement besoin est un journal d'événements ordonné, acquitté et rejouable. Ça, c'est un stream.

Streams : quand vous avez besoin d'un journal ordonné et rejouable​

Une file et un journal se ressemblent jusqu'à ce qu'un consommateur plante. Les streams Zaris sont un vrai journal en ajout-seulement : les entrées obtiennent des identifiants monotones, vous pouvez lire des plages, et un groupe de consommateurs divise le journal sur un pool de travailleurs, suit les entrées en attente (livrées-mais-non-acquittées) de chaque travailleur, et laisse un autre travailleur récupérer ce qu'un travailleur planté n'a jamais acquitté. Cette mécanique d'attente-et-acquittement est ce qui vous achète une livraison au moins une fois — la chose qu'une notification tire-et-oublie ne peut pas donner.

Choisissez un stream quand vous avez besoin d'événements durables, ordonnés et rejouables avec un acquittement explicite et un partage du travail — ingestion de commandes, une boîte d'envoi, une piste d'audit qu'une projection reconstruit. Ne l'utilisez pas comme une file à priorités ou un canal requête/réponse ; c'est un journal, et ses forces sont l'ordre et le rejeu, pas le routage.

Watch, notifications et la famille de diffusion : quand vous réagissez au changement​

Il existe plusieurs façons d'apprendre que quelque chose a changé, et elles ne sont pas interchangeables — la différence est de savoir si le signal est durable.

Celle à choisir depuis .NET est Watch : un flux de changements natif, à l'échelle du cluster. Vous vous abonnez à une clé ou un préfixe, y intégrez éventuellement un instantané initial pour qu'il n'y ait pas de trou entre « lire l'état courant » et « s'abonner aux changements », et recevez les événements au fur et à mesure que les écritures atterrissent :

var (subscription, initial) = await client.Watch.WatchKeyAsync(
    "job:42",
    new WatchOptions { IncludeInitialSnapshot = true },
    evt => Handle(evt));

La propriété importante est que le watch est enregistré à l'échelle du cluster et survit au basculement — il n'est pas lié à l'unique nœud qui a justement traité une écriture. C'est aussi pourquoi les notifications d'espace de clés Redis que Zaris parle (__keyevent@0__ / __keyspace@0__, un simple PSUBSCRIBE depuis n'importe quel client Redis) valent davantage ici que sur une machine Redis unique : ce sont un pont mince vers ce même watch répliqué, de sorte qu'un basculement ne laisse pas tomber silencieusement le flux d'événements.

Choisissez watch/notifications d'espace de clés quand vous voulez réagir à des changements d'état — invalider un cache, réveiller un travailleur, rafraîchir une projection. Ne confondez pas la simple diffusion pub/sub au mieux avec un flux durable : si vous avez besoin de chaque événement même à travers plantages et redémarrages, c'est un stream, pas une notification.

Verrous : exclusion mutuelle grossière, avec un avertissement tranchant​

Zaris dispose bien d'un verrou distribué de première classe — une barrière nommée, fondée sur un bail avec un TTL, acquise depuis le client et libérée à la libération ou à l'expiration par plantage :

await using var gate = await client.Locks.AcquireAsync("order:123", TimeSpan.FromSeconds(10));
if (gate is null)
{
    // someone else holds it — back off, do other work, or retry later
    return;
}
// critical section; the lease auto-expires if we crash, and can be renewed

Il est véritablement utile pour l'exclusion mutuelle grossière — empêcher deux planificateurs d'exécuter le même balayage, sérialiser une tâche de maintenance — et le TTL signifie qu'un détenteur planté ne bloque pas le verrou pour toujours.

Mais voici l'avertissement que la version léchée omet, et c'est la phrase la plus importante de cet article sur les verrous : un verrou fondé sur un bail n'est pas une barrière de correction. Si votre détenteur fait une pause — un blocage GC, un appel système lent — assez longtemps pour que le bail expire, un second détenteur peut acquérir le « même » verrou tandis que le premier croit encore le détenir, et voilà deux travailleurs dans la section critique à la fois. Pour la vivacité et l'efficacité (d'ordinaire un seul travailleur exécute la tâche, la contention est faible) un verrou à bail est exactement bon. Pour un invariant de correction qui ne doit jamais être violé, ne comptez pas sur le verrou pour l'imposer — imposez-le sur la donnée avec la comparaison-et-échange ou une transaction, de sorte que même un second acteur parasite soit rejeté par une vérification de version à l'écriture.

Choisissez un verrou quand vous voulez une exclusion mutuelle grossière, au mieux, et qu'un chevauchement occasionnel est simplement gaspilleur, pas incorrect. Choisissez plutôt le CAS quand un chevauchement corromprait les données — laissez la version, pas le verrou, être la chose qui dit non.

La partie transversale : propriété, durabilité, cohérence​

Trois propriétés tiennent à travers chaque primitive ci-dessus, parce que ce sont des propriétés du cœur, pas d'un outil en particulier :

• Le propriétaire bouge, et vous n'avez pas à le remarquer. Chaque clé est possédée par une partition qui peut basculer, migrer ou être rendue. Le client .NET transforme ce changement en un signal typé et réessayable et redirige vers le nouveau propriétaire, borné par un budget de tentatives et une échéance en temps réel — de sorte qu'un PutAsync pendant un basculement prend d'ordinaire simplement quelques millisecondes de plus et renvoie un succès.
• La durabilité est par réplication, pas par disque. Zaris garde les données en mémoire et durables en gardant des copies sur d'autres nœuds. C'est pourquoi le facteur de réplication n'est pas la même chose que la tolérance aux pannes : le nombre ne vous protège que si la topologie place réellement une seconde copie sur un nœud qui peut survivre à la perte du premier. Toute l'épine dorsale de propriété et de récupération existe pour s'assurer qu'aucune écriture acquittée n'est perdue pendant que la propriété est en mouvement.
• Les écritures et les lectures routent vers le propriétaire courant. La mécanique de nouvelle tentative et de redirection fait que vos opérations trouvent le nœud qui possède actuellement la clé, de sorte qu'une lecture suit une écriture validée plutôt que de devancer le changement de propriété qui vient de se produire.

Aucune de celles-ci n'est une primitive que vous choisissez. Ce sont le socle sur lequel chaque choix repose.

L'organigramme​

La version courte​

La longueur de la liste de fonctionnalités n'a jamais été le propos. Zaris est un cœur clé-valeur versionné, partitionné et répliqué, plus des vues typées côté serveur (hash, liste, set, sorted set, stream) et des couches de coordination au-dessus de la version (CAS, transactions, verrous, watch). Faites correspondre l'outil à la forme du problème : un scalaire sous contention veut le CAS ; un invariant inter-clés veut une transaction ; une donnée qui est une collection veut la collection correspondante ; des événements ordonnés et durables veulent un stream ; réagir au changement veut watch ; l'exclusion mutuelle grossière veut un verrou — et tout ce qui ne doit jamais être violé veut sa garantie imposée sur la donnée, avec une vérification de version, pas sur un verrou qui peut expirer.

Choisissez par la forme, appuyez-vous sur la version pour la correction, et le petit cœur porte une quantité de système remarquable.

L'essentiel de ce que vous lisez sur un store de données concerne le chemin de données — lectures, écritures, protocole de communication, sa rapidité. Mais avant que tout cela ne compte, quelqu'un doit monter la chose : décider combien de partitions elle a, combien de copies de chacune, où vivent les ports, la démarrer, confirmer qu'elle est montée en bonne santé et la surveiller pendant qu'elle tourne. C'est le plan de contrôle, et dans Zaris il vit dans PowerShell.

Ceci est une visite guidée de l'opérateur au jour zéro. Nous allons créer un espace de travail, provisionner un store, le démarrer, puis relire son état en direct — le tout depuis le module AdminShell. Aucune console web requise, rien édité à la main. Et parce que tout l'intérêt d'une histoire d'opérateur est la confiance, nous serons explicites sur les choix que New-ZrStore met devant vous et sur ce que chacun coûte réellement.

Deux shells, deux plans​

Zaris livre sa surface en ligne de commande sous la forme de deux modules PowerShell distincts, et la séparation n'est pas cosmétique — elle reflète les deux plans du système :

• AdminShell est le plan de contrôle. Ses cmdlets provisionnent, démarrent, arrêtent, inspectent et mettent à l'échelle les stores. Elles parlent au Management Service de Zaris (le « manager »), pas directement aux nœuds de données. Ce sont les verbes New-ZrStore, Get-ZrNode, Watch-ZrStoreMetrics.
• ClientShell est le plan de données. Ses cmdlets — Connect-ZrStore, Get-ZrItem, Set-ZrItem — ouvrent une connexion directe vers les nœuds du store et déplacent des données clé-valeur. C'est la surface qu'utilise une application, et le sujet de l'article sur les chaînes de connexion.

Un opérateur qui monte un cluster vit presque entièrement dans AdminShell. Le manager auquel il parle est le composant qui connaît la forme désirée de chaque store et pilote les processus réels vers elle. La première chose à faire est donc d'indiquer à votre shell à quels managers parler.

Étape 0 — un espace de travail à cibler​

Un espace de travail est un ensemble nommé de managers que les cmdlets admin ciblent, persisté sous ~/.clustron pour qu'il survive aux sessions. Vous en créez un une fois et vous y basculez chaque fois que vous ouvrez un shell :

# Create a workspace pointing at the cluster's managers (does not activate it)
New-ZrWorkspace -Name "prod" -Managers "10.0.0.10:7801","10.0.0.11:7801"

# Make it the active target for this and future sessions
Use-ZrWorkspace prod

Chaque point de terminaison manager est un observateur d'un cluster — listez-les tous et les cmdlets admin agrègent l'état sur l'ensemble du cluster plutôt que sur ce qu'une machine se trouve connaître. Si votre cluster a la sécurité activée, enregistrez un jeton admin sur l'espace de travail (-Token) ou authentifiez la session avec Connect-ZrManager -Credential (Get-Credential) -Force, qui échange un nom d'utilisateur et un mot de passe contre un jeton de session. (Connect-ZrManager est l'ancienne connexion ad hoc et fonctionne toujours, mais les cmdlets d'espace de travail sont le chemin actuel — ce sont ce à quoi correspondent les espaces de travail enregistrés de la console web.)

Une bifurcation honnête du chemin ici : la visite guidée ci-dessous est le modèle superviseur, où chaque manager fork et possède ses processus Zaris locaux — le déploiement natif/Windows. Si vos nœuds tournent plutôt sous un orchestrateur comme Kubernetes (le modèle d'attachement), le manager ne crée pas de processus ; vous définissez le store avec votre orchestrateur et vous l'adoptez avec Register-ZrStore au lieu de New-ZrStore. New-ZrStore détecte un manager en mode attachement et vous le signale plutôt que d'échouer au fond de la pile.

Étape 1 — provisionner le store​

C'est la cmdlet qui porte les vraies décisions. La forme de production minimale est courte :

New-ZrStore -Name "orders" `
            -ReplicationFactor 2 `
            -BaseClusterPort 7811 `
            -BaseClientPort 7861

Cela crée un store nommé orders sur chaque machine de l'espace de travail, avec deux copies de chaque partition. Quatre paramètres portent le poids, soyons donc précis sur chacun.

-ReplicationFactor est le nombre total de copies de chaque partition — primaire plus réplicas. Pour la production, il doit être au plus égal au nombre de machines, de sorte que chaque copie atterrisse sur une machine différente ; c'est ce qui en fait de la tolérance aux pannes plutôt qu'une décoration. Sur une machine de dev unique, la contrainte est assouplie avec un avertissement — les réplicas partageront une machine, ce qui convient pour les tests et ne vous apporte rien lors d'une vraie panne. La cmdlet le dit à voix haute plutôt que de vous laisser croire autre chose.

-PartitionsPerNode vaut 1 par défaut, ce qui est la topologie de production. Le nombre total de partitions est dérivé de l'appartenance en direct du cluster — PartitionsPerNode × nœuds en direct — et recalculé à chaque changement d'appartenance, ce n'est donc pas un nombre que vous figez à la création. Vous le montez au-dessus de 1 surtout pour les tests locaux, où vous voulez observer le comportement conscient des partitions (routage de segment, rééquilibrage à la montée en charge) sur une machine unique sans monter un rack.

-BaseClusterPort / -BaseClientPort sont les premiers ports de deux plages : le port interne de gossip/cluster et le port exposé aux clients, incrémentés une fois par processus sur chaque machine. La cmdlet vérifie que les deux plages ne se chevauchent pas et refuse de créer un store qui entrerait en collision avec lui-même — une petite garde qui évite un échec déroutant au premier démarrage.

Il y en a trois autres qui valent la peine d'être connues parce qu'elles encodent un véritable compromis de durabilité :

New-ZrStore -Name "orders" -ReplicationFactor 3 `
            -BaseClusterPort 7811 -BaseClientPort 7861 `
            -ReplicationMode Sync `
            -WriteQuorumPolicy Majority `
            -AllowReplicaReads

• -ReplicationMode vaut Async par défaut : le primaire écrit localement et retourne immédiatement, répliquant en arrière-plan. C'est l'option la plus rapide et le bon défaut pour un cache — mais soyez lucide : une écriture acquittée sous Async n'est pas encore garantie d'être sur un réplica. Choisissez Sync et le primaire attend l'acquittement du réplica avant de renvoyer Ok, échangeant de la latence contre de la durabilité.
• -WriteQuorumPolicy ne mord que sous Sync : All (chaque réplica doit acquitter), Majority (floor(RF/2)+1 doivent acquitter), ou BestEffort (les échecs sont journalisés mais ne font pas échouer l'écriture).
• -AllowReplicaReads laisse les clients lire depuis les nœuds réplicas pour répartir la charge de lecture — avec l'avertissement honnête qu'une lecture de réplica peut renvoyer des données légèrement périmées, car un réplica peut traîner derrière le primaire. Laissez-le désactivé quand vous avez besoin de lire vos propres écritures ; activez-le quand vous préférez le débit et pouvez tolérer le retard.

Remarquez ce que les défauts disent de la posture de Zaris : Async + lecture-depuis-le-primaire est un cache rapide et correct par défaut. Les boutons de durabilité sont là quand vous en avez besoin, nommés clairement, chacun avec un coût que vous pouvez voir.

Étape 2 — le démarrer, et confirmer qu'il est monté​

Créer un store définit sa forme ; cela n'exécute pas les processus. Start-ZrStore énumère les instances du store sur chaque manager et les démarre, en rapportant le succès ou l'échec par instance :

Start-ZrStore -Name "orders"

Voici maintenant la partie qui distingue un opérateur de quelqu'un qui a lancé une commande et espéré. Get-ZrStore relit l'état en direct du store depuis les managers — statut global, temps de disponibilité, et l'état d'exécution de chaque nœud :

Get-ZrStore orders

Store   : orders
Status  : Running
Uptime  : 2h 14m  (since 2026-10-03 09:41:12)

Nodes (4)
───────────────────────────────────────────
  ● 10.0.0.10-n0   10.0.0.10:7861   Running   up 2h 14m
  ● 10.0.0.10-n1   10.0.0.10:7862   Running   up 2h 14m
  ● 10.0.0.11-n0   10.0.0.11:7861   Running   up 2h 14m
  ● 10.0.0.11-n1   10.0.0.11:7862   Running   up 2h 14m
───────────────────────────────────────────
  Running: 4   Stopped: 0

Le statut du store est une synthèse : Running quand chaque nœud est actif, Stopped quand tous sont en panne, et Partial quand certains sont actifs et d'autres non — ce qui est exactement l'état que vous voulez révélé bruyamment, car un store Partial est un store qui a démarré de façon inégale. Le temps de disponibilité est délibérément le moment de formation du cluster rapporté par le cœur — le démarrage de nœud le plus précoce qui a survécu au changement — et non le plus vieux processus actuellement en cours, de sorte qu'un store qui sert depuis des heures ne rapporte pas à tort « quelques minutes » simplement parce qu'un nœud a redémarré.

Pour la couche en dessous, Get-ZrNode montre les rôles et la carte de partitions :

Get-ZrNode orders

Nodes (4)
─────────────────────────────────────────────────────────────────────────
  ● 10.0.0.10-n0   10.0.0.10:7861   Running   Primary   v7
  ● 10.0.0.10-n1   10.0.0.10:7862   Running   Replica   v7
  ● 10.0.0.11-n0   10.0.0.11:7861   Running   Primary   v7
  ● 10.0.0.11-n1   10.0.0.11:7862   Running   Replica   v7

La colonne Primary/Replica indique qui possède actuellement chaque partition, et le v7 est la version de la carte de partitions — le numéro de génération de la carte de propriété. Lorsque chaque nœud s'accorde sur la même version de carte, la propriété a convergé ; un nœud coincé sur une version plus ancienne est un nœud qui n'a pas rattrapé le dernier rebrassage. Demander le détail d'un nœud unique (Get-ZrNode orders 10.0.0.10-n0) développe cela en les identifiants exacts des partitions primaires et réplicas qu'il détient et le moment où son rôle a changé pour la dernière fois — la vue que vous consultez quand un basculement vient d'avoir lieu et que vous voulez savoir où la propriété a atterri.

Étape 3 — le surveiller pendant qu'il tourne​

Un instantané vous dit que le store est actif. Une vue en direct vous dit ce qu'il fait. Watch-ZrStoreMetrics interroge les managers et redessine une table par nœud à intervalle régulier jusqu'à ce que vous l'annuliez :

Watch-ZrStoreMetrics -StoreName orders -RefreshSec 2

Elle dispose d'abord les compteurs du quotidien — taux de requêtes, gets, puts, deletes, nombre d'éléments, utilisation mémoire — et repousse les diagnostics avancés de réplication et de synchronisation vers le bas, de sorte que les nombres que vous vérifiez d'un coup d'œil sont en haut. Les compteurs d'erreurs passent au rouge dès que leur taux dépasse zéro ; le débit se teinte de vert lorsqu'il monte. Elle signale aussi les changements de rôle en ligne : si un basculement fait passer un primaire à réplica pendant que vous regardez, une ligne [ROLE CHANGE] s'affiche avec un horodatage — le signal en direct qu'une partition vient de changer de mains.

Un détail délibéré qui mérite d'être souligné, car c'est le genre de chose qui rend un outil utilisable à 2 h du matin : la vue récupère la trame suivante avant d'effacer l'écran, et une interrogation vide transitoire conserve la dernière bonne trame plutôt que de tout effacer. Vous obtenez une table stable, pas une table clignotante, quelle que soit la lenteur d'un manager à répondre.

Pour compléter l'ensemble en lecture seule, Get-ZrInfo rapporte la version installée, les répertoires d'installation et de données, les deux emplacements de module, le runtime hôte — et sonde chaque manager pour sa joignabilité. Un manager sécurisé qui répond 401 est rapporté comme joignable mais nécessitant une authentification, pas comme « en panne », de sorte que vous pouvez distinguer d'un coup d'œil un problème réseau d'un jeton manquant.

Étape 4 — arrêter, et la forme sous-jacente à tout​

Mettre un store à l'arrêt est le miroir du cycle de vie de son démarrage :

# Fast whole-store stop (default: a hard kill, since every node goes down together)
Stop-ZrStore -Name orders

# Per-node drain and clean cluster-leave
Stop-ZrStore -Name orders -Graceful

Le défaut est une mise à mort dure et rapide, qui est le bon comportement quand le store entier descend d'un coup — il n'y a pas de cluster survivant à qui un nœud partant puisse passer la main, donc drainer n'apporte rien. Utilisez -Graceful quand vous voulez que chaque nœud draine et quitte le cluster proprement, ce qui importe quand vous arrêtez un sous-ensemble plutôt que l'ensemble.

Sous chaque cmdlet de cet article se cache une seule idée : un store Zaris a une forme désirée — une définition canonique des serveurs et partitions qu'il est censé avoir — et le manager tourne sous un modèle superviseur qui pilote en continu les processus en direct vers elle. New-ZrStore écrit cette forme ; Start-ZrStore la réalise ; Get-ZrStore et Get-ZrNode rapportent à quel point la réalité en est proche. C'est ce même modèle qui fait du redimensionnement élastique une ligne unique plutôt qu'un runbook — changer la forme désirée avec Add-ZrServer / Remove-ZrServer et laisser le superviseur réconcilier, ce qui est sa propre histoire de mise à l'échelle élastique.

Le résumé honnête​

Le cycle de vie complet du jour zéro, ce sont cinq commandes et deux lectures :

New-ZrWorkspace -Name prod -Managers "10.0.0.10:7801","10.0.0.11:7801"
Use-ZrWorkspace prod
New-ZrStore -Name orders -ReplicationFactor 2 -BaseClusterPort 7811 -BaseClientPort 7861
Start-ZrStore -Name orders
Get-ZrStore  orders          # is it Running, and are all nodes up?
Get-ZrNode   orders          # who owns what, and did the map converge?
Watch-ZrStoreMetrics -StoreName orders -RefreshSec 2   # what's it doing now?

Ce qui fait de ceci un plan de contrôle et pas seulement un tas de scripts, c'est que les cmdlets rapportent une vérité en direct, agrégée — non pas ce que vous avez demandé, mais ce que le cluster est réellement — et que les choix aux conséquences réelles sont nommés en toutes lettres : facteur de réplication contre nombre de machines, Async contre Sync, lectures de réplica contre péremption. Montez un store, confirmez qu'il a convergé, et gardez-le à l'œil — le tout sans quitter le shell.

La plupart des stores de données distribués vous obligent à choisir, tôt et définitivement, entre deux mondes. Il y a le « vrai » store — un cluster que vous déployez, vers lequel vous pointez un client sur le réseau, et auquel vous parlez via un protocole de communication. Et il y a le « faux » store auquel vous recourez dans les tests unitaires : un dictionnaire en mémoire, un mock, un bouchon fait main qui implémente juste assez de l'interface pour que le test compile. Les deux ne partagent rien. Votre test exerce le comportement du bouchon, pas celui du store, et l'écart entre eux est exactement là où se cachent les bugs.

Zaris supprime ce choix. Le même client .NET typé qui parle à un cluster distribué sur TLS exécute aussi le store embarqué à l'intérieur de votre processus, sans socket, sans carte de partitions et sans déploiement — et c'est le même moteur de store, pas un substitut. Vous sélectionnez lequel vous obtenez avec une seule chaîne de connexion. Cet article traite de la façon dont cela fonctionne, des cas pour lesquels il est véritablement bon, et de la ligne dure où le mode embarqué s'arrête et où un cluster commence.

Une chaîne est tout l'interrupteur​

Un client Zaris est toujours configuré à partir d'une chaîne de connexion. La chaîne porte le transport, les points de terminaison d'amorçage, le nom du store et les options. Il y a deux formes, et la différence entre elles est la différence entre un cluster et un store embarqué :

zaris://inproc/orders                     # embedded — store runs inside this process
zariss://zaris.mycorp.com:7863/orders     # remote   — connect to a cluster over TLS

Le jeton d'hôte inproc est réservé. Quand le client le voit, il n'y a aucun point de terminaison à composer, aucun transport à négocier, aucune poignée de main TLS et aucun jeton — le store est servi depuis la mémoire dans le processus courant. Tout le reste de votre code reste identique :

// Embedded: no server to start, no port, no network.
IZarisClient store = await ZarisClient.ConnectAsync("zaris://inproc/orders");

// Later, in production — the ONLY line that changed:
IZarisClient store = await ZarisClient.ConnectAsync("zariss://zaris.mycorp.com:7863/orders?ca=/etc/zaris/ca.crt");

Dans ASP.NET Core, c'est la même histoire via l'injection de dépendances — la chaîne de connexion provient d'ordinaire de la configuration, donc le basculement est une valeur de config, pas un changement de code :

// Program.cs — one registration, driven entirely by the connection string.
builder.Services.AddClustronZaris("orders", builder.Configuration.GetConnectionString("orders")!);

Mettez zaris://inproc/orders dans appsettings.Development.json et zariss://.../orders en production, et le même binaire tourne embarqué sur l'ordinateur portable d'un développeur et en cluster dans le cloud, sans rien recompiler.

Pourquoi « le même client » est le propos​

La raison pour laquelle cela compte réside dans le type que vous récupérez. ConnectAsync renvoie un IZarisClient — ou, pour la surface de fonctionnalités complète, IZaris — quel que soit le mode. Le mode embarqué est servi par une classe appelée ZarisInProcClient, et elle implémente exactement les mêmes interfaces que le client de cluster :

public interface IZaris : IZarisClient
{
    ILeasesClient     Leases     { get; }
    ILocksClient      Locks      { get; }
    ICountersClient   Counters   { get; }
    IScanClient       Scan       { get; }
    IWatchClient      Watch      { get; }
    IPubSubClient     PubSub     { get; }
    IHashClient       Hashes     { get; }
    IListClient       Lists      { get; }
    ISetClient        Sets       { get; }
    ISortedSetClient  SortedSets { get; }
    IStreamClient     Streams    { get; }
}

Chacune de ces surfaces est présente en mode embarqué, adossée au même moteur de store que le cluster utilise. Get/Put/Delete clé-valeur, en masse et par lot, transactions multi-éléments, TTL et expiration, comparaison-et-échange optimiste, Watch pour les lectures réactives, Streams natifs avec groupes de consommateurs, les structures de données répliquées — tout cela se résout contre le store embarqué, pas un mock.

Ce moteur partagé est ce qui fait du store embarqué une cible de test fidèle. Une boucle de comparaison-et-échange qui dépend d'un conflit rapporté avec précision, un abonnement Watch qui doit se déclencher quand une clé change, une transaction qui doit valider atomiquement ou pas du tout — chacun se comporte embarqué comme il se comporte en cluster, parce que c'est littéralement le même chemin de code qui l'évalue. Un KvStatus.Conflict embarqué signifie ce qu'il signifie en production. Un bouchon de dictionnaire fait main ne peut pas le promettre.

Ce qu'est réellement l'hôte embarqué​

Il vaut la peine d'être précis sur ce que zaris://inproc démarre, car les limites honnêtes en découlent directement. L'hôte embarqué est une topologie à nœud unique fixe qui possède chaque segment. Il n'y a pas de carte de partitions, parce qu'il n'y a qu'un seul participant ; il n'y a pas de réplication, parce qu'il n'y a pas de seconde copie ; il n'y a pas de transport, parce qu'il n'y a pas de second processus à atteindre.

Ce qui tourne bel et bien, c'est la vraie mécanique que vous voudriez dans un test. Le store provisionne son segment d'emblée, câble le service de bail, le service de watch et les métriques locales, et démarre le balayeur de TTL à sa cadence normale — de sorte qu'une clé que vous ExpireAsync avec un TTL de 50 ms disparaît réellement, sur une minuterie, exactement comme elle le ferait dans un cluster. L'expiration, la comptabilité d'éviction, le versionnage et les notifications de watch sont tous actifs. C'est un store complet qui se trouve avoir une taille de cluster de un.

Au sein d'un même processus, les clients sont partagés par nom de store. Deux appels ConnectAsync("zaris://inproc/orders") dans le même processus se résolvent vers le même store embarqué, de sorte qu'une valeur que l'un écrit, l'autre la lit — pratique quand votre test lance un producteur et un consommateur et attend qu'ils se voient. Des noms de store différents obtiennent des stores différents ; des processus différents obtiennent des stores embarqués entièrement séparés (plus sur cette limite ci-dessous).

Là où le mode embarqué gagne son pain​

Tests unitaires et d'intégration qui exercent le vrai store. C'est l'usage phare. Votre dépôt, votre couche de cache, votre coordinateur de saga — testez-les contre zaris://inproc/test-{Guid}, obtenez un store frais et isolé par test, et exercez la sémantique véritable : vrai versionnage pour vos boucles CAS, vraie expiration TTL sur une vraie minuterie, vraie atomicité de transaction, vrais événements de watch. Aucun conteneur Docker à démarrer en CI, aucun port à allouer, aucune instabilité de démontage. Le store est créé à la première connexion et meurt avec le processus.

Applications à processus unique qui pourraient grandir plus tard. Une application de bureau, un travailleur d'arrière-plan, un outil en ligne de commande, ou un petit service qui a besoin aujourd'hui d'un store structuré rapide mais pourrait devenir un déploiement en cluster demain. Commencez embarqué. Le jour où vous avez besoin de partager ces données entre instances, vous changez la chaîne de connexion pour pointer vers un cluster — et parce que vous avez codé contre IZaris tout du long, rien d'autre ne bouge.

Intégrations livrées embarquées par défaut. Le fournisseur de session ASP.NET Core de Zaris en est un exemple concret : câbler Zaris comme votre store de session est un seul appel, et dans son échantillon il tourne entièrement embarqué —

builder.Services.AddZarisSession(options =>
{
    options.ConnectionString = "zaris://inproc/sessions";
});

— ce qui signifie qu'un développeur peut F5 l'application et avoir des sessions fonctionnelles avec zéro infrastructure, puis passer à zariss://.../sessions pour un déploiement multi-instance sans toucher au code de session.

Pour utiliser le mode embarqué, référencez le paquet Clustron.Zaris.InProc aux côtés du client (il cible .NET 8). Le paquet s'enregistre lui-même : le client découvre et charge la fabrique en cours de processus à la première utilisation, de sorte que le simple fait de le référencer suffit. Dans un assembly de test où vous préférez être explicite, new InProcBootstrap().Register(); le câble de façon déterministe.

Là où il s'arrête honnêtement​

Le mode embarqué est un vrai store, mais c'est un store à nœud unique, en mémoire, et prétendre autre chose serait le baratin marketing que ce blog cherche à éviter. Trois limites dures, droit sorties de la conception :

Aucune durabilité. Le store embarqué garde les données dans la mémoire du processus et nulle part ailleurs. Il n'y a ni réplication ni journal sur disque dans ce mode — quand le processus se termine, les données sont parties. C'est exactement ce que vous voulez pour un test (table rase à chaque exécution) et exactement ce sur quoi vous ne devez pas compter pour quoi que ce soit qui doive survivre à un redémarrage. Le mode embarqué n'est pas une base de données avec laquelle vous adossez vos données de production.

Aucune haute disponibilité, aucune montée en charge. Un cluster de un tolère la perte de zéro nœud et se met à l'échelle à la mémoire et au CPU d'un seul processus. Toutes les raisons pour lesquelles vous recourriez au Zaris distribué — survivre à une panne de nœud sans perte de données, dimensionner les réplicas pour la durabilité, mettre à l'échelle le débit sur les cœurs et les machines — ne s'appliquent tout simplement pas à un hôte embarqué, parce qu'il n'y en a qu'un. Quand vous avez besoin de ces propriétés, vous avez besoin du cluster.

Aucun partage inter-processus. Le registre en cours de processus partage un store par nom au sein d'un processus. Deux processus différents qui ouvrent tous deux zaris://inproc/orders obtiennent deux stores indépendants qui ne savent rien l'un de l'autre — il n'y a pas de socket entre eux, par définition. Dès l'instant où vos données doivent être visibles pour un second processus ou une seconde machine, le mode embarqué est le mauvais outil et un cluster est le bon.

Aucune de ces limites n'est un bug à corriger ; elles sont la définition d'« embarqué ». La valeur n'est pas que le store en cours de processus soit secrètement distribué — c'est que le jour où vous avez besoin de la distribution, la seule chose que vous changez est la chaîne qui dit où le store vit.

La même promesse, tenue deux fois​

L'argumentaire est petit et concret. Vous écrivez votre application contre une seule surface de client. Dans un test, ou sur un portable, ou à l'intérieur d'un outil à processus unique, cette surface est servie par un vrai store Zaris tournant dans votre propre mémoire — rapide à créer, fidèle dans sa sémantique, et disparu quand le processus se termine. En production, le code identique parle à un cluster distribué sur TLS. Le comportement que vos tests ont figé est le comportement que vous livrez, parce que ce n'a jamais été une implémentation différente — seulement un endroit différent où le store vit.

C'est toute l'idée derrière zaris://inproc : l'écart entre « le store dans mon test » et « le store en production » a la largeur d'une chaîne de connexion, et c'est à vous de décider, par environnement, de quel côté vous vous trouvez.

Il y a une question que chaque développeur finit par poser à un store distribué, généralement juste après un rapport de bug déroutant : si j'écris une valeur puis la relis immédiatement, suis-je garanti de voir ce que j'ai écrit ? On dirait que cela devrait avoir une réponse en un mot. Ce n'est pas le cas — ni pour aucun store partitionné et répliqué, ni pour Zaris. La réponse honnête est « oui, au sein d'une partition, parce que les lectures vont au même propriétaire unique que votre écriture » — et la partie intéressante est tout ce qui est contenu dans ce qualificatif.

Cet article est le modèle de cohérence de Zaris, assemblé en un seul endroit. Nous avons écrit sur les pièces séparément — comparaison-et-échange optimiste, nouvelle tentative transparente lors du changement de propriété, le journal d'opérations rejouable qui alimente les réplicas, transactions multi-clés. Ici nous les relions du côté du lecteur et répondons à la seule question qui compte derrière un clavier : quand je lis, qu'est-ce qui m'est réellement promis ? Y compris, surtout, là où la promesse s'arrête.

Le modèle en une phrase​

Zaris est un store à tendance AP avec la frontière de cohérence tracée autour de la propriété, et non autour de chaque écriture. Le plan de données reste disponible — un nœud isolé continue de servir les segments qu'il détient — et la discipline d'écrivain unique qui garde les lectures saines est imposée dans le plan de propriété : il y a exactement un propriétaire actif par partition à tout instant. Les écritures vers une partition sont sérialisées à travers ce nœud unique. Il n'y a délibérément aucun quorum ni consensus sur le chemin d'écriture, et Zaris ne revendique pas de linéarisabilité stricte globale.

Presque tout ce qu'un lecteur observe découle de ce seul fait structurel, il vaut donc la peine de rendre la chaîne explicite :

key → segment → partition → one runtime active owner

Une clé hache de façon déterministe vers un segment ; un segment appartient à une partition ; une partition a exactement un propriétaire actif qui accepte ses écritures et sert ses lectures. La propriété est un bail porté sur la carte de partitions sous la forme (LeaderTerm, OwnershipGeneration) — accordé par le leader du cluster, durable à travers les redémarrages, et propagé à chaque nœud. Ce bail est ce qui garantit l'« exactement un » — il a remplacé un ancien schéma « l'époque la plus haute gagne » qui pouvait se réinitialiser au redémarrage et produire brièvement deux nœuds croyant chacun posséder la même partition.

Pourquoi les lectures routées vers le propriétaire vous donnent la lecture de vos propres écritures​

Voici la partie qui répond à la question d'ouverture. Dans Zaris, les lectures routent vers le propriétaire actif, le même nœud où est allée votre écriture. Les clients ne lisent pas depuis les réplicas par défaut. Ainsi, quand vous PutAsync une clé puis la GetAsync, les deux requêtes se résolvent — via la même table de routage, construite à partir de la carte de partitions plus l'instantané de propriété du runtime — vers le même nœud propriétaire, et ce nœud a déjà votre écriture dans son store local.

C'est tout le mécanisme. La lecture de vos propres écritures n'est pas boulonnée comme une garantie de session ou un cache côté client ; elle découle du routage. Vous lisez vos écritures au sein d'une partition parce qu'un nœud unique est l'autorité pour les lectures et les écritures de cette partition à la fois, et les écritures vers lui sont sérialisées une à la fois. Le réplica dans ce schéma pourrait être en retard de quelques millisecondes sur le propriétaire — la réplication a une traîne asynchrone — mais par défaut vous ne lisez jamais le réplica, donc ce retard vous est invisible.

Le qualificatif « au sein d'une partition » porte le poids, et nous reviendrons sur ce qu'il exclut.

La version que vous êtes autorisé à voir​

Chaque valeur que le propriétaire sert porte deux nombres monotones, et ce sont eux qui font de « la même valeur » une affirmation précise plutôt qu'une impression :

• une Revision appartenant au store — un numéro de séquence strictement croissant que le propriétaire estampille sur chaque mutation dans l'ordre de validation, et
• une ItemVersion par élément — la version de cette clé spécifique, qui est ce que IfMatchVersion protège dans une écriture par comparaison-et-échange.

Parce que le propriétaire les assigne dans l'ordre de validation et sert les lectures depuis le même état validé, des lectures successives d'une clé depuis le propriétaire font avancer la version vers l'avant, jamais vers l'arrière. Vous ne lirez pas la version 42, puis la version 40 un instant plus tard. Cette monotonie est exactement ce qui permet à la boucle CAS d'être correcte : un lecteur voit une version, calcule contre elle, et réécrit conditionné au fait qu'elle soit encore cette version. Si le modèle laissait les lectures osciller entre versions, la concurrence optimiste serait bâtie sur du sable. Un propriétaire, des révisions ordonnées par validation, des lectures servies par le propriétaire — c'est le fondement sur lequel repose toute l'histoire de coordination de l'article sur le CAS.

La fenêtre où une lecture dit honnêtement « pas encore »​

Les lectures routées vers le propriétaire sont propres en régime permanent. Les moments intéressants sont les transitions — un basculement, une migration, un primaire préféré qui est rendu — car pendant un transfert, le nœud vers lequel vous routeriez peut ne pas être actuellement l'autorité. Le choix de Zaris ici est l'honnête : plutôt que de servir une lecture depuis un nœud qui n'est pas le propriétaire stabilisé, il renvoie un statut réessayable. Une lecture (ou écriture) pendant une telle fenêtre peut revenir sous la forme :

• Moved — votre table de routage est périmée ; la clé vit sur un nœud différent maintenant.
• OwnershipChanging — la propriété de ce segment est activement en transition en ce moment ; c'est un transfert, pas un bug de routage établi.
• Migrating — le segment est en cours de migration vers un nouveau propriétaire.
• ReplicaSyncPending — ce nœud met à jour la copie d'un segment et ne servira pas encore une lecture possiblement incomplète depuis celui-ci.
• Unavailable — la partition n'a aucun propriétaire joignable à cet instant.

Aucun de ceux-ci n'est une exception que vous devez extraire d'une trace de pile — ce sont des résultats lisibles par machine, et le client .NET les traite comme transitoires et réessaie avec une redirection, rafraîchissant sa carte du cluster et allant vers celui que la carte désigne désormais comme propriétaire. L'effet est que votre GetAsync prend simplement quelques millisecondes de plus puis renvoie la bonne valeur. La décision de conception sous-jacente mérite d'être énoncée clairement : Zaris préfère vous faire attendre un battement plutôt que de vous remettre une lecture dont il n'est pas sûr qu'elle soit autoritaire. Un « pas encore » réessayable est une meilleure réponse qu'une réponse confiante et fausse.

C'est aussi pourquoi la lecture de vos propres écritures survit à un basculement : le travail de barrière d'écriture signifie qu'une écriture acquittée n'est pas laissée pour compte dans la fenêtre de transfert (nous en viendrons à la limite honnête de cela ci-dessous), et la promotion ne fait d'un nœud le propriétaire qu'une fois qu'il est éligible — de sorte que la lecture qui redirige après un basculement redirige vers un nœud qui a vos données.

Le cadran que vous pouvez tourner — et ce qu'il fait réellement aujourd'hui​

Zaris expose une surface de cohérence de lecture. GetOptions porte une ReadConsistency de Leader, Quorum ou Any, et un store a un drapeau AllowReplicaReads (désactivé par défaut). L'intention est le compromis classique : laisser les lectures être servies depuis les réplicas pour répartir la charge de lecture, en échange de l'acceptation qu'un réplica puisse être en retard sur le propriétaire — une péremption bornée à laquelle vous optez délibérément.

Voici l'état actuel honnête, car c'est exactement le genre de chose qu'un texte marketing flouterait : aujourd'hui, les lectures sont réservées au propriétaire. AllowReplicaReads et ReadConsistency.Any sont une surface de configuration et de mise en forme de requête qui existe et transite par la définition du store, mais il n'y a pas encore de chemin de code serveur qui serve réellement une lecture depuis un réplica. En pratique, cela signifie que vous obtenez l'extrémité forte du cadran dès maintenant — chaque lecture est une lecture du propriétaire, donc la lecture de vos propres écritures tient — et que vous n'obtenez pas actuellement le comportement de lecture-de-réplica-périmée, même si vous basculez le drapeau.

Pourquoi mentionner un cadran effectivement épinglé sur un seul réglage ? Parce qu'il vous dit ce que le contrat de cohérence va vous laisser échanger, et parce que l'asymétrie compte quand vous raisonnez sur la péremption. Quand les lectures servies par réplica arriveront, activer AllowReplicaReads sera le moment où vous cesseriez d'être garanti de lire vos propres écritures : une lecture routée vers un réplica peut observer une version en retard sur celle du propriétaire, aussi longtemps que la traîne de réplication asynchrone est en retard. D'ici là, la garantie est plus simple et plus forte que le bouton ne le suggère. Nous préférons que vous le sachiez plutôt que de supposer que vous répartissez déjà les lectures sur les réplicas alors que ce n'est pas le cas.

Ce que « acquitté » signifie pour le prochain lecteur​

La lecture de vos propres écritures concerne vous qui lisez votre propre écriture sur le propriétaire. Une question différente et plus tranchante est : une fois que le propriétaire vous dit qu'une écriture est acquittée, cette écriture est-elle sûre si le propriétaire meurt ensuite, de sorte que le lecteur qui redirige vers le nouveau propriétaire la voit toujours ?

Le contrat d'acquittement honnête d'aujourd'hui : une écriture est acquittée quand elle atterrit dans le store local du propriétaire actif. La réplication vers les RF−1 réplicas suit une traîne asynchrone derrière cet acquittement. Les conséquences valent la peine d'être planifiées plutôt qu'éludées :

• À redondance 1 — aucun réplica synchronisé — une écriture est véritablement au mieux. Elle ne doit pas être traitée comme durable face à une panne unique, car il y a exactement une copie.
• Même avec des réplicas, si l'unique propriétaire actif est perdu dans la fenêtre étroite après qu'il a acquitté une écriture mais avant que cette écriture n'atteigne un réplica, l'écriture acquittée peut être perdue.

La propriété plus forte — acquitter seulement une fois que l'écriture est sur au moins un réplica synchronisé, de sorte qu'une écriture acquittée survive à la perte de n'importe quel nœud — est la cible conçue (la « barrière d'acquittement W1 »), pas encore la sémantique d'acquittement livrée. C'est la direction vers laquelle le travail sur l'épine dorsale de durabilité se consolide, et cet article est prudent sur la même distinction : l'affirmation forte qu'il valide est limitée aux écritures acquittées, lorsqu'un réplica synchronisé existe, sous les classes de pannes que l'exécution de chaos provoque — et non un « rien ne peut jamais être perdu » inconditionnel. La mécanique du journal d'opérations et de la migration est la façon dont un réplica ou un nouveau propriétaire rattrape l'état validé du propriétaire en premier lieu ; la barrière d'acquittement concerne le moment où le propriétaire est autorisé à dire « terminé ».

Donc l'énoncé précis côté lecteur est : la lecture de vos propres écritures sur le propriétaire est solide ; la durabilité inter-pannes d'une écriture acquittée est forte-et-de-plus-en-plus-forte, avec la réserve actuelle énoncée ci-dessus, et un plancher dur au RF1 qu'aucun store ne peut concevoir pour l'éliminer — une copie est une copie.

À travers les partitions, il n'y a pas d'horloge partagée​

Le dernier endroit où le qualificatif « au sein d'une partition » mord : il n'y a pas d'ordre global ni d'instantané à travers les partitions. Chaque partition est sérialisée à travers son propre propriétaire ; deux partitions différentes sont deux propriétaires différents avec deux séquences de révision indépendantes. Si vous écrivez la clé A (partition 1) puis la clé B (partition 2), un lecteur concurrent peut observer la nouvelle valeur de B et l'ancienne de A, ou vice versa — il n'y a pas d'instant à l'échelle du cluster où « les deux se sont produits ». Les opérations en masse et par lot sont par clé en dessous ; elles sont pratiques, pas atomiques.

Quand vous avez véritablement besoin qu'un invariant s'étende sur plusieurs clés — déplacer un solde de A à B, maintenir un index au pas avec l'enregistrement qu'il pointe — c'est exactement à cela que servent les transactions multi-clés. Elles fournissent une isolation Serializable sur une validation coordonnée par le client à travers des versions optimistes, et elles sont la seule surface d'atomicité inter-clés. Les lectures et écritures multi-clés ordinaires ne sont pas une transaction et ne doivent pas être confondues avec une.

Ce qui est, et n'est pas, garanti​

Énoncé clairement, pour que vous puissiez tenir tout le modèle d'un coup :

La forme honnête de la chose​

Un bon modèle de cohérence n'est pas celui avec la plus longue liste de garanties ; c'est celui dont vous pouvez réellement nommer les garanties et dont vous pouvez réellement voir les limites. Zaris trace sa frontière autour de la propriété et est franc sur le compromis : vous obtenez la lecture de vos propres écritures et des lectures monotones au sein d'une partition gratuitement, parce qu'un propriétaire sert les deux côtés et vous remet des versions ordonnées par validation ; vous obtenez un « pas encore » réessayable au lieu d'une réponse confiante et fausse pendant un transfert ; et vous abandonnez la linéarisabilité globale et l'ordre inter-partitions, que vous rachetez explicitement avec une transaction quand un invariant particulier l'exige.

Les deux réserves à garder en tête sont celles que cet article a énoncées plutôt que lissées : le cadran de lecture de réplica est, aujourd'hui, effectivement épinglé sur le réglage fort, de sorte que vous êtes plus cohérent que le bouton ne le laisse croire ; et « acquitté » signifie actuellement sur le propriétaire, avec la durabilité complète face à une panne unique comme cible que le travail de durabilité est en train de livrer, et un vrai plancher à la redondance 1. Connaissez ces deux choses et le reste du modèle est exactement aussi simple qu'il en a l'air : trouvez le propriétaire, lisez vos écritures.

Pour la conception plus profonde, voyez Cohérence et Partitionnement et réplication dans la documentation.

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.

L'activer — exactement à la manière de Redis​

Il n'y a rien de spécifique à Zaris dans la façon dont vous activez ou consommez la fonctionnalité. Pointez n'importe quel client Redis vers la façade RESP et utilisez les commandes que vous connaissez déjà :

# Enable notifications for keyspace (K) and keyevent (E) channels
redis-cli -p 6380 CONFIG SET notify-keyspace-events KEA

# Subscribe to every key-event, cluster-wide
redis-cli -p 6380 PSUBSCRIBE '__keyevent@0__:*'

1) "pmessage"
2) "__keyevent@0__:*"
3) "__keyevent@0__:set"
4) "user:42"

Depuis un client typé — ici StackExchange.Redis — c'est la même forme, sans SDK Zaris impliqué :

var mux = await ConnectionMultiplexer.ConnectAsync("localhost:6380");
var sub = mux.GetSubscriber();

await sub.SubscribeAsync(
    new RedisChannel("__keyevent@0__:expired", RedisChannel.PatternMode.Literal),
    (channel, key) => Console.WriteLine($"key expired: {key}"));