Fragen Sie einen verteilten Store nach einem Key, wird der Aufwand von einer einzigen Zahl dominiert: dem Round-Trip zum Node, der ihn besitzt. Der Lookup selbst dauert Nanosekunden; das Netzwerk Mikrosekunden. Fragen Sie nun nach tausend Keys. Wenn Sie in einer Schleife tausendmal Get aufrufen, zahlen Sie diesen Round-Trip tausendmal, seriell, und der Store verbringt fast die gesamte Wanduhrzeit untätig mit dem Warten auf Pakete. Die Keys könnten auf vier Nodes verteilt sein, die parallel hätten antworten können — aber eine naive Schleife gibt ihnen nie die Chance.

Zaris hat drei Bulk-APIs — GetManyAsync, PutManyAsync, DeleteManyAsync — und darunter ein gemischtes ExecuteBatchAsync, und ihr ganzer Daseinszweck ist, „tausend Keys" in „eine Anfrage pro besitzendem Node, parallel abgesetzt" zu verwandeln. Dieser Beitrag ist der Fan-out-Pfad von Anfang bis Ende: wie der Client Keys nach Owner in Buckets sortiert, warum alle vier APIs auf eine einzige Engine zusammenfallen, wie ein Index-Feld die Antworten durch zwei Schichten von Nebenläufigkeit in Reihenfolge hält und warum — anders als bei einer Multi-Key-Transaktion — eine Bulk-Operation pro Item arbeitet und ein Teilerfolg normal ist.

Das Kostenmodell: Round-Trips, nicht Operationen​

Wogegen eine Bulk-API kämpft, ist nicht die CPU. Ein GET auf einen einzelnen Key ist auf einem besitzenden Node ein Dictionary-Lookup — der Latenzboden ist eine Mikrosekunde echter Arbeit in zehn Mikrosekunden Installation. Der teure Teil ist die Installation: Die Anfrage muss das Netzwerk zum Owner überqueren, und die Antwort muss zurückkommen. Nennen wir diese Round-Trip-Zeit R, in einem Datacenter-Netzwerk typischerweise zehn bis hundert Mikrosekunden, um Größenordnungen mehr als der Lookup.

Eine serielle Schleife über N Keys kostet etwa N × R, weil jeder Aufruf auf die Rückkehr des Pakets des vorherigen wartet, bevor er den nächsten sendet. Das ist die Falle. Die Lösung ist kein schnellerer Lookup — es ist, aufzuhören, R pro Key zu zahlen. Wenn die N Keys auf M besitzenden Nodes liegen, ist der Boden R, M-mal nebenläufig gezahlt, also insgesamt etwa ein R, unabhängig davon, wie viele Keys jeder Node hält. Bei tausend Keys auf vier Nodes ist das der Unterschied zwischen tausend seriellen Round-Trips und effektiv einem. Das gesamte Design unten existiert, um N × R auf ~R zusammenzufalten.

Eine Engine: alles ist ein Batch von Items​

Das erste Überraschende im Cluster-Client ist, dass GetManyAsync, PutManyAsync und DeleteManyAsync nicht drei getrennte Implementierungen sind. Jede ist ein dünner Shim, der ihre Argumente in eine Liste von KvBatchItems verwandelt und an die eine Methode übergibt, die die eigentliche Arbeit erledigt, ExecuteBatchAsync. So macht GetManyAsync genau das:

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 und DeleteManyAsync tun dasselbe mit KvBatchOp.Put und KvBatchOp.Delete. Die Unterscheidung, die die Samples zwischen Bulk (jeweils eine Operationsart) und Batch (eine Mischung aus PUT / GET / DELETE in einem Aufruf) ziehen, ist also eine Annehmlichkeit der Oberfläche: Die Bulk-Helfer sind nur ein Batch, in dem zufällig jedes Item dieselbe Operation hat. Es gibt genau eine Fan-out-Engine, und sie ist operationsagnostisch.

Beachten Sie Index = i. Jedes Item wird mit seiner Position in der Liste des Aufrufers gestempelt, bevor irgendetwas gruppiert, umsortiert oder gesendet wird. Dieser Stempel überlebt die zwei nebenläufigen Hops, die noch kommen, und erlaubt es, die endgültige Antwort wieder in Reihenfolge zu bringen. Merken Sie sich das.

Der Fan-out: nach Owner in Buckets sortieren, je eine Anfrage​

Hier ist das Herz des ganzen Beitrags — der Batch-Dispatch des Cluster-Clients, im Wesentlichen vollständig:

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()
};

Lesen Sie es als vier Züge:

1. Jeden Key lokal zu seinem Owner auflösen. SegmentMapper.ComputeSegmentId ist dieselbe Platzierungsfunktion, die der Single-Key-Pfad nutzt — CRC16 über den Hash-Tag, modulo Segmentanzahl —, und GetClientForSegment bildet dieses Segment auf die bereits geöffnete Verbindung zu seinem besitzenden Node ab. Kein Proxy, kein Koordinator: Der Client berechnet das Ownership selbst, genau wie in Ein Hop zum Owner beschrieben. Der Unterschied ist, dass er das hier für jeden Key der Menge auf einmal tut.

2. Bucketing. Keys, die demselben Node gehören, häufen sich in dessen Liste. Tausend Keys, verteilt auf vier Owner, werden zu vier Listen. Hier werden aus N Operationen M Anfragen.

3. Nebenläufig absetzen. buckets.Select(...) baut pro Owner einen ExecuteBatchAsync-Aufruf, und Task.WhenAll lässt alle gleichzeitig starten. Vier Nodes antworten parallel; die Wanduhrzeit ist die Antwort des langsamsten einzelnen Nodes, nicht die Summe.

4. In Reihenfolge neu zusammensetzen. Jeder Owner liefert seinen Anteil der Ergebnisse; SelectMany flacht sie ab, und OrderBy(r => r.Index) stellt die ursprüngliche Reihenfolge des Aufrufers wieder her. Der Aufrufer erhält eine Liste, in der Position i die Antwort für Key i ist, obwohl die Keys zu verschiedenen Nodes gereist und in der Reihenfolge zurückgekehrt sind, in der das Netzwerk sie lieferte.

Das ist die vollständige Amortisationsbehauptung, konkret gemacht: Die Anzahl der Round-Trips entspricht der Anzahl der verschiedenen besitzenden Nodes in der Key-Menge, nicht der Anzahl der Keys.

Innerhalb eines Owners: wieder nebenläufig, wieder geordnet​

Jeder Sub-Batch pro Owner landet im BatchCommandHandler dieses Nodes. Auch er führt die Items nicht nacheinander aus — er führt sie alle gleichzeitig aus und sortiert dann neu:

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 ist ein kleiner Switch über die Operation, der jedes Item an den Store weiterleitet — GetRawAsync, PutRawAsync oder DeleteRawAsync —, sodass ein gemischter Batch aus Lese- und Schreibzugriffen Item für Item innerhalb derselben Anfrage verarbeitet wird. (Für die In-Process- und Single-Node-Router erscheint dieselbe Form als Parallel.ForEachAsync über die Keys, begrenzt durch MaxDegreeOfParallelism — standardmäßig eine Option MaxParallelism oder Environment.ProcessorCount —, weshalb Lesezugriffe mit Kernen skalieren: Ein dicker Sub-Batch hält jeden Kern beschäftigt statt nur einen.)

Der Index-Stempel verdient sich seinen Lohn also zweimal. Nebenläufigkeit bringt die Reihenfolge auf dem Node durcheinander, daher sortiert der Handler vor der Antwort nach Index. Fan-out bringt die Reihenfolge auf dem Client durcheinander, daher sortiert der Client nach dem Zusammenführen nach Index. Der Aufrufer sieht nie eines der beiden Durcheinander. Eine kleine Ganzzahl, ab dem Moment, in dem die Anfrage gebaut wird, an jedem Item mitgeführt, ist der gesamte Mechanismus, der es sicher macht, „wirf alles parallel auf den Cluster" als geordnete Liste bereitzustellen.

Eine Bulk-Operation ist keine Transaktion​

Das ist die Unterscheidung, die die Leute am häufigsten falsch verstehen, daher soll sie scharf formuliert werden. Jedes Item eines Batches trägt sein eigenes Ergebnis. Der Ergebnistyp pro Item hält Erfolg, Status und — für die Operationen, die sie haben — Revision, Version und TTL dieses einen Keys fest:

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
};

Es gibt keinen gemeinsamen Commit-Punkt. Ein GetMany über hundert Keys, von denen dreißig nicht existieren, liefert siebzig Success-Ergebnisse und dreißig NotFound-Ergebnisse, nach Index verzahnt — keinen Fehler, keine leere Liste. Ein PutMany, bei dem das Segment eines Keys gerade migriert, liefert dieses eine Item mit Status Moved und den Rest mit Success. Teilerfolg ist die normale, erwartete Form der Antwort, und der Aufrufer soll jedes Item prüfen.

Das ist das genaue Gegenteil einer Multi-Key-Transaktion, die per Konstruktion alles-oder-nichts ist: ein clientkoordinierter Two-Phase-Commit über optimistische Versionen, bei dem entweder jeder Key sich bewegt oder keiner. Die beiden Features sehen von außen ähnlich aus — beide nehmen viele Keys in einem Aufruf — und sind für entgegengesetzte Bedürfnisse gebaut. Greifen Sie zu einem Batch, wenn die Keys unabhängig sind und Sie Durchsatz wollen; greifen Sie zu einer Transaktion, wenn eine Invariante die Keys umspannt und ein halb angewendetes Ergebnis sie verletzen würde. Zaris hält sie als getrennte APIs, genau damit die Semantik nie mehrdeutig ist: Ein Batch rollt nie stillschweigend zurück, und eine Transaktion committet nie stillschweigend halb.

Überleben, wenn das Ownership mitten im Batch wandert​

Eine Bulk-Operation ist ein breiteres Ziel als ein einzelnes GET für das Problem, dass sich das Ownership darunter ändert. Zwischen dem Moment, in dem der Client einen Key in den Bucket von Node A sortiert, und dem Moment, in dem Node A den Sub-Batch verarbeitet, kann ein Partition-Cut-over dieses Segment zu Node B verschoben haben. Node A beantwortet diese Items dann mit dem Status Moved, statt zu raten.

Der Cluster-Client umhüllt den gesamten Fan-out für genau diesen Fall mit einem begrenzten Retry:

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);
}

Bei einem Retry hat sich die Routing-Tabelle meist aktualisiert, sodass das erneute Bucketing die verschobenen Keys an ihren neuen Owner sendet. Der Retry ist bewusst flach — zwei Versuche, ein kurzes Backoff —, weil das Ziel ist, eine kurzzeitig veraltete Routing-Tabelle zu überbrücken, nicht einen tatsächlich ausgefallenen Node zu übertünchen. Das ist dieselbe Disziplin wie in Retries bei Ownership-Churn beschrieben, angewendet auf eine ganze Key-Menge auf einmal: Der Retry führt die Gruppierung erneut aus, nicht nur das Senden, sodass jeder Versuch das neueste Ownership widerspiegelt statt einen veralteten Plan zu wiederholen.

Ein echter Bug, weil die Wire-Form zwei Gestalten hat​

Es lohnt sich, eine Stelle zu zeigen, an der dieser Pfad brach, weil sie etwas speziell über Bulk-Operationen aussagt. Der Wert eines GET-Ergebnisses kann auf der Leitung in zwei Formen eintreffen — in einen ZarisEntry-Umschlag gewickelt oder als roher serialisierter Wert —, je nachdem, wie er gespeichert wurde (siehe Was über die Leitung geht). Der ursprüngliche Bulk-GET-Decoder nahm nur die Wrapper-Form an und warf bei der rohen eine Exception.

Bei einem einzelnen GET ist das ein Fehler für einen Key. Bei einem GetMany war es auf subtile Weise katastrophal: Jeder Key im Batch schlug fehl, weil die eine unbehandelte Kodierung eine Exception warf, bevor irgendein Ergebnis dekodiert wurde. Ein Zertifizierungslauf markierte es als „Bulk-Get-Fehler", und die Lösung war, die Dekodierung über einen gemeinsamen Helfer mit Doppel-Kodierung zu leiten, der beide Formen behandelt:

// 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);

Die Lehre, die sich verallgemeinern lässt: In einem Bulk-Pfad wird ein Defekt in der gemeinsamen Maschinerie pro Item mit der Batch-Größe multipliziert, und ein Fehler, der für einen Key lästig ist, ist für tausend ein Ausfall. Das Ergebnismodell pro Item begrenzt den Schadensradius — sobald die Dekodierung korrekt ist, scheitert ein fehlerhafter Wert an einem Item und lässt die anderen 999 intakt.

Was der Fan-out bringt​

Fügt man die Teile zusammen, ist die Form des Gewinns klar. Ein Bulk-Aufruf stempelt jedes Item mit seinem Index, löst den Owner jedes Keys mit derselben Platzierungsmathematik auf, die der Single-Key-Pfad nutzt, sortiert die Keys in Buckets, sodass aus N Operationen eine Anfrage pro besitzendem Node wird, setzt diese Anfragen nebenläufig ab und setzt die Antworten in der Reihenfolge des Aufrufers wieder zusammen — überlebt eine Routing-Tabelle, die sich mitten im Flug verschiebt, und meldet das Schicksal jedes Keys unabhängig. Die Zahl der Round-Trips sinkt von der Zahl der Keys auf die Zahl der Nodes, und das ist die einzige Zahl, auf die es je ankommen konnte.

Nichts davon erforderte einen neuen Speicherpfad oder einen neuen Wire-Record. Die Bulk-APIs sind eine Scheduling-Schicht über den Primitiven, die Zaris bereits hat: die partitionsbewusste Platzierung, die dem Client sagt, wer was besitzt, den Vertrag pro Record, den jedes Item-Ergebnis wiederverwendet, und die kernparallele Ausführung, die einen Sub-Batch durchkaut, sobald er gelandet ist. Der schwere Teil des schnellen Umgangs mit vielen Keys waren nie die Keys — es war die Weigerung, das Netzwerk einen Key nach dem anderen zu bezahlen.

Es gibt zwei ehrliche Wege, einen Client für einen verteilten Cache zu bauen. Der erste: irgendeinen Node wählen, ihm die Anfrage senden und den Cluster sie intern an den Besitzer des Keys weiterleiten lassen — einfach für den Client, aber jede Anfrage, die auf dem falschen Node landet, zahlt für einen zusätzlichen Netzwerk-Hop innerhalb des Clusters. Der zweite: den Client klug genug machen, um zu wissen, welcher Node den Key besitzt, bevor er irgendetwas sendet, sodass der erste Socket, den er berührt, derjenige ist, der tatsächlich antworten kann. Zaris geht den zweiten Weg. Ein GET verlässt Ihren Prozess bereits an den Node adressiert, der den Key hält — kein Proxy, kein Weiterleitungs-Hop, kein Koordinator in der Mitte.

Dieser Beitrag ist der Blick ins Innere, wie das funktioniert: die Funktion, die einen Key in einen Owner verwandelt, die Lookup-Tabelle, die der Client im Speicher hält, und — der Teil, den man leicht falsch macht — wie der Client korrekt bleibt, wenn sich das Ownership bewegt, während Ihr Traffic unterwegs ist.

Die Behauptung, präzise formuliert​

Wenn Sie client.GetAsync("user:42") aufrufen, tut der Client drei Dinge, bevor irgendwelche Bytes das Netzwerk berühren:

1. Den Key auf ein Segment hashen. Eine reine Funktion bildet den Key-String auf eines der Segmente des Clusters ab.
2. Den Owner des Segments nachschlagen. Ein In-Memory-Array bildet dieses Segment direkt auf die eine Verbindung ab, die den aktiven Owner-Node erreicht.
3. Owner-direkt senden. Die Anfrage geht über diese Verbindung und nirgendwo sonst hin.

Kein Schritt befragt einen zentralen Router. Schritt 1 ist Arithmetik, die Schritte 2 und 3 sind ein Array-Index und ein Socket-Schreibvorgang. Der Client hält eine Verbindung pro Node und eine kleine Routing-Tabelle, und das ist die gesamte Apparatur. Das Interessante an der Ingenieursarbeit ist nicht der Happy Path — es ist, diese Tabelle ehrlich zu halten.

Schritt 1 — der Key wird zu einem Segment​

Zaris hasht Keys absichtlich genau so wie ein Redis-Cluster-Client. Die Platzierungsfunktion lebt in SegmentMapper, und ihr Doc-Kommentar ist unverblümt darüber, warum sie so aussieht, wie sie aussieht:

// 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.

Diese letzte Zeile ist die wichtigste. Es heißt nicht „der Client berechnet die Platzierung auf die eine Weise und der Server validiert sie auf eine andere." Es ist derselbe Code, in die Client-Assembly und die Server-Assembly kompiliert, der jedes Mal dasselbe Segment für denselben Key erzeugt. Wären sich Client und Server uneinig, wo ein Key lebt, wäre jeder Schreibzugriff ein Münzwurf zwischen der Landung beim Owner und der Landung auf einem Node, der ihn ablehnen muss. Das Teilen der Funktion macht diese Klasse von Bugs nicht darstellbar.

Die Berechnung selbst besteht aus zwei Zügen:

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
}

Zuerst wird der Key mit XMODEM-CRC16 auf einen Slot im festen Bereich [0, 16384) reduziert — dasselbe CRC16-CCITT-Polynom (0x1021, Init 0x0000), das Redis verwendet. Dann werden die 16384 Slots proportional auf so viele Segmente abgebildet, wie der Cluster tatsächlich hat:

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

Zwei Slots können im selben Segment landen; ein Segment ist ein zusammenhängender Bereich von Slots. Diese Ausrichtung erlaubt es Zaris, CLUSTER SLOTS für einen Redis-Cluster-Client korrekt zu beantworten und intern dennoch nach seinem eigenen Segmentmodell zu routen — die beiden Sichten sind dieselbe Sicht in unterschiedlicher Auflösung.

Hash-Tags: entscheiden, was co-lokalisiert wird​

Im Key-Hashing gibt es eine bewusste Hintertür. Enthält ein Key eine {...}-Gruppe mit mindestens einem Zeichen zwischen den Klammern, werden nur die Bytes innerhalb der Klammern gehasht:

// 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.

So erzwingen Sie, dass zusammengehörige Keys auf demselben Segment landen. {u1}:profile und {u1}:sessions hashen beide auf u1, teilen also ein Segment und damit einen Owner — genau das, was Sie für eine Multi-Key-Transaktion oder jede Operation brauchen, die mehrere Keys atomar auf einem Node berühren muss. Keys ohne Tag verteilen sich über den gesamten Keyspace. Auch hierin sind sich Client und Server einig, denn auf beiden Seiten ist es dasselbe HashTagRange.

Ein weiteres Detail für den Hot Path: Die CRC16-Schleife hat einen reinen ASCII-Schnellpfad, der die Zeichen ohne Allokation als Bytes hasht und nur für Nicht-ASCII-Keys auf ein UTF-8-Encoding zurückfällt. Jede Operation zu routen heißt, dass dies bei jeder Operation läuft, daher wurde es so geschrieben, dass es im Normalfall nicht allokiert.

Schritt 2 — das Segment wird zu einer Verbindung​

Jetzt hat der Client eine Segmentnummer. Er braucht den Node, der es gerade besitzt. Der Client hält eine unveränderliche RoutingTable, deren Felder die ganze Geschichte erzählen:

// 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; }

Die zentrale Designentscheidung ist SegmentMap. Es ist ein nach Segment indiziertes Array, dessen Einträge bereits aufgelöst sind auf die Verbindung zum Owner dieses Segments. Einen Key zu routen ist kein Graphdurchlauf von Segment über Partition und Node zur Verbindung zur Request-Zeit — diese Auflösung geschieht im Voraus, wenn die Tabelle gebaut wird, sodass die Kosten pro Request ein einziger Array-Index sind:

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 hält genau einen ZarisRemoteClient — eine Verbindung — pro Node. Der Client öffnet keinen frischen Socket pro Request oder pro Key; er multiplext den gesamten Traffic für einen Node über dessen einzelne Verbindung, und SegmentMap zeigt mit vielen Segmenten einfach auf dasselbe Verbindungsobjekt (Referenzgleichheit dedupliziert sie, wenn der Client die Menge der verschiedenen aktiven Owner braucht, zum Beispiel für den Fan-out eines Scans). Die Speicherkosten der Partitionsbewusstheit sind also eine Verbindung pro Node plus ein paar Arrays in Größe der Segmentanzahl — sie wachsen nicht mit der Zahl der Keys oder Requests.

Der Gewinn: Es gibt keinen Node im Cluster, dessen Aufgabe es ist, fehlgeroutete Requests entgegenzunehmen und weiterzuleiten. Jeder gut geroutete Request wird vom ersten Node bedient, den er erreicht. Das entfernt eine ganze Ebene aus dem Latenzbudget und, ebenso wichtig, aus der Fehlerfläche — man kann keinen Request in einem Weiterleitungs-Hop verlieren, den es nicht gibt. (Der Begleitbeitrag zum Latenzboden geht durch, was im Budget übrig bleibt, sobald der Proxy-Hop weg ist.)

Schritt 3 — die Map bewegt sich unter Ihnen​

Hier kommt der schwere Teil. Die Routing-Tabelle ist ein Cache einer Tatsache — „Segment S gehört Node N" —, die der Cluster jederzeit ändern kann. Ein Owner kann ausfallen, und eine Replica wird befördert; eine Partition kann migriert werden, um einen Node zu vergrößern oder zu leeren. Sobald das geschieht, zeigt SegmentMap[S] des Clients auf eine Verbindung, die nicht mehr der Owner ist. Ein Client, der seiner Tabelle blind vertraute, würde Schreibzugriffe an einen Node senden, der sie korrekterweise ablehnt.

Zaris hält die Tabelle auf drei Wegen ehrlich, in der Reihenfolge der Präferenz.

Push — der Server sagt es dem Client. Ändert sich das Ownership, sendet der Cluster ein RuntimeOwnershipChangedEvent, und der Client hat einen Handler, der es abonniert hat:

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

TryUpdateRuntimeOwnership baut nicht die ganze Tabelle neu. Es klont das SegmentMap-Array, setzt nur die Segmente um, deren Partition tatsächlich den Owner gewechselt hat, und tauscht die unveränderliche Tabelle mit einer einzigen Referenzzuweisung aus. Leser sehen nie eine halb aktualisierte Tabelle — sie lesen entweder die alte oder die neue, nie eine zerrissene Mischung. Das ist Copy-on-Write-Routing: Der Normalfall (nichts hat sich geändert) kostet nichts, und eine Änderung berührt nur die betroffenen Segmente.

Poll — ein langsamer Backstop. Ein Timer aktualisiert die Cluster-Map unabhängig davon alle zehn Sekunden, sodass sich die Sicht des Clients selbst dann innerhalb eines Intervalls heilt, wenn ein Push-Ereignis verpasst wird (ein Reconnect, eine verlorene Benachrichtigung):

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

React — der Request selbst korrigiert die Map. Die letzte Verteidigungslinie ist der Request, der falsch routet. Sendet der Client an einen Node, der nicht mehr der Owner ist, leitet der Node ihn nicht stillschweigend weiter — er liefert einen Status zurück, der dem Client sagt, dass seine Map veraltet ist, und der Retry-Helfer aktualisiert und versucht es erneut:

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;

Kommt eine wiederholbare Operation mit Moved, OwnershipChanging oder ReplicaWriteRejected zurück, ruft der Client seinen Refresh-Hook auf und versucht es erneut — eine begrenzte Schleife mit einigen Versuchen und kurzem Backoff, kein offenes Drehen im Kreis. Im aktuellen Code steckt eine subtile Lehre: Eine frühere Version aktualisierte die Map bei jedem Retry-Versuch, was bei starkem Node-Churn eine einzelne fehlschlagende Operation in Dutzende Aktualisierungen verwandelte, die alle hinter einem Lock serialisiert waren. Die Lösung war, nur dann zu aktualisieren, wenn der Status tatsächlich sagt „Ihre Map ist falsch", nicht schon deshalb, weil ein Versuch fehlschlug. Die tiefere Behandlung dieser Retry-Disziplin ist ein eigener Beitrag — Retries bei Ownership-Churn —, aber die Kurzfassung lautet: Eine veraltete Map ist ein selbstkorrigierender Zustand, und die Korrektur ist gerade deshalb billig, weil sie selten und gezielt ist.

Die drei Mechanismen schichten sich: Push macht den Normalfall sofortig, Poll macht einen verpassten Push letztlich konsistent, und der reaktive Retry macht jede verbleibende Veraltung für Ihren Aufruf unsichtbar — er kostet im Moment des Ownership-Wechsels einen zusätzlichen Round-Trip und ist ab dem nächsten Aufruf korrekt.

Warum überhaupt auf dem Client?​

Partitionsbewusstes Client-Routing kostet etwas. Der Client muss ein Modell des Clusters tragen, es aktuell halten und dieselbe Platzierungslogik mitliefern wie der Server. Ein Proxy-basiertes Design schiebt all das in den Cluster und lässt den Client dumm bleiben. Warum also zahlen?

Weil die Alternative bei jedem einzelnen Request für immer zahlt. Ein Proxy oder ein Design „an irgendwen senden, wir leiten es weiter" fügt dem Hot Path jeder Operation einen Hop hinzu — einen Hop, der reiner Overhead ist, selbst wenn nichts ausgefallen ist und nichts sich bewegt. Zaris zahlt die Kosten des Routings einmal, im Voraus, und nur dann wieder, wenn sich das Ownership tatsächlich ändert — was in einem gesunden Cluster fast nie vorkommt. Der Normalzustand ist ein Array-Index und ein Socket-Schreibvorgang zum richtigen Node. Das ist der ganze Grund, warum Lesezugriffe mit Ihren Kernen skalieren, statt an einer mittleren Ebene zum Flaschenhals zu werden: Es gibt keine mittlere Ebene, die zum Flaschenhals werden könnte.

Und es lässt sich mit allem anderen kombinieren. Dieselbe Auflösung GetClientForKey ist das, worüber ein Key-Watch, ein Counter-Inkrement, ein Compare-and-Swap und eine Datenstruktur-Operation auf einem einzelnen Key alle routen, sodass sie alle die Owner-direkte Zustellung und dieselbe selbstheilende Map erben. Der Client ist keine dumme Leitung mit angeschraubtem Routing; das Routing ist das, was der Client ist.

Die ehrlichen Kompromisse​

Owner-direktes Routing ist nicht frei von Kanten, und es lohnt sich, sie zu benennen.

• Der Client muss jeden Node erreichen können. Da es keinen Proxy gibt, öffnet der Client eine Verbindung zu jedem Node, zu dem er routet. In einem flachen Netzwerk ist das kein Problem; über eine Grenze hinweg — sagen wir, ein Client außerhalb von Kubernetes — müssen diese Nodes einzeln adressierbar sein. Genau dieses Problem soll die Adressierung externer Clients lösen, und es ist eine direkte Folge davon, dass es keine einzelne Eingangstür gibt.
• Eine kurze Map-Verzögerung ist möglich, kein Verlust. In dem Fenster zwischen dem Wandern des Ownerships und dem Erfahren des Clients kann ein Request zum alten Owner routen. Er wird abgelehnt und wiederholt, nicht falsch angewendet — der reaktive Pfad oben garantiert, dass der Retry beim echten Owner landet. Sie zahlen einen Round-Trip, keine falsche Antwort.
• Die Platzierungsfunktion ist ein Kompatibilitätsvertrag. Weil Client und Server SegmentMapper teilen, können Sie nicht ändern, wie Keys auf Segmente gehasht werden, ohne dass beide Seiten zustimmen — genau deshalb wurde das Hashing am stabilen Redis-Slot-Modell ausgerichtet statt an einem internen Schema, das driften könnte.

Klar gesagt: Der Zaris-Client weiß, wo Ihre Keys leben, hält dieses Wissen aktuell, ohne dass Sie daran denken müssen, und verbraucht für jede Operation einen Netzwerk-Hop — den, der tatsächlich die Arbeit erledigt. Die Raffinesse liegt nicht im schnellen Pfad, der bewusst langweilig ist. Sie liegt in den drei stillen Mechanismen, die den schnellen Pfad korrekt halten, während sich der Cluster unter ihm neu formt.

Ein Failover deckt den Moment ab, in dem ein Owner stirbt: Der Cluster wählt einen Überlebenden und bedient weiter. Eine geplante Migration deckt das absichtliche Verschieben der Partition eines gesunden Owners ab. Dieser Beitrag handelt vom dritten Akt, dem, der nach dem Ende der Sirenen abläuft — der ursprüngliche Owner-Prozess startet neu, tritt dem Cluster wieder bei und will seine Partition zurück. Sein Store, der nichts auf der Platte und alles im Speicher hält, kam leer zurück. Die Daten, für die er verantwortlich ist, leben noch, aber auf den Replicas, die weiter bedient haben, während er ausgefallen war.

Das gesamte Korrektheitsproblem steckt in einem Satz: Dem neu gestarteten Owner darf nicht erlaubt werden, seiner eigenen Leere zu trauen. Ein leerer Store sieht genau so aus wie ein Store, den jemand bewusst geleert hat. Nimmt der Node an „ich bin der Owner und habe keine Daten, also ist diese Partition leer", wird er bereitwillig NotFound für Millionen lebender Keys ausliefern und, schlimmer, seinen leeren Zustand zurück auf die Replicas fließen lassen und sie löschen. Dieser Beitrag geht die fünf kleinen, reinen Policies durch, mit denen Zaris sicherstellt, dass das nie geschieht.

Warum Leere von innen nicht entscheidbar ist​

Beginnen wir mit der Falle, denn jede Regel unten ist von ihr geprägt. Ein Node, der hochfährt und null Records für ein Segment hält, das er besitzt, befindet sich in einem von zwei Zuständen, und er kann allein aus lokalen Informationen nicht sagen, in welchem:

1. Er ist leer, weil er gerade neu gestartet ist und seine Daten nie zurückgeholt hat. Er muss pullen.
2. Er ist leer, weil er diese Keys maßgeblich gelöscht hat oder sie abgelaufen sind, und eine Replica, die kurz ausgefallen war, hält noch die veralteten Kopien. Pullt er, lässt er gelöschte Daten wiederauferstehen.

Diese beiden sind lokal ununterscheidbar — der Store ist in beiden Fällen leer. Eine frühere Version von Zaris versuchte, das mit einem EmptyActive-Anomaliesignal aufzulösen, und es wurde gerade deshalb entfernt, weil das Signal eine Vermutung ist. Man kann nicht fragen „bin ich aus gutem Grund leer?" und von dem leeren Node eine vertrauenswürdige Antwort erhalten.

Zaris fragt die Leere daher gar nicht erst. Es leitet die Entscheidung über eine andere Tatsache: ein klebriges Flag auf Partitionsebene namens certified, das genau bedeutet: „Mein Startup-Sync ist abgeschlossen, und mein Store ist nun maßgeblich." Ein Node setzt es erst, nachdem er den Besitz nachgewiesen hat. Ein frisch neu gestarteter Owner ist per Definition nicht certified — und ein nicht zertifizierter Owner hat keine Autorität, leer zu sein. Er muss von dem pullen, der die Daten hält. Ein zertifizierter Owner ist maßgeblich und wird strikt in Ruhe gelassen, sodass ein legitimes Leeren nie wiederaufersteht.

Diese eine Umdeutung — von Leere (unentscheidbar) zu Zertifizierung (eine nachgewiesene, klebrige Tatsache) — macht den Rest der Wiederherstellung sicher.

Schritt 1 — der neu gestartete Owner pullt, statt anzunehmen​

Wenn der Node wieder beitritt, weist die Map ihn weiterhin als Owner seiner alten Partition aus. Der Reverse-Sync-Trigger entscheidet, ob jedes besessene Segment von einer Live-Replica gepullt werden soll, statt als lokal maßgeblich behandelt zu werden:

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

Drei Dinge an diesem winzigen Prädikat sind tragend, und jedes ist ein Bug, der einen Zertifizierungslauf erreichte, bevor die Regel aufgeschrieben wurde.

Es ignoriert isMapPreferredPrimary. Dieser Parameter wird weiterhin übergeben — als dokumentierter Entscheidungskontext —, aber die Entscheidung liest ihn bewusst nicht. Eine frühere Version löste Reverse-Sync nur aus, wenn der Node zusätzlich der bevorzugte Primary der Map war. Ein Node, der zur Laufzeit aktiv, aber nicht der Map-Primary ist — genau der Zustand, in dem ein neu verorteter oder nach der Wiederherstellung beförderter Owner landet —, hatte seine besessenen Segmente komplett übersprungen. Er forderte seine Daten nie an und blieb für immer leer gestrandet, während eine Live-Replica jeden Record hielt (ein Cert-Lauf: Active hielt 0, Replica hielt 4600 auf fünfzehn Segmenten, über acht Minuten nie konvergiert). Das Ownership des Daten-Pulls darf nicht daran hängen, der bevorzugte Primary zu sein; es muss für jeden nicht zertifizierten Active feuern.

Das Signal ist !partitionCertified, nicht Leere. Das ist die Lösung der Unentscheidbarkeit aus dem vorigen Abschnitt, als Code. Ein nicht zertifizierter Active hat den Besitz nie nachgewiesen, also pullt er; ein zertifizierter ist maßgeblich und wird übersprungen.

liveNonSelfReplicaExists ist ein Guard, keine Nettigkeit. Ist die konfigurierte Replica ausgefallen, gibt es nichts, wovon man synchronisieren könnte. Die Wiederherstellung gegen eine tote Quelle zu treiben dreht sich ewig im Kreis (RECOVERY STUCK source=self synced=0/128). Existiert also keine Live-Replica, ist der Active die einzige überlebende Kopie — er ist die Autorität und zertifiziert sofort, statt auf eine Quelle zu warten, die nie antworten wird. Der Pull selbst ist durch Revisionen abgesichert und durch ein Watermark begrenzt, was ihn zu einem harmlosen No-op macht, wenn die Replica zufällig nichts hält.

Schritt 2 — einen Key nicht bedienen, bei dem man noch nicht aufgeholt hat​

Das Pullen ist nicht augenblicklich, und das Fenster, während es läuft, ist der Ort, an dem bestätigte Lesezugriffe stillschweigend zu NotFound werden. Ein naives Gate ist ein einzelner Boolean, IsSynced, der bedeutet „ein Sync-Durchlauf ist beendet." Dieser Boolean reicht nicht, und drei getrennte Cert-Fehler bewiesen es: Ein zurückfordernder Active wurde 34 Keys zu kurz befördert; ein Handoff verlor einen bestätigten Key; ein wieder beitretender Active lieferte während des Churns für 57 Keys NotFound. In jedem Fall war ein Sync-Durchlauf beendet — aber die Quelle (der temporäre Active, der weiter bediente) hatte inzwischen mehr Schreibzugriffe akzeptiert, die der wiederherstellende Node nicht gepullt hatte. IsSynced war true, und der Node hinkte trotzdem hinterher.

Die Lösung ist, an einer Position zu gaten, nicht an einem Flag. Die Op-Log-Revision ist eine replizierte, nodeübergreifend vergleichbare Zahl: Der Active vergibt sie und verschickt sie, sodass eine aufgeholte Replica zum selben Head konvergiert. Das Serve-Gate vergleicht Heads:

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 ist der neue Zustand, auf den es ankommt: Ein Sync-Durchlauf wurde beendet, aber der Head der Quelle (bei diesem Sync erfasst) liegt vor unserem, die Quelle hat also Schreibzugriffe akzeptiert, die wir nicht gepullt haben. Jetzt zu bedienen würde für genau diese Keys NotFound liefern. Der Node hält an, bis sein lokaler Head das Watermark erreicht. Beachten Sie den bewussten Rückfall: Ein aufgezeichnetes Watermark von 0 bedeutet „keine Watermark-Information", und das Gate fällt auf das reine IsSynced-Verhalten zurück, statt für immer an fehlenden Daten zu blockieren. Die Regel blockiert nie an der Abwesenheit einer Tatsache — nur an einer Tatsache, die sagt: Sie hinken hinterher.

Schritt 3 — pullen, aber nicht überschreiben​

Nun die gefährliche Richtung: den Snapshot anwenden, den die Replica zurückschickt. Der Instinkt ist, den lokalen Store zu leeren und den Snapshot im Ganzen hineinzukopieren. Dieser Instinkt ist genau zur Hälfte richtig und zur anderen Hälfte katastrophal falsch. Die entscheidende Frage ist, wessen Revisionen mit wessen vergleichbar sind:

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

Drei Ergebnisse:

• Skip — die Content-Digests stimmen bereits überein. Nichts zu übertragen, nichts anzuwenden. (Siehe das Cut-over-Protokoll, warum ein Content-Digest und keine Revisionszählung das ist, was sich zu vergleichen lohnt.)
• Reconcile (nicht-destruktiv) — der lokale Node ist ein rein passiver Subordinate des einen Live-Actives. Seine Revisionen pro Key stammen alle von diesem einen Active und sind daher direkt vergleichbar. Der Snapshot wird revisionsgesichert gemergt: Ein PutRaw behält den lokal neueren Record und füllt fehlende Keys auf; Tombstones werden über DeleteRaw angewendet. Entscheidend: Dies bewahrt Schreibzugriffe, die die Replica über den Live-Kanal während eines langsamen Bootstraps angesammelt hat, statt sie durch vorheriges Leeren wegzuwerfen.
• Wipe (destruktives Leeren + Kopieren) — der lokale Node ist oder war selbst ein Active für diese Partition. Zwei unabhängig aktive Nodes haben unvergleichbare Revisionen pro Key: Dieselbe Revisionsnummer bezeichnet auf beiden unterschiedliche Schreibzugriffe. Sie zu mergen würde stillschweigend zwei Historien verzahnen. Der einzig sichere Schritt ist also, den lokalen Zustand zu verwerfen und den maßgeblichen Snapshot im Ganzen zu übernehmen.

Der Default ist die sichere destruktive Kopie; Reconcile wird nur freigeschaltet, indem nachgewiesen wird, dass der Node ein rein passiver Subordinate ist. Das ist der „Wipe-Guard": Er verhindert den gefährlichen Merge über zwei frühere Actives hinweg und verhindert symmetrisch, dass ein Komplett-Wipe gute Live-Kanal-Schreibzugriffe auf einer einfachen Replica verwirft.

In priorReconcileShortfall steckt noch eine Falte, die direkt aus einem Abbruch der Zwölf-Stunden-Zertifizierung stammt. Ein revisionsgesicherter Reconcile kann Records aussperren, die er hätte anwenden sollen, und abschließen, während er noch hinter dem maßgeblichen Snapshot liegt — ein Segment hing bei 12643/15435 über 232 Sync-Sessions fest und stimmte jedes Mal dieselben Records aus dem Fenster ab, in einer Endlosschleife. Das Flag sagt: Wenn ein früherer Reconcile abgeschlossen wurde, uns aber zu kurz hielt, hör auf zu reconcilen und eskaliere zu einem Wipe, damit der eingefrorene Snapshot im Ganzen übernommen wird und wir tatsächlich konvergieren. Es wird nur nach einem gemessenen Defizit gesetzt — eine vorauseilende oder gleichstehende Replica löst es nie aus, sodass Live-Kanal-Schreibzugriffe nie verworfen werden, um einem Phantom nachzujagen.

Schritt 4 — die andere Seite: ein nicht zertifizierter Owner kann trotzdem eine gute Quelle sein​

Bei der Wiederherstellung geht es nicht nur um den Node, der hinterherhinkt. Betrachten Sie den Spiegelfall: Node A startet neu, und Node B — eine Replica, die ausgefallen war — will nun von A synchronisieren. Soll A die Anfrage bedienen, solange A selbst noch nicht zertifiziert ist?

Der naive Guard sagt nein: „nicht zertifiziert heißt, mein Store ist leer, ein Bedienen würde B's gültige Daten mit meiner Lücke überschreiben." Aber diese Prämisse ist in dem Moment falsch, in dem A die maßgebliche Kopie tatsächlich hält — was auf zwei Wegen geschieht: A war ein bevorzugter Primary, der vor der Beförderung den Catch-up verifizierte, dessen Beförderungspfad aber nie CertifyPartition aufrief (das klebrige Flag bleibt also false, obwohl die Daten alle da sind), oder A übernahm das Ownership über eine Wiederherstellung nach Totalausfall der Partition und hält als Active die vollständigen Daten, ohne je als IsSynced gestempelt worden zu sein. In beiden Fällen ist A's Kopie die Quelle der Wahrheit, und die Verweigerung ließ die Replica bei null gestrandet zurück (ein Dump: 1.792 verweigerte Requests; ein anderer: alle 128 Segmente für eine ganze Partition verweigert).

Der Guard auf der Quellseite wird daher datenbewusst gemacht:

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

Verweigert wird nur, wenn der Node der Owner ist, nicht zertifiziert ist und das Segment sowohl unsynchronisiert ist als auch keine Daten hält — der eine echte Fall „mitten in der Wiederherstellung und tatsächlich leer", in dem das Bedienen einer Lücke den Anfragenden gegen sie zertifizieren lassen könnte. Da der Empfänger jeden Chunk revisionsgesichert anwendet, ist das Bedienen echter Daten immer sicher; der Guard beschränkt die Verweigerung auf den einen Zustand, in dem es nichts Sicheres zu bedienen gibt.

Schritt 5 — den Sieg erklären, genau einmal​

Schließlich hat der wiederherstellende Active jedes besessene Segment gepullt und jedes auf den Head seiner Quelle aufgeholt. Er ist wieder maßgeblich und muss das sagen — das klebrige Certified-Flag umlegen —, damit der Reverse-Sync-Trigger aus Schritt 1 aufhört, seine Segmente erneut einzureihen, und der Cluster die Partition als konvergiert registriert.

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

Die Zertifizierung ist der symmetrische Abschluss des Triggers: Der Trigger reiht die Segmente eines nicht zertifizierten Actives zum Pullen ein; dies hier legt das Flag um, sobald jedes besessene Segment synchronisiert ist, und die Partition beruhigt sich. Der bisherige Certify-Pfad lief nur für den bevorzugten Primary der Map, sodass ein neu verorteter Nicht-Primary-Active zwar alle seine Daten korrekt pullte und dann nie zertifizierte — er reihte Reverse-Sync endlos neu ein, und der Cluster registrierte sich nie als konvergiert (ein Lauf: 30 Checkpoints liefen ~106 Sekunden nach dem Start in den Timeout, während Missing=0 und die Zählungen nie auseinanderliefen — die Daten waren richtig, nur das Zur-Ruhe-Kommen fehlte).

Und beachten Sie die eine Abkürzung, die diese Policy bewusst verweigert: Es gibt keinen Pfad „keine Live-Replica, also zertifiziere ich meine Leere als Autorität" für einen Nicht-Primary-Active. Ein Nicht-Primary-Active ist nicht die Autorität der Map; ihn leer zu zertifizieren, während eine vorübergehend ausgefallene Replica die Daten noch hält, würde dieser Replica erlauben, später von diesem leeren Node zu synchronisieren und alles zu verlieren. Die Autorität, leer zu sein, gehört nur dem bevorzugten Primary der Map, in seinem eigenen Reconcile-Pfad. Überall sonst bringt Leere nichts ein.

Die Form des Ganzen​

Tritt man zurück, sind die fünf Policies eine Idee an fünf Stellen angewendet: Besitz wird nachgewiesen, nie angenommen.

• Ein neu gestarteter Owner ist nicht zertifiziert, also pullt er, statt seinem leeren Store zu trauen (Schritt 1).
• Er bedient ein Segment nicht, bevor sein Op-Log-Head den der Quelle erreicht — ein beendeter Sync-Durchlauf ist nicht dasselbe wie aufgeholt zu sein (Schritt 2).
• Er mergt, statt zu überschreiben, wenn Revisionen vergleichbar sind, und überschreibt, statt zu verzahnen, wenn sie es nicht sind (Schritt 3).
• Als Quelle bedient er immer dann, wenn er die Daten wirklich hält, und verweigert nur, wenn er mitten in der Wiederherstellung wirklich leer ist (Schritt 4).
• Er zertifiziert — legt das klebrige Autoritäts-Flag um — nur auf den Nachweis, dass jedes besessene Segment synchronisiert ist, ohne eine Abkürzung „Leere als Autorität" für einen Nicht-Primary (Schritt 5).

Jede dieser Regeln ist ein reines, IO-freies Prädikat — eine Handvoll Booleans und zwei Revisionsnummern hinein, eine Entscheidung heraus —, weshalb sie isoliert unit-testbar sind und jede an genau den Zertifizierungsfehler festgenagelt werden konnte, der sie motivierte. Sie sind die Innenansicht der Invariante, die die zwölfstündige Chaos-Zertifizierung von außen beweist: einen Owner mitten im Flug töten, seine Replicas die Last tragen lassen, ihn zurückbringen und zusehen, wie Missing=0 über Millionen bestätigter Operationen hält. Der Grund, warum der Neustart keinen Schreibzugriff verliert, ist, dass dem zurückkehrenden Owner nie auch nur einmal erlaubt wird, seiner eigenen Leere zu glauben. Er muss sich seine Daten zurückverdienen — von den Replicas, die sie in Sicherheit gehalten haben.

Wenn Sie die Teile wollen, auf die sich dies stützt: Das wiederholbare Op-Log macht „hole meinen Head auf den Head der Quelle auf" zu einer echten, lückenlosen Operation, und Eigene Schreibzugriffe lesen ist das clientseitige Versprechen, das das Serve-Gate aus Schritt 2 einhalten soll.

Die meisten Texte über verteilte Stores handeln vom Normalbetrieb — Lesen, Schreiben, Replikation — oder von den dramatischen Ausfällen: einem Failover, wenn ein Owner stirbt, oder einem Cut-over, wenn eine Partition umzieht. Doch es gibt einen leiseren Moment, der darüber entscheidet, ob all das funktioniert: der Moment, in dem der Cluster hochfährt. Bevor auch nur ein Key geroutet werden kann, müssen sich die Nodes einigen, wer zum Cluster gehört, wem welcher Ausschnitt des Keyspace gehört und — der Schritt, den die meisten Systeme falsch machen — ob es überhaupt sicher ist, mit dem Bedienen zu beginnen.

Dieser Beitrag folgt dieser Boot-Sequenz in der Reihenfolge, in der Zaris sie tatsächlich ausführt: Mitgliedschaft, Partition-Map und die Readiness-Gates, die zwischen „der Prozess läuft" und „der Node nimmt Traffic an" stehen. Außerdem ziehen wir ehrlich eine Grenze zwischen dem, was Zaris selbst implementiert, und dem, was es von der zugrunde liegenden Cluster-Laufzeit erbt, auf der es aufbaut.

Wer gehört zum Cluster: Mitgliedschaft​

Das Erste, was ehrlicherweise gesagt werden muss, ist, wo die Grenze verläuft. Der Low-Level-Mitgliedschaftstransport — Peer-Heartbeats, Fehlererkennung und Leader-Election — wird von der Schicht Clustron.Nodus bereitgestellt, auf der Zaris aufbaut. Zaris nutzt sie über ein INodusNode-Interface: Es fragt Nodus, wer die Mitglieder sind und wer die Leadership hält, und wird benachrichtigt, wenn der Heartbeat eines Peers ausbleibt oder fehlschlägt. Zaris implementiert Raft oder ein Gossip-basiertes Discovery-Protokoll nicht neu; es setzt seine eigene Partition- und Ownership-Steuerungsebene auf diesem Fundament auf.

Was Zaris hinzufügt, ist eine explizite Mitgliedschafts-Zustandsmaschine, die rohe Heartbeat-Ereignisse in Ownership-relevante Entscheidungen übersetzt. Sie lebt in MembershipStateTracker, und ihre Zustände sind bewusst differenzierter als „oben / unten":

Die Zustände fallen in zwei Gruppen, und genau diese Trennung ist der Kern. Alive, Suspected und Unreachable betreffen nur das Laufzeit-Ownership — sie können eine Replica-Promotion auslösen oder eine Partition vorübergehend als nicht verfügbar markieren, aber sie verändern niemals die Partition-Map. Nur Lost, Evicted und Decommissioned machen einen Node für eine Neuberechnung der Map zugänglich.

Diese Unterscheidung existiert, weil das Neuberechnen der Partition-Map teuer und, wenn zu voreilig, gefährlich ist — es kann gesunde Partitionen unnötig umverteilen. Wenn also der Heartbeat eines Nodes ausfällt, schreibt Zaris die Map nicht sofort neu. Es setzt den Node auf Unreachable und startet eine Karenzzeit (standardmäßig 30 Sekunden). Während dieses Fensters führt der Cluster nur ein Laufzeit-Failover durch — er befördert eine Replica, damit Lese- und Schreibzugriffe weiterfließen — und gibt dem Node die Chance zurückzukehren. Ein Flattern, eine GC-Pause, ein kurzer Netzwerkaussetzer: Nichts davon soll das Ownership neu schreiben. Erst wenn die Karenzzeit abläuft, wird der Node zu Lost, und erst wenn eine ganze Partitionsgruppe entfernt wurde, wird der einzige fehlergetriebene Pfad zur Map-Neuberechnung ausgelöst. Die Designregel, im Code, der sie verdrahtet, klar formuliert, lautet: Ein ausscheidender Node berechnet die Map niemals von sich aus neu.

Wie sich Nodes finden​

Das Discovery ist Roster-basiert, nicht Gossip-Discovery. Die maßgebliche Liste der Nodes ist Konfiguration, nichts, was der Cluster zur Laufzeit aufspürt. In einer handgeschriebenen Konfiguration ist es das nodes-Array — jeder Eintrag deklariert eine ID, einen Host, einen Cluster-Port (Peer) und einen Client-Port. Unter Kubernetes wird diese Roster stattdessen aus den StatefulSet-Pod-Ordinalzahlen synthetisiert, statt von Hand gepflegt zu werden; die Preferred-Primary-Rolle eines Nodes wird direkt aus seiner Ordinalzahl abgeleitet.

Es gibt einen Gossip-Mechanismus in Zaris, aber er erfüllt eine andere Aufgabe — er hält die Sicht der Nodes auf den Cluster-Zustand konvergent, er dient nicht dazu, die Existenz von Peers zu entdecken. Darauf kommen wir bei der Readiness zurück.

Wem gehört was: die Partition-Map​

Sobald die Mitgliedschaft bekannt ist, braucht der Cluster einen Plan für den Keyspace. Dieser Plan ist die Partition-Map — ein einziges, versioniertes Dokument, nach dem jeder Node routet.

Von einem Key zu einem Owner, in zwei Schritten​

Ein Key wird nicht direkt einer Partition zugeordnet. Zaris verwendet eine zweistufige Zuordnung, die bewusst Byte für Byte an Redis Cluster ausgerichtet ist, sodass dieselbe Routing-Mathematik für native Clients und das RESP-Front-End funktioniert:

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

Der erste Schritt hasht den Key mit CRC16 (CCITT/XMODEM, Polynom 0x1021) modulo 16384 — exakt die Funktion, die Redis Cluster verwendet, einschließlich der Berücksichtigung der Hash-Tag-Co-Location: Ein Key wie user:{42}:profile hasht nur den Teil innerhalb der geschweiften Klammern, sodass zusammengehörige Keys beieinander landen. Die 16384 Slots werden dann proportional auf die Segmente des Clusters abgebildet — standardmäßig 256, für die Lebensdauer des Clusters fest — und eine SegmentToPartition-Tabelle weist jedes Segment einer Partition zu. Die Partition schließlich ist das, was Owner hat.

Warum die zusätzliche Segmentschicht, statt direkt auf Partitionen zu hashen? Weil Segmente eine stabile, feingranulare Einheit sind, die Sie zwischen Partitionen verschieben können, wenn der Cluster wächst oder neu balanciert wird, ohne jeden Key neu zu hashen. Der Schritt von CRC16 zum Slot ändert sich nie; nur die Zuordnung von Segment zu Partition ändert sich.

Was eine Partition-Map enthält​

Die Map selbst ist eine PartitionMap — ein MessagePack-serialisierter Record, dessen Struktur zeigt, wie sorgfältig das Ownership nachverfolgt wird. Die wissenswerten Felder:

• Version — ein monotoner Zähler, der bei jeder Map-Änderung hochzählt. Das ist die Zahl, die den Commit sicher macht (mehr dazu unten).
• TopologyVersion — zählt nur bei einer echten strukturellen Änderung hoch (ein Node oder eine Partition kommt hinzu oder geht, ein Re-Tile), nicht bei einem routinemäßigen Migrations-Cut-over. Die Trennung von „die Form hat sich geändert" und „ein Owner hat sich geändert" erlaubt dem Rest des Systems, verhältnismäßig zu reagieren.
• TotalSegments — standardmäßig 256, für die Lebensdauer des Clusters konstant.
• Partitions — die Liste der Zuweisungen, jeweils mit einer PrimaryNodeId (der Platzierungs-Primary), ReplicaNodeIds und einer stabilen PartitionIdentity (einer bei der Entstehung erzeugten GUID, die eine Umnummerierung überdauert) sowie Ownership-Lease-Feldern: ActiveOwnerNodeId, einer vom Leader erzeugten OwnershipGeneration und dem LeaderTerm, der die Lease erteilt hat — wodurch der Cluster einen veralteten Ex-Leader daran hindern kann, Ownership zu verfassen.

Beachten Sie die bewusste Trennung zwischen PrimaryNodeId (wo die Map eine Partition bevorzugt ansiedelt) und ActiveOwnerNodeId (wer sie tatsächlich gerade bedient). Beide können sich während eines Failovers oder einer Migration unterscheiden, und die Trennung in separate Felder macht diese Übergänge darstellbar, ohne den Plan für den Normalbetrieb zu verfälschen. Der Beitrag zum Konsistenzmodell erklärt, warum Lesezugriffe zu diesem einen aktiven Owner geroutet werden.

Wie die Map geplant wird​

Die Map wird nicht gierig zusammengesetzt. Sie wird von einem reinen, deterministischen Planer erzeugt — DesiredMapPlanner —, der die Node-IDs der Mitglieder, die Segmentanzahl, eine gewünschte Partitionsanzahl und den Replikationsfaktor entgegennimmt und einen Plan zurückgibt. Zwei Eigenschaften sind erwähnenswert:

1. Ausgewogene, zusammenhängende Segmentaufteilung. Segmente werden so gleichmäßig wie möglich in zusammenhängenden Abschnitten verteilt; die ersten Partitionen nehmen den Rest auf, wenn die Teilung nicht glatt aufgeht.
2. Platzierung in disjunkten Gruppen. Die ersten N Mitglieder werden die verschiedenen Partition-Primaries; die übrigen Mitglieder füllen die Replica-Slots reihum, sodass kein Node in zwei verschiedenen Partitionsgruppen landet.

Der Grund, warum der Planer als reine Funktion der Eingaben geschrieben ist, ist ein hart erkämpfter: Dadurch ist eine ganze Klasse fehlerhafter Maps — eine Partition mit doppeltem Primary, ein nicht zusammenhängender Segmentbereich, eine degenerierte Zuweisung — per Konstruktion nicht darstellbar, statt dass man sie nachträglich mit einem Validator abfängt. Ehrlicherweise sollte auch die aktuelle Einschränkung genannt werden: Die Platzierung ist heute positionsbasiert und folgt disjunkten Gruppen; eine Churn-minimierende, Rendezvous-artige Platzierung, die bei jeder Neuberechnung möglichst wenige Daten verschiebt, ist eine ausdrückliche künftige Verfeinerung, nicht etwas, das ausgeliefert ist. Ausgeliefert ist ein Sticky-Placement-Schritt, der bei einer Neuberechnung durch Mitgliedschafts-Churn einen live bedienenden Owner an Ort und Stelle belässt, sodass eine gesunde Partition nicht ohne Grund verschoben wird.

Was „Commit" bedeutet​

Die Map wird von einem Node — dem Leader der Steuerungsebene — und niemandem sonst verfasst. Der Leader erzeugt eine Kandidaten-Map, schickt sie durch eine Projektion des Ownership-Logs (der Leader ist der einzige Schreiber des Ownership-Logs, und die bediente Map ist eine Faltung dieses Logs) und committet sie dann lokal, bevor er jemandem davon erzählt. Der Commit folgt einer einzigen, strikten Regel, die in TopologyManager.ApplyMap durchgesetzt wird:

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

Eine Map mit einer Version kleiner oder gleich der bereits gehaltenen wird abgelehnt, Punkt. Erst nachdem der Leader committet hat, sendet er ein MapChangedEvent, schickt direkte Map-Snapshots an Peers und veröffentlicht die Routing-Änderung an Clients. Follower holen die Map ab (beim Kaltstart fordern sie sie von bereits bekannten Peers an und versuchen es erneut, bis einer antwortet) und wenden sie über dieselbe monotone Prüfung an. Da jeder Node nur strikt höhere Versionen akzeptiert, können sich zwei Nodes nie auf widersprüchliche Maps derselben Version einigen — die Versionsnummer ist der Serialisierungspunkt.

Eine ehrliche Besonderheit beim Kaltstart: Ein führerloser Node, der allein hochfährt, kann eine einzelne provisorische Ein-Node-Map erzeugen, damit er nicht handlungsunfähig ist; sie ist als provisorisch markiert und wird später durch die maßgebliche Multi-Node-Map ersetzt, sobald sich der Cluster gebildet hat. Das ist ein Verfügbarkeitsmittel, nicht der Pfad im Normalbetrieb.

Ist es sicher zu bedienen: durch Konvergenz gesteuerte Readiness​

Hier ist der Schritt, der einen vertrauenswürdigen Store von einem unterscheidet, der lediglich startet. Dass ein Prozess läuft und sogar eine Map vorliegt, heißt nicht, dass ein Node Traffic annehmen sollte. Beginnt ein Node zu bedienen, bevor sein Laufzeit-Ownership zu der Map aufgeschlossen hat, die er gerade angewendet hat, kann er eine Anfrage an eine Partition routen, die er noch gar nicht hält. Zaris weigert sich, das zu tun, und zwar mit zwei unterschiedlichen Gates.

Gate eins: Stabilität der Cluster-Bildung​

Das erste Gate entscheidet, wann der Leader die erste echte Map erzeugen darf. ClusterReadinessGate wartet, bis die Mitgliedschaft stabil ist — mindestens eine Mindestanzahl von Nodes ist durchgehend für ein Stabilitätsfenster anwesend (standardmäßig 3 Sekunden) —, bevor eine Map committet wird. Das verhindert, dass der Leader eine Map gegen einen halb gebildeten Cluster verfasst, in dem Nodes noch einer nach dem anderen beitreten, was eine sofortige Neuberechnung eine Sekunde später bedeuten würde. Wird die Stabilität nicht innerhalb des Timeouts erreicht (standardmäßig 30 Sekunden), führt das Gate trotzdem einen erzwungenen Bootstrap durch: Verfügbarkeit schlägt endloses Warten. Der Cluster fährt lieber etwas zu früh hoch, als hängen zu bleiben.

Gate zwei: das Traffic-Gate pro Node​

Das zweite Gate entscheidet tatsächlich, ob ein Node seinen Client-Listener öffnet. ClusterTrafficReadinessGate.IsReady() liefert nur dann true, wenn alle der folgenden Bedingungen erfüllt sind:

• eine committete Map existiert,
• ihre Segment-zu-Partition-Tabelle ist vollständig befüllt (length == TotalSegments),
• eine Laufzeit-Ownership-Map existiert,
• runtime.MapVersion == map.Version — das Laufzeit-Ownership des Nodes stimmt mit der exakten Version der von ihm committeten Map überein,
• und jede Partition hat einen Laufzeiteintrag.

Die vierte Bedingung ist der Kern. Ein Node meldet sich nicht als bereit zum Bedienen, bevor seine eigene committete Map und sein eigenes Laufzeit-Ownership dieselbe Version haben. Darauf zeigt das Titelbild oben. Es gibt einen 60-Sekunden-Backstop, damit ein Node, der nicht konvergieren kann, den Start nicht ewig blockiert — danach fährt er mit einer Warnung fort, statt zu hängen —, aber im Normalfall hält das Gate die Tür geschlossen, bis beide Ebenen übereinstimmen.

Konvergent bleiben: Digests und Detect-and-Heal​

Readiness ist eine Eigenschaft der Startphase; konvergent zu bleiben ist eine des Normalbetriebs, und hier zahlt sich Zaris' Gossip tatsächlich aus. Jeder Heartbeat trägt einen kleinen ClusterStateDigest — die Epoche des Nodes, wen er für den Leader hält, seine Map-Version, seine Node-Anzahl und die Ownership-Generationen pro Partition. Keine zusätzlichen RPCs; er reist auf Traffic mit, den der Cluster ohnehin sendet.

Ein DigestAccumulator sammelt die Digests der Peers und vergleicht sie alle paar Sekunden. Weicht ein Node in zwei aufeinanderfolgenden Auswertungszyklen von der Mehrheit ab, löst er ein Drift-Signal aus, und ein HealingOrchestrator reagiert darauf — der Leader sendet korrigierende Direktiven (mit einer Abklingzeit, damit er nicht flattert), und ein Node, der sich als einsamer Ausreißer findet, heilt sich selbst durch erneutes Abholen. Das ist Konvergenz durch Erkennen und Reparieren, nicht durch eine Quorum-Abstimmung vor dem Bedienen.

Diese Unterscheidung ist für die Ehrlichkeit wichtig, daher möchte ich präzise sein. In Produktion wird die Übereinstimmung der Map-Version im gesamten Cluster durch das Traffic-Gate pro Node plus diese Digest-getriebene Heilungsschleife aufrechterhalten — nicht durch eine globale Barriere, die jedes Bedienen blockiert, bis jeder Node über eine Version abgestimmt hat. Die stärkere Aussage — jeder Node-Snapshot stimmt in einem Leader, einer Leader-Epoche und einer Map-Version überein — ist das, was das 12-Stunden-Chaos-Zertifizierungs-Harness fortlaufend als Pass/Fail-Invariante prüft. Die Zertifizierung belegt, dass die Eigenschaft gilt; die Laufzeit erreicht sie durch Gating und Heilung statt durch eine blockierende Konsensrunde auf dem Serve-Pfad.

Replikationsfaktor und ein ehrlicher Default​

Ein letztes Stück der Cluster-Bildung, denn es verändert, was „bereit" für Ihre Dauerhaftigkeit bedeutet. Der Replikationsfaktor ist standardmäßig 1. Mit RF=1 hat jede Partition einen Primary und keine Replica — eine einzige Kopie. Der Planer platziert RF - 1 Replicas pro Partition, im Default also null. Ein Cluster mit RF=1 bildet sich, konvergiert und bedient einwandfrei, aber der Verlust eines Nodes ist ein Datenverlust für die Partitionen, die er besaß — by Design, nicht zufällig. Wenn Sie möchten, dass eine Partition einen Node-Ausfall überlebt, setzen Sie RF >= 2 und benötigen genug Nodes, um diese Replicas tatsächlich auf verschiedenen Maschinen zu platzieren — der Beitrag zur Dimensionierung der Dauerhaftigkeit unter Kubernetes rechnet genau durch, wie viele Pods das erfordert. Die Partitionsanzahl hat einen ähnlich ehrlichen Default: Ist sie nicht gesetzt, verwendet der Cluster eine Partition pro Node.

Die Sequenz im Ganzen​

Zusammengenommen fährt ein Zaris-Cluster so hoch:

1. Die Mitgliedschaft wird aufgelöst aus der Konfigurations-Roster (oder den k8s-Ordinalzahlen), und Nodus wählt einen Leader der Steuerungsebene.
2. Der Leader wartet hinter dem Formations-Gate auf stabile Mitgliedschaft, plant dann eine Map mit DesiredMapPlanner und committet sie lokal unter der strikten Prüfung auf monotone Versionen.
3. Der Leader sendet die Map per Broadcast; Follower holen sie ab und wenden sie unter derselben Prüfung an, wobei sie nur strikt höhere Versionen akzeptieren.
4. Jeder Node wartet hinter seinem Traffic-Gate, bis runtime.MapVersion == map.Version gilt und das Routing vollständig befüllt ist — erst dann öffnet er seinen Client-Listener.
5. Im Normalbetrieb halten Heartbeat-gebundene Digests die Sicht jedes Nodes konvergent, wobei Drift-Erkennung und Leader-getriebene Heilung jede Lücke schließen.

Keiner dieser Schritte ist für sich genommen dramatisch. Zusammen machen sie den Unterschied zwischen einem Cluster, der läuft, und einem, der bereit ist — und in der Lücke zwischen diesen beiden Worten verliert ein Store stillschweigend Daten, wenn er die Frage nicht ernst nimmt.

Zaris ist der verteilte Key/Value-Store von Clustron. Wenn Sie die Steuerungsebene aus Sicht des Operators sehen möchten, erstellt, startet und inspiziert die PowerShell-Anleitung live einen Cluster; und Elastic Scaling behandelt, was mit der Map passiert, wenn Sie einem bereits bedienenden Cluster einen Server hinzufügen.

Früher oder später stellt jemand die Frage: Wir haben einen Cluster in einer Region und Nutzer in einer anderen — können wir nicht einfach dort ein paar Nodes hinzufügen und einen Cluster beide Regionen umspannen lassen? Das ist ein nachvollziehbarer Instinkt. Ein Cluster, ein Namespace, ein Connection-String, Daten überall. Der Instinkt ist aber auch eine Falle, und es lohnt sich, genau zu erklären, warum.

Ein Zaris-Cluster ist für ein Datacenter-Netzwerk konstruiert. Die Mitgliedschaft wird mit Heartbeats auf kurzen Timern verfolgt. Das Ownership einer Partition wechselt zwischen Nodes über einen Handshake, der voraussetzt, dass die Gegenseite schnell antwortet. Das Failover fenced einen vermutlich toten Owner und befördert eine Replica im Sekundenbereich. Jeder dieser Mechanismen ist für eine Verbindung kalibriert, bei der die Round-Trip-Zeit in Mikrosekunden gemessen wird und ein „langsamer" Node tatsächlich krank ist — nicht bloß achtzig Millisekunden und einen Ozean entfernt. Setzt man die Hälfte der Nodes über ein WAN, hat man keinen georedundanten Cluster gebaut, sondern einen Cluster, der normale WAN-Latenz nun für einen Ausfall hält, das Ownership flattern lässt und beim ersten Aussetzer der Verbindung zwischen den Regionen ein Split-Brain riskiert.

Die richtige Form ist also nicht ein gestreckter Cluster. Es sind zwei unabhängige Cluster — jeder in sich geschlossen, mit eigenem Ownership und Failover, das vollständig im eigenen LAN bleibt —, verbunden durch einen asynchronen, wiederaufnehmbaren Change Feed. Dieser Beitrag handelt von diesem Muster: warum Unabhängigkeit die tragende Entscheidung ist und wie das Operation-Log von Zaris Ihnen bereits das Eine liefert, was ein WAN-Replikator tatsächlich braucht — einen Cursor, von dem aus Sie fortsetzen können.

Warum ein gestreckter Cluster das falsche Werkzeug ist​

Es hilft, die konkreten Annahmen zu benennen, die ein einzelner Cluster trifft, denn jede zerbricht über ein WAN auf andere Weise.

• Heartbeat-basierte Mitgliedschaft entscheidet, dass ein Node verschwunden ist, wenn er einige Beats verpasst. Eine Verbindung zwischen Regionen, die Latenz hinzufügt und gelegentlich partitioniert, wird diesen Detektor im gesunden Betrieb auslösen. Der Cluster wird lebende Nodes für tot erklären.
• Das Ownership-Protokoll verschiebt Partitionen zwischen Nodes mit einem Handshake, der eine prompte Antwort erwartet. Über ein WAN stocken, wiederholen und konkurrieren diese Übergänge — genau der Churn, den die Ownership- und Cut-over-Mechanik in einem LAN schnell auflösen soll.
• Failover-Timer befördern eine Replica, wenn der Owner tot aussieht. Über ein WAN sind „sieht tot aus" und „ist nur weit weg" nicht mehr unterscheidbar, sodass es zu unnötigen Promotions kommt — und wenn die Verbindung heilt und auf jeder Seite eine beförderte Replica sitzt, haben Sie zwei Owner für eine Partition.

Nichts davon ist ein Defekt. Es ist ein Store, der genau das tut, was ein Store mit niedriger Latenz im Datacenter tun sollte, angewendet auf ein Netzwerk, das er nie überspannen sollte. Die Lösung ist nicht, jeden Timer so weit zu lockern, bis der Cluster ein WAN toleriert — das würde ihn auch echte Ausfälle viel zu langsam tolerieren lassen. Die Lösung ist, nicht länger von einem Cluster zu verlangen, es zu tun.

Der Baustein, den Sie bereits haben: ein wiederholbares Log​

Zaris führt pro Segment ein nach Revision geordnetes Operation-Log. Jeder akzeptierte Schreibvorgang erhöht eine monotone Revision und hängt einen Eintrag an. Dieses Log ist das Substrat, mit dem Replicas und neue Partition-Owner aufholen, ohne Schreibzugriffe einzufrieren: Ein Consumer, der die zuletzt gesehene Revision kennt, kann ab diesem Punkt vorwärts abspielen und zur aktuellen Wahrheit konvergieren.

Diese Eigenschaft — ab einer bekannten Revision vorwärts abspielen — ist das gesamte Fundament eines WAN-Replikators. Ein Change Feed ist nichts weiter als ein langlebiger Leser dieses Logs, der Einträge in Revisionsreihenfolge streamt und sich merkt, wo er aufgehört hat. Das, was er sich merkt, ist ein Cursor: die höchste Revision, die er dauerhaft angewendet hat, pro Segment.

Weil das Log nach Revision geordnet ist und das Abspielen an einem von Ihnen gewählten Punkt beginnt, hat der Feed die beiden Eigenschaften, die eine WAN-Verbindung verlangt:

1. Wiederaufnehmbar. Die Verbindung wird abbrechen — das ist die definierende Tatsache eines WAN. Kommt sie zurück, verbindet sich der Follower neu und fragt nach allem nach seinem gespeicherten Cursor. Keine vollständige Neukopie, keine Koordination, einfach „bei Revision N fortsetzen".
2. Idempotent beim Abspielen. Einen Eintrag nur anwenden, wenn seine Revision größer ist als die zuletzt für dieses Segment angewendete. Liefert ein Reconnect das Ende erneut aus, überspringt der Follower, was er schon hat. Doppelte Zustellung wird zum No-op, wodurch der Feed At-least-once sein darf, statt Exactly-once sein zu müssen.

Das Muster, von Anfang bis Ende​

Zwei Cluster. Nennen wir sie A (die Quelle) und B (der Follower). Jeder ist ein gewöhnlicher, unabhängiger Zaris-Cluster, der nichts von den Interna des anderen weiß.

In Cluster B betreiben Sie einen Replikations-Follower — einen Client, der den Change Feed von A konsumiert und die Operationen lokal in B schreibt. Sein Zustand ist winzig und dauerhaft: ein Cursor pro Segment. Die Schleife ist unspektakulär, und das ist der Punkt:

1. Mit A verbinden, den Change Feed für die zu replizierenden Segmente (oder Key-Präfixe) anfordern, beginnend nach dem gespeicherten Cursor jedes Segments.
2. Einträge in Revisionsreihenfolge empfangen. Jede Operation auf B anwenden — SET, DELETE, Expiry —, abgesichert durch die Revisionsprüfung, sodass eine erneute Zustellung harmlos ist.
3. Den Cursor voranschreiten lassen und persistieren, sobald Einträge dauerhaft angewendet sind.
4. Bei jeder Trennung zurück zu Schritt 1. Der Cursor ist, wo Sie aufgehört haben.

Alles, was der Follower braucht, um eine Unterbrechung zu überstehen, steckt in diesem Cursor. Es gibt keine verteilte Transaktion über das WAN, keine gemeinsame Mitgliedschaft, kein regionsübergreifendes Quorum. Ein Aussetzer der Verbindung kostet nichts außer etwas Aktualität.

Was Sie eintauschen: RPO ist nicht null, und das ist der Deal​

Diese Replikation ist asynchron. Der Follower hinkt der Quelle immer etwas hinterher — um so viele Revisionen, wie in A erzeugt, aber in B noch nicht angewendet wurden. Dieser Abstand ist Ihr Recovery Point Objective: Verschwindet Region A in diesem Augenblick, verlieren Sie, was B noch nicht erreicht hatte.

Das ist kein Fehler, für den man sich entschuldigen müsste; es ist der Kompromiss, den Sie ausdrücklich wählen. Die Alternative — Schreibzugriffe in A auf eine Bestätigung von B warten zu lassen, bevor sie committen — würde einen WAN-Round-Trip auf Ihren Schreibpfad legen und die niedrige Latenz opfern, die der ganze Grund ist, Zaris zu betreiben. Synchrone regionsübergreifende Replikation macht jeden Schreibvorgang zu einer transkontinentalen Anfrage. Das will fast niemand, sobald er die Latenzrechnung sieht.

Die ehrliche Formulierung lautet also: Sie wählen den RPO. Ein gut versorgter Follower auf einer gesunden Verbindung bleibt innerhalb weniger Revisionen — in der Praxis Staleness unter einer Sekunde. Eine gesättigte oder flatternde Verbindung lässt ihn weiter abdriften. Der Cursor macht die Drift begrenzt und sichtbar — Sie können genau messen, wie weit B zurückliegt, indem Sie seinen Cursor mit der aktuellen Revision von A vergleichen —, aber er macht sie nicht null. Dimensionieren Sie Ihre Toleranz entsprechend und alarmieren Sie bei Cursor-Lag, so wie Sie bei Replica-Lag innerhalb eines Clusters alarmieren würden.

Wenn die Quelle ein Failover durchführt, ist es dem Feed egal​

Hier zahlt sich der Aufbau auf dem Operation-Log ein zweites Mal aus. Innerhalb von Cluster A wird die Partition, die Ihr Feed liest, gelegentlich den Owner wechseln — ein Node stirbt, eine Replica wird befördert, eine Partition migriert. Das Log überlebt das: Es ist nach Revision geschlüsselt, und ein neuer Owner setzt dieselbe Revisionssequenz fort. Für den Follower ist ein Failover auf der Quellseite nur ein weiterer Reconnect. Er baut den Feed gegen die aktuelle Topologie von A neu auf und setzt bei seinem Cursor fort. Die Revisionen, die er schon angewendet hat, sind weiterhin die Revisionen, die er schon angewendet hat; die, die ihm fehlen, liegen weiterhin hinter dem Cursor. Der Follower muss nie verstehen, wer in A die Partition besitzt — nur, welche Revision er zuletzt gesehen hat.

Das ist der stille Grund, warum das Design mit Cursor über dem Log mehr wert ist als ein naives Relay, das „die Schreibzugriffe mitliest und weiterschickt". Ein Relay, das Live-Schreibzugriffe ohne dauerhafte, nach Revision geschlüsselte Position streamt, hat nichts, womit es fortsetzen könnte, wenn sich die Quelltopologie verschiebt. Das Log gibt dem Follower ein stabiles Koordinatensystem, das jeden einzelnen Owner überdauert.

Der Umfang ist eine Wahl, und Konflikte sind eine Grenze​

Zwei weitere Dinge sollten bewusst entschieden werden.

Datenumfang. Sie müssen nicht alles replizieren. Der Feed arbeitet pro Segment, und Sie können die Segmente oder Key-Präfixe auswählen, auf die es ankommt — einen bestimmten Tenant, einen bestimmten Datensatz, den Ausschnitt, den eine Disaster-Recovery-Region wirklich braucht. Weniger zu replizieren bedeutet weniger WAN-Traffic und einen kleineren Follower; alles zu replizieren ergibt ein vollständiges Warm-Standby. Entscheiden Sie bewusst statt per Default.

Richtung und Konflikte. Das obige Muster ist unidirektional: A ist die Quelle der Wahrheit, B ist ein überwiegend lesender Follower / Standby. Das ist der saubere Fall, und er hat kein Konfliktproblem — es gibt genau einen Schreiber pro Key. In dem Moment, in dem Sie es bidirektional machen — beide Regionen akzeptieren Schreibzugriffe auf dieselben Keys —, haben Sie nebenläufige Schreiber eingeführt, die durch ein WAN getrennt sind, und keine Menge an Change-Feed-Plumbing löst das für Sie. Nun schulden Sie eine Konfliktauflösungsrichtlinie: Last-Writer-Wins auf einer Uhr, der Sie vertrauen, Ownership pro Key, sodass die beiden Regionen nie denselben Key schreiben, oder eine Merge-Logik in der Anwendung. Active-Active ist ein reales und manchmal notwendiges Design, aber es ist eine Datenmodellierungs-Entscheidung, kein Transport-Feature. Greifen Sie zuerst zum unidirektionalen Modell; setzen Sie bidirektional nur ein, wenn Sie ausdrücklich entschieden haben, wie zwei Schreiber abgeglichen werden.

Die Form zum Merken​

Ein WAN ist kein langsames LAN; es ist ein anderes Medium, in dem Partitionen ein normales Ereignis sind und kein Notfall. Ein einzelner Cluster weigert sich korrekterweise, etwas anderes vorzutäuschen — seine Timer und sein Ownership-Protokoll sind darauf abgestimmt, eine lange Stille als Ausfall zu werten, weil sie das innerhalb eines Datacenters fast immer ist. Also strecken Sie den Cluster nicht. Sie betreiben zwei, jeder souverän in seinem eigenen Netzwerk, und verbinden sie mit dem einen Primitiv, das darauf ausgelegt ist, eine Verbindung zu tolerieren, die kommt und geht: ein nach Revision geordnetes Log, das Sie abspielen können, und ein Cursor, der sich merkt, wo Sie waren.

Unabhängigkeit ist die Entscheidung, die den Rest sicher macht. Der Change Feed ist nur das Rohr. Das Operation-Log hat Ihnen den Cursor bereits geliefert.

Hier ist eine Zahl, die verändert, wie man über einen Key/Value-Store denkt. Wenn wir den In-Memory-Store von Zaris isolieren und ihm Operationen zuführen, ohne dass etwas anderes im Weg ist — kein Socket, keine Serialisierung, kein Routing —, bedient ein einzelner Thread mehr als eine Million Lesezugriffe pro Sekunde und skaliert sauber auf mehr als acht Millionen über acht Threads. Der Store erledigt die eigentliche Arbeit eines GET also in unter zwei Mikrosekunden und ist ausdrücklich nicht der Engpass.

Und doch erreicht ein vollständiges GET über eine echte TCP-Verbindung auf derselben Maschine ein Plateau bei einigen Hunderttausend pro Sekunde. Der Store kann die Arbeit fünfmal schneller erledigen, als der Server sie liefern kann. Die interessante Performance-Frage zu Zaris lautet also nicht „Wie schnell ist der Store?" Sondern genau umgekehrt: Wohin geht die ganze Zeit zwischen Socket und Store? Dieser Beitrag ist die Antwort, Operation für Operation nachverfolgt, denn die Lücke zwischen 1,7 Mikrosekunden Logik und 10 bis 13 Mikrosekunden Server-CPU pro Operation ist kein Rauschen — sie ist der Latenzboden, und fast alles davon ist Installation.

Die Messung, mit der die gesamte Untersuchung beginnt​

Man kann einen Pfad nicht optimieren, den man nicht in Schichten getrennt hat. Deshalb haben wir als Erstes eine Reihe von Ablations-Benchmarks gebaut — Harnesses, die das System jeweils auf eine einzige Schicht reduzieren.

• Nur Store. Den In-Process-Store der Partition direkt aufrufen, im selben Prozess, ohne Netzwerk. Ergebnis: ~1,15 Mio. GET/s und ~0,5 Mio. PUT/s pro Thread, linear skalierend auf ~8,2 Mio. / ~2,0 Mio. bei acht Threads.
• Reines Socket-Echo. Ein einfacher .NET-Socket, der Frames derselben Form verarbeitet, ohne Zaris-Logik: ~7,2 Mio. Frames/s auf derselben Maschine.
• Vollständiger nativer TCP-Pfad. Der echte Client spricht mit dem echten Server: ~300–324K Ops/s, wobei auf jeder Seite nur etwa drei von vierzehn logischen Kernen ausgelastet sind.

Betrachtet man diese drei zusammen, fallen sofort zwei übliche Verdächtige weg. Der Store ist nicht die Grenze — er ist 3- bis 4-mal schneller als der vollständige Pfad. Das Betriebssystem und das Loopback sind es auch nicht — ein reiner Socket bewegt Frames zwanzigmal schneller. Was in der Mitte bleibt, zwischen einem Socket, der Millionen schafft, und einem Store, der Millionen schafft, ist die eigene Request-Installation von Zaris, und sie verbrennt etwa 10–13 Mikrosekunden Server-CPU pro Operation, um rund 1,7 Mikrosekunden echter Arbeit zu umhüllen.

Dieses Verhältnis ist das Thema. Folgen wir einem GET durch sie hindurch.

Der Weg eines einzelnen GET​

Nichts in diesem Diagramm ist auf den ersten Blick falsch oder verschwenderisch — es ist die ehrliche Form eines vernetzten Stores. Die Kosten stecken in den Details jedes Pfeils: wie oft ein Thread aufwachen muss, wie oft die Bytes kopiert werden und wie viel feste Arbeit pro Request mitläuft, die nichts mit dem gelesenen Key zu tun hat. In diesen Details leben die elf Mikrosekunden, und sie gruppieren sich in drei Bereiche.

Engpass eins: die Egress-Hop-Kette​

Die größten Einzelkosten entstehen nicht beim Lesen des Wertes — sondern bei seiner Auslieferung. Das Zurücksenden einer einzigen Antwort an den Client durchquert in der aktuellen Struktur drei interne Channels, weckt drei Threads und kopiert die Payload viermal auf ihrem Weg nach draußen:

1. Die Antwort wird vom Shard-Worker an den Sendepfad der Server-Pipeline übergeben.
2. Der Sendepfad übergibt sie an eine Schreibschleife pro Verbindung, die sie in einen gepoolten Buffer kodiert.
3. Die Schreibschleife stellt sie in die Sendewarteschlange der Transportverbindung.
4. Der Transport führt die eingereihten Buffer zu einem Stream zusammen und schreibt auf den Socket.

Jede Übergabe ist ein Thread-Wake-up, und jedes Wake-up ist ein Scheduling-Ereignis, das das Betriebssystem bedienen muss — einzeln billig, bei Hunderttausenden pro Sekunde verheerend. Und in jeder Stufe werden die Bytes erneut kopiert: gepoolter Encode-Buffer, Sendewarteschlange, Coalescing-Buffer, Socket. Auf der eingehenden Seite gibt es entsprechende Kosten: Jeder Request, der auf einem IOCP-Completion-Thread ankommt, wird an einen Shard-Worker übergeben, bevor irgendeine Arbeit stattfindet — ein weiteres Wake-up und eine weitere Warteschlange.

Der Grund für diese Struktur ist vernünftig — die Entkopplung von Empfang, Dispatch, Encoding und Übertragung macht jede Schicht einfacher nachvollziehbar und lässt langsame Consumer Backpressure ausüben, ohne den Socket zu blockieren. Aber für den Normalfall — einen RF1-Lesezugriff, dessen Antwort bereits im Speicher des Nodes liegt, der den Request empfangen hat — ist das enorm mehr Maschinerie, als die Arbeit verdient. Die Antwort könnte im Prinzip auf dem Empfangspfad selbst berechnet und zurückgeschrieben werden, mit einer Kopie in den Socket-Buffer und ohne jegliche Übergaben.

Das ist das erste und größte Stück struktureller Arbeit, auf das die Messung hinweist: den Egress auf einen Hop und eine Kopie zusammenfassen für den Hot Path und den RF1-Lese-/Schreibzugriff inline auf dem empfangenden Thread ausführen, statt ihn über den Worker-Pool springen zu lassen. Das ist der Unterschied zwischen einem Design, das leicht zu zeichnen ist, und einem Design, das billig zu betreiben ist, und beides ist nicht dasselbe.

Engpass zwei: redundantes Hashing und ein Lock pro Request​

Die zweite Gruppe ist fester Overhead pro Operation — Arbeit, die bei jedem Request anfällt, unabhängig vom berührten Key, und die größtenteils nicht anfallen sollte.

CRC16, dreimal, Bit für Bit. Zaris routet Keys mit einem CRC16-Hash zu Partitionen — derselben Hash-Familie, die Redis Cluster verwendet, so bleibt das RESP-Front-End Slot-kompatibel. Das Problem ist nicht die Wahl des Hashs; es ist, dass die Implementierung bitseriell ist (sie läuft Bit für Bit, statt eine Lookup-Tabelle zu nutzen) und dass ein einzelnes GET sie beim Durchlaufen des Routings dreimal berechnet. Bei rund 260 Nanosekunden pro Berechnung sind das ~784 ns pro GET fürs Hashing — mehr als der gesamte MessagePack-Decode-plus-Encode-Roundtrip, der bei etwa 533 ns liegt. Ein tabellengetriebenes CRC16, einmal berechnet und mitgeführt, würde die größte feste Einzelposition zu einem Rundungsfehler machen.

Eine Lizenzprüfung, die bei jedem Request einen Lock nimmt. Überraschender noch: Der Einstiegspunkt der Requests befragt bei jeder einzelnen Operation den Lizenzdienst, und diese Abfrage nimmt einen prozessweiten Lock und liest die Wanduhr (DateTime.UtcNow), um zu entscheiden, ob die aktuelle Lease noch gültig ist. Ein Lock auf dem Hot Path ist genau die Art von Ding, die in einem Single-Thread-Mikrobenchmark nicht auftaucht und dann unter Nebenläufigkeit stillschweigend alles serialisiert. Das Lizenzurteil ändert sich höchstens ein paar Mal während der Lebensdauer eines Prozesses — wenn eine Lease erteilt, erneuert oder abläuft. Es hat nichts damit zu tun, bei jedem GET unter einem Lock neu berechnet zu werden. Die Lösung ist, das Urteil in einem einzelnen volatile-Feld zu veröffentlichen, das eine Hintergrunderneuerung aktualisiert, und den Hot Path es ohne Lock und ohne Uhr-Aufruf lesen zu lassen. (Die Lease-Mechanik selbst ist Thema des Beitrags zum Lizenz-Lebenszyklus; hier geht es nur darum, dass das Lesen des Urteils kostenlos sein muss.)

Beides ist kein tiefes algorithmisches Problem. Es sind Kosten, wie sie entstehen, wenn jedes Stück für sich korrekt geschrieben wurde und noch niemand gemessen hat, was die Summe auf dem Pfad kostet, der eine Million Mal pro Sekunde läuft.

Engpass drei: Der Client verbraucht so viel wie der Server​

Es wäre bequem, dem Server an allem die Schuld zu geben, aber die Ablation sagt etwas anderes: Lokale Benchmarks sind client-limitiert, und allein das Festnageln des Clients auf Performance-Kerne hob ihn von 169K auf 299K Ops/s. Der Client verbraucht etwa 9 Mikrosekunden und 1,8 KB pro GET, und die Kosten ähneln denen des Servers:

• Completions springen durch den Thread-Pool. Jeder ausstehende Request wird von einer TaskCompletionSource verfolgt, die so konfiguriert ist, dass ihre Fortsetzung asynchron läuft; wenn die Antwort eintrifft, wird die Completion also in den Thread-Pool gepostet, statt inline fortgesetzt zu werden — ein weiterer Scheduling-Hop bei jeder Operation.
• Bei jeder einzelnen Operation wird eine Umgebungsvariable gelesen. Der Client ruft Environment.GetEnvironmentVariable("ZARIS_REQUEST_TIMEOUT") pro Request auf, um seine Deadline zu bestimmen. Das Lesen einer Umgebungsvariable durchläuft den Umgebungsblock des Prozesses; eine Million Mal pro Sekunde ist das der größte von Zaris verfasste Frame auf dem Client. Sie sollte einmal beim Start gelesen und gecacht werden.
• Ein Semaphor und ein Channel-Lock pro Operation, dazu Allokationen pro Request — eine Client-ID, die jedem Request aufgestempelt wird, Eintragsmetadaten, die angefordert und zurückgegeben werden, auch wenn der Aufrufer sie nicht verlangt hat.

Der rote Faden ist derselbe wie beim Server: Die Arbeit eines GET ist winzig und von Scheduling-Hops, Locks und Allokationen umgeben, die jeweils für sich kostenlos aussahen. Der Hot Path des Clients ist bereits auf dem richtigen Weg — der Wechsel zu ValueTask für die Kernoperationen hat eine Allokation pro Aufruf bei synchronem Abschluss beseitigt —, und der Rest der Liste ist dieselbe Idee weitergeführt: die Umgebungsvariable cachen, ohne Thread-Pool-Sprung abschließen, auf dem Socket mit einem ValueTask empfangen und aufhören, Dinge zu allokieren, die niemand verlangt hat.

Was ist der Boden also wirklich?​

Rechnet man alles zusammen, ergibt sich folgendes ehrliche Bild. Auf einem Laptop erreicht der native TCP-Pfad bei etwa 300K Ops/s seine Obergrenze, nicht weil der Store langsam wäre — er schafft Millionen —, sondern weil jede Operation 10–13 Mikrosekunden Server-CPU und ~9 Mikrosekunden Client-CPU durch eine Kette aus Hops, Kopien, redundanten Hashes und Locks schleppt. Der Boden wird von der Installation bestimmt, nicht von der Arbeit.

Das ermutigende Korollar: Der Boden besteht aus behebbaren Dingen, und die Schätzung, was ihre Behebung bringt, ist konkret. Die strukturelle Liste lautet:

1. Den Egress auf einen Hop und eine Kopie zusammenfassen.
2. Den RF1-Hot-Path inline auf dem Empfangs-Thread ausführen oder pro Empfang gebündelt.
3. Tabellengetriebenes CRC16, einmal pro Operation gehasht.
4. Client-Completions ohne Allokation und ohne Thread-Pool-Sprung.
5. ValueTask-basierter Socket-Empfang auf dem Client.
6. Die Umgebungsvariable für den Request-Timeout cachen, statt sie pro Operation zu lesen.
7. Das Lizenzurteil in einem volatile-Feld veröffentlichen — kein Lock, keine Uhr auf dem Hot Path.
8. Eine allgemeine Allokationsdiät: gepoolte Antworten, keine Client-ID pro Request, keine unverlangten Metadaten.

Zusammen sollen diese Maßnahmen die Server-CPU pro Operation von ~10 auf ~3–4 Mikrosekunden senken — der Unterschied zwischen einem Dutzend ausgelasteter Kerne für eine Million Ops/s und etwa vier.

Die ehrlichen Einschränkungen​

Zwei Dinge halten diesen Beitrag wahrhaftig statt triumphal.

Erstens, die absoluten Zahlen hier sind Laptop-Zahlen, und sie liegen vermutlich 2- bis 4-mal unter dem, was echte Server-Hardware mit dedizierten Client-Maschinen erreicht. Was sich zwischen Umgebungen überträgt, ist nicht der absolute Durchsatz — sondern die relative Zuordnung: Der Store ist nicht der Engpass, der Egress ist der größte Serverkostenpunkt, und der Client verbraucht so viel wie der Server. Diese Schlussfolgerungen sind maschinenunabhängig; die endgültige Ops/s-Zahl ist es nicht, und die echte Validierung findet im großen Maßstab auf Kubernetes statt, nicht auf einer Workstation.

Zweitens, Replikation verändert die Obergrenze. Alles oben ist die RF1-Geschichte — eine einzelne Kopie, der schnelle Fall. Ein RF2-PUT muss dauerhaft auf ein Backup repliziert werden, bevor er bestätigen kann, und das ist ein grundlegend anderer und teurerer Pfad; ein realistisches Ziel dafür sind 400–500K pro Node, nicht eine Million. Und wenn Sie keine Round-Trips pro Operation brauchen, amortisiert der Batch-Pfad fast diesen gesamten festen Overhead über viele Operationen und kann heute eine Million pro Node erreichen. Die Ein-Million-Ops-Zahl für einzelne Operationen auf einem einzelnen Node ist ein Ziel, das die obige strukturelle Arbeit erreichen soll — keine Zahl, die wir als ausgeliefert nennen.

Diese Unterscheidung ist die gesamte Disziplin vertrauenswürdiger Performance-Arbeit: trennen, was die Messung beweist (der Store ist schnell, die Installation ist der Boden, und hier ist, wohin jede Mikrosekunde geht), von dem, was sie verspricht (eine bestimmte Zahl nach einer bestimmten Liste von Änderungen). Das Erste ist erledigt und solide. Das Zweite ist Ingenieursarbeit, die wir nun mit einer Karte statt einer Vermutung angehen können — und genau deshalb instrumentiert man den Pfad, bevor man ihn anfasst.

Ein Failover ist das, was passiert, wenn ein Owner stirbt — der Cluster hat Sekunden, um einen Überlebenden zu wählen, und die Partition-Map bewegt sich nie. Migration ist der ruhigere, gefährlichere Cousin: Der Owner ist völlig gesund, und Sie wollen eine Partition absichtlich von ihm wegbewegen — um den Cluster zu vergrößern, neu zu balancieren oder einen Node zu leeren, den Sie außer Dienst stellen wollen. Nichts ist ausgefallen, und genau deshalb liegt die Latte höher. Ein Failover darf im schlimmsten Fall einige ehrlich verlorene Schreibzugriffe am Ende in Kauf nehmen; eine geplante Migration nicht. Wenn das Verschieben einer Partition von Node A zu Node B einen einzigen bestätigten Schreibzugriff verlieren kann, ist Migration kein Feature, sondern eine Belastung.

Dieser Beitrag geht das Cut-over-Protokoll durch, das Zaris tatsächlich ausführt, in dieser Reihenfolge, und verbringt die meiste Zeit bei dem einen Schritt, den alle falsch machen: dem Moment, in dem die Quelle schließlich „frei" ist, ihre Kopie zu verwerfen. Dieser Schritt ist eine geladene Waffe, und das Interessante an der Ingenieursarbeit ist die Sicherung daran.

Die Form des Problems​

Eine Partition ist eine Menge von Segmenten, und ein Segment ist ein Beutel von Key/Value-Records, jeder mit einer monotonen Revision. Die Migration verschiebt die Daten eines Segments von einem Quell-Node zu einem Ziel-Node und kippt dann das Ownership, sodass Clients zum Ziel routen. Das Ganze geschieht, während das Segment live ist: Lese- und Schreibzugriffe landen die ganze Zeit weiter.

Diese Live-Eigenschaft ist das Problem. Wenn Sie die Quelle snapshotten, die Bytes verschicken und das Ownership kippen, liegt jeder Schreibzugriff, der während des Versands landete, auf der Quelle und nicht auf dem Ziel — und im Moment des Kippens verschwinden diese Schreibzugriffe aus der gerouteten Sicht. Sie haben sie bestätigt; der Client wurde über „committet" informiert; jetzt sind sie weg. Die naive Migration verliert genau die Schreibzugriffe, die stattfanden, während sie damit beschäftigt war, sorgfältig mit denen davor umzugehen.

Das Protokoll muss also zwei Dinge tun, die in Spannung zueinander stehen: bis unmittelbar zum Flip weiter Schreibzugriffe auf der Quelle bedienen und garantieren, dass das Ziel jeden dieser Schreibzugriffe hält, bevor der Flip wirksam wird. Zaris löst diese Spannung mit einer Sequenz aus fünf Schritten, von denen jeder sich weigert fortzufahren, bevor der vorherige nachweislich abgeschlossen ist.

Schritt 1 — ein an eine Revision verankerter Snapshot, mit festgenageltem Trim-Floor​

Das Ziel beginnt damit, die Daten des Segments von der Quelle anzufordern (SegmentMigrationRequest). Die Quelle serialisiert nicht einfach ihr aktuelles Dictionary; sie erstellt einen an eine Revision verankerten Snapshot. Sie notiert die aktuelle Revision des Segments — nennen wir sie R — und erfasst die Live-Records zum Stand R.

In diesem einen Schritt stecken zwei Feinheiten. Erstens schaltet die Quelle ihr Op-Log scharf, bevor sie den Anker erfasst. Zaris kann das Op-Log für ein Segment mit einzigem Primary (RF1) als Optimierung des Schreibpfads überspringen; es zuerst scharf zu schalten bedeutet, dass jeder Schreibzugriff ab diesem Punkt protokolliert wird, sodass ein zuvor ohne Log geschriebener Schreibzugriff trotzdem eine Revision bei oder unter R hat und vom Snapshot selbst getragen wird. Das Delta, das wir später berechnen — „Operationen nach R" —, ist dann nachweislich lückenlos.

Zweitens nagelt die Quelle den Trim-Floor ihres Op-Logs bei R fest:

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);

Normalerweise trimmt das Op-Log alte Einträge, um Speicher zurückzugewinnen. Während einer Migration wäre das ein Desaster: Wenn der Floor während der laufenden Massenübertragung über R hinaus vorrückte, wären die Schreibzugriffe zwischen R und dem Flip nicht mehr abspielbar, und das finale Delta wäre stillschweigend unvollständig. Das Festnageln des Floors bei R garantiert, dass diese Schreibzugriffe überleben, bis das Ziel sie hat. Die Quelle streamt dann die Snapshot-Einträge — und bedient die ganze Zeit weiter Lese- und Schreibzugriffe. Sie ist weiterhin der geroutete Owner. Noch hat sich nichts bewegt.

Schritt 2 — das Ziel wartet, absichtlich​

Das Ziel wendet den Bulk-Snapshot an und tut dann etwas, das wie Untätigkeit aussieht, aber das Herz des Designs ist: Es versetzt das Segment in einen Zustand Warten auf Cut-over und hält an. Es bestätigt der Quelle nichts. Es erhebt keinen Anspruch auf Ownership. Es sagt dem Leader nicht, dass es fertig ist. Der Kommentar im Code ist unverblümt, warum:

Kein Ack an die Quelle (sie ist noch der geroutete Owner), KEIN Ownership-Anspruch und noch KEINE Completion-Benachrichtigung — die Completion wird zurückgehalten, bis das gefencte finale Delta bestätigt, dass dieser Node alles hält, was die Quelle bestätigt hat.

Das ist der „Old-owner-authoritative"-Vertrag. Bis zum Flip antwortet genau ein Node für das Segment, und das ist die Quelle. Ein Ziel, das voreilig startet — und von einem Snapshot bedient, der bereits um einige Hundert Schreibzugriffe veraltet ist —, wäre ein Split-Brain. Das Ziel hält also inne und bittet um das Eine, mit dem es nachweisen kann, dass es aufgeholt hat: das finale Delta.

Schritt 3 — das durch einen Write-Fence abgesicherte finale Delta und der Digest-Nachweis​

Das Ziel sendet ein SegmentMigrationFinalDeltaRequest, verankert bei R. Hier erledigt die Quelle den sorgfältigen Teil.

// 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);

Sie aktiviert einen Write-Fence auf dem Segment und liest dann die aktuelle Revision. Die Reihenfolge zählt: erst fencen, dann messen, damit es kein Fenster gibt, in dem ein Schreibzugriff an der Messung vorbeischlüpft. Dann liest sie jeden Op-Log-Eintrag nach R — das Delta von allem, was während der Massenübertragung landete — und berechnet einen Content-Digest des Live-Zustands des Segments. Dieser Digest ist der Dreh- und Angelpunkt des gesamten Protokolls, daher notiert die Quelle ihn als Cut-over-Nachweis:

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);

Genau hier ist ein ehrlicher Fehlermodus eingebaut. Sollte der Trim-Floor tatsächlich über R hinaus vorgerückt sein — ein verlorener oder zurückgesetzter Pin —, wäre „Operationen nach R" unvollständig, und das Verschicken dieses Deltas würde bestätigte Schreibzugriffe stillschweigend verwerfen. Die Quelle weigert sich:

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.
}

Ein Abbruch unter dem Floor ist kein Verlust; er baut ab und erstellt von einem frischen Anker aus einen neuen Snapshot. Die Regel, an die sich der Code hält, lautet: lauter Abbruch statt stillem Teilergebnis — die Migration startet lieber neu, als auf einem unvollständigen Delta zu kippen.

Schritt 4 — das Gate: das Ziel weist nach, dass es dominiert​

Das Ziel wendet das Delta an, berechnet dann seinen eigenen Content-Digest des Segments und vergleicht ihn mit dem der Quelle:

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

Sind die beiden Digests gleich, hält das Ziel Byte für Byte das, was die Quelle am Fence hielt — der Zustand des Ziels ist eine Obermenge jedes Schreibzugriffs, den die Quelle bestätigt hat. Unterscheiden sie sich, liegt es fast immer daran, dass der gestreamte Snapshot noch angewendet wird, wenn das erste Delta berechnet wird (das Completion-Signal kann eingereihte Daten-Batches überholen); das Ziel bleibt dann ausstehend und lässt einen zeitlich versetzten Retry das Delta erneut anfordern, statt zu spinnen. Eine Abweichung kippt nie. Der Flip hängt an einem positiven Nachweis der Gleichheit, nicht an der Abwesenheit eines Fehlers.

Es gibt noch etwas, das das Ziel tut, bevor es den Sieg erklärt, und es ist eine Garantie, die die meisten Migrationsimplementierungen auslassen. Die Quelle ist nicht die einzige Kopie, die vorne liegen könnte — eine Replica des Segments könnte einen Schreibzugriff halten, den die gefencte Quelle verpasst hat. Bevor es abschließt, faltet das Ziel daher den schreibgeschützten Tail jeder Live-Replica ein:

Der Flip darf nur ausgelöst werden, wenn der Digest des neuen Owners die Quelle und jede Live-Replica des Segments dominiert.

Die Faltung erhält die Revisionen: Ältere Records einer hinterherhinkenden Replica werden vom Revisions-Gate ignoriert, und eine vorauseilende Replica steuert genau den Schreibzugriff bei, den die Quelle nicht hatte. Erst wenn das Ziel die Quelle und jede Live-Replica dominiert, geht es weiter. Das ist die Invariante „Dauerhaftigkeit vor Ownership" — Ownership ist die Belohnung für nachweisbaren Besitz, nicht seine Voraussetzung.

Schritt 5 — der Flip und der Drop, der fast Ihre Daten verliert​

Jetzt meldet das Ziel dem Leader, dass es fertig ist (SegmentMigrationCompletionNotify). Der Leader validiert die Completion gegen den aktuellen Migrations-Override und schaltet eine atomare Cut-over-Neuberechnung der Partition-Map scharf — eine einzige versionierte Map-Änderung, die den Owner des Segments auf das Ziel kippt und den Migrations-Override entfernt. Nachdem diese Map angewendet wurde, ist das Ziel der geroutete Owner. Clients routen zu ihm. Der Umzug ist aus Sicht des Clusters erledigt.

Und die Quelle, die nun ein Segment hält, für das sie keine Rolle mehr hat, führt einen Aufräumlauf aus, um die verwaiste Kopie zu verwerfen und den Speicher freizugeben. Das ist die geladene Waffe.

Hier ist die Falle, und sie ist subtil genug, dass sie bis in einen Zertifizierungslauf überlebte, bevor sie gefangen wurde (Missing=8629 bestätigte Keys weg). Ein Write-Fence reduziert das Bestätigen, bringt es bei einem Segment mit einer einzigen Kopie unter Last aber nicht sofort perfekt auf null. Also ist folgende Sequenz möglich:

1. Die Quelle liefert den Digest des finalen Deltas als Nachweis. Das Ziel gleicht ihn ab und kippt.
2. Im winzigen Zeitfenster zwischen der Auslieferung des Nachweises und dem Wirksamwerden des Flips wird auf der Quelle noch ein weiterer Schreibzugriff bestätigt.
3. Das Ziel hat diesen Schreibzugriff nie erhalten — der Nachweis, den es abgeglichen hat, stammte von vor ihm.
4. Die Quelle, nun verwaist, verwirft ihre Kopie, um Platz zu gewinnen.
5. Dieser letzte Schreibzugriff existierte nur auf der Quelle. Er ist weg. Einem Client wurde gesagt, er sei committet.

Die Lösung besteht darin, den Drop davon abhängig zu machen, dass der Nachweis weiterhin zutrifft. Die Quelle vernichtet ein verwaistes Segment nicht blind. Sie vergleicht den aktuellen Live-Digest des Segments mit dem Digest, den sie als Cut-over-Nachweis notiert hat, und zerstört die Daten nur, wenn beide noch übereinstimmen:

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);
}

Ist nach dem Nachweis ein Schreibzugriff gelandet, unterscheidet sich der aktuelle Digest vom Nachweis-Digest, ShouldRetainAfterCutover liefert true, und die Quelle behält ihre Kopie:

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
}

Die Asymmetrie ist der ganze Punkt. Behalten ist immer sicher: Die Quelle ist nicht mehr der geroutete Owner, also ist eine behaltene Kopie ein redundantes, nicht bedientes Waisenkind — sie kann nie ein Split-Brain verursachen, sie kostet nur etwas Speicher, bis ein erneutes Bedienen den Tail an den neuen Owner ausliefert und ein späterer Lauf, der die Digests wieder übereinstimmend findet, sie sauber verwirft. Zerstören auf einem veralteten Nachweis ist nie sicher: Es ist die eine Operation, die einen bestätigten Schreibzugriff dauerhaft löschen kann. Die Richtlinie ist deshalb bewusst eng gefasst — sie überstimmt ausschließlich einen Drop, der sonst stattfinden würde, und nur für ein Segment mit einem aufgezeichneten Nachweis, dessen Digest nicht mehr passt. Segmente ohne Nachweis (eine Eviction, ein sofortiger Flip, ein nie migriertes Segment) behalten ihr bisheriges Verhalten unverändert. Das Gate fügt ein Behalten hinzu; es fügt nie ein Verwerfen hinzu.

Warum der Digest und nicht eine Revisionsnummer?​

Man könnte fragen, warum der Nachweis ein Content-Digest ist und nicht einfach „die höchste Revision, die das Ziel bestätigt hat". Die Antwort: Eine Revisionsnummer sagt Ihnen, wie weit das Ziel gekommen ist, aber ein Digest sagt Ihnen, ob das, was es bekommen hat, das ist, was Sie hatten. Beides kann in den Nahtstellen auseinanderlaufen — eine Replica-Faltung, ein neu verankerter Retry, ein noch abfließender Snapshot —, und die einzige Frage, die Daten sicher hält, ist die inhaltliche: Hält der neue Owner genau dies? Ein Digest beantwortet das direkt. Ein Watermark beantwortet nur einen Stellvertreter dafür, und Stellvertreter sind der Ort, an dem bestätigte Schreibzugriffe sterben.

Was das ehrlich bringt​

Klar gesagt lautet die Garantie: Eine geplante Partition-Migration verliert keinen bestätigten Schreibzugriff. Jeder Schreibzugriff, den die Quelle vor dem Fence bestätigt hat, ist im Snapshot oder im Delta; jeder Schreibzugriff, den sie nach dem Nachweis bestätigt hat, hält die Kopie der Quelle am Leben, bis auch der neue Owner ihn hat. Das Protokoll bricht lieber laut ab und startet neu, als auf einem unvollständigen Delta zu kippen, und es faltet Live-Replicas ein, sodass der neue Owner jede Kopie dominiert, nicht nur die Quelle.

Was es nicht ist, ist kostenlos. Das gefencte finale Delta ist ein synchroner Round-Trip, der Schreibzugriffe auf dem zu migrierenden Segment kurz fenced — eine kurze, begrenzte Pause auf einem Segment, nicht auf der Partition und nicht im Cluster. Eine Migration, die nicht konvergieren kann (ein Trim-Floor, der immer weiter vorrückt, ein Replica-Tail, der sich aus seinem Log nicht ausdrücken lässt), erstellt einen neuen Snapshot und wiederholt, statt Fortschritt zu erzwingen; unter pathologischem Churn bedeutet das, dass eine Migration länger dauert, statt eine Abkürzung durch Ihre Daten zu nehmen. Das sind die richtigen Kompromisse für eine geplante Operation: Ein Umzug, für den Sie sich entschieden haben, sollte nie der Grund sein, dass ein committeter Schreibzugriff verschwindet.

Dies ist dasselbe Rückgrat, das die zwölfstündige Chaos-Zertifizierung von außen belastet — einen Node mitten in der Migration stoppen, die Map durcheinanderwirbeln und zusehen, wie bestätigte Schreibzugriffe überleben. Dieser Beitrag ist die Innenansicht einer der Nahtstellen, die dieser Lauf als geschlossen nachweist: der Moment, in dem eine Partition den Besitzer wechselt, und die Sicherung am Abzug, die verhindert, dass die Übergabe genau die Schreibzugriffe verschlingt, die sie schützen soll. Er stützt sich auf zwei weitere Teile, die für sich lesenswert sind — das wiederholbare Op-Log, das „Operationen nach Revision R" zu einer echten, lückenlosen Abfrage macht, und das elastische Scale-out, der häufigste Grund, warum eine Partition überhaupt umziehen muss.

Ein einzelnes GET auf einen Key ist leicht zu durchdenken: den Key hashen, den Owner finden, genau diesen einen Node fragen. SCAN ist die gegenteilige Art von Operation. Es hat keinen Key — es stellt eine Frage über den gesamten Keyspace: Gib mir jeden Key in diesem Bereich, Seite für Seite. Und in einem partitionierten, replizierten Store ist dieser Keyspace nicht eine Sache an einem Ort. Er ist über 256 Segmente verteilt, die auf so viele Nodes entfallen, wie Sie betreiben, wobei jeder Node nur die Ausschnitte hält, die er gerade besitzt, und während Sie iterieren, wird in die Gesamtheit geschrieben. Es gibt keinen globalen sortierten Index zum Durchlaufen. Woher kommt also die Ordnung, worauf zeigt ein Resume-Token genau, und was passiert mit Ihrem Scan, wenn mittendrin ein Key geschrieben wird — oder eine Partition umzieht?

Dieser Beitrag folgt einem SCAN durch die drei Schichten, die ihn tatsächlich bedienen: ein einzelnes Segment, ein einzelner Node und der Client, der die Nodes zusammenfügt. Jede Schicht löst ein Teilstück des Problems, und die ehrlichen Grenzen der Operation ergeben sich daraus, wie diese Teile zusammenpassen.

Die Anfrage: ein Bereich und eine Seitengröße, kein Key​

Ein Scan wird durch zwei kleine Objekte beschrieben. Ein KeyRange sagt, welche Keys — ein Start, ein Ende oder ein Präfix, jeweils optional:

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

Und ScanOptions sagt, wie sie geliefert werden — wie groß eine Seite ist, ob Werte oder nur Keys übertragen werden, ein optionales hartes Limit und ein Resume-Token, um einen vorherigen Aufruf fortzusetzen:

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; }
}

Nichts davon nennt einen Node oder ein Segment. Das ist der Punkt: Der Aufrufer beschreibt, was er will, und die drei Schichten darunter finden heraus, wo es liegt und in welcher Reihenfolge es zurückgegeben wird.

Schicht eins: ein Segment scannt sich selbst, lock-frei und geordnet​

Die kleinste Einheit, die einen Teil eines Scans beantworten kann, ist ein Segment — die Einheit der partitionierten Speicherung in Zaris, gestützt auf ein ConcurrentDictionary mit Live-Records. Ein Dictionary hat keine Ordnung, also braucht ein Segment-Scan zuerst eine sortierte Sicht seiner Keys. Diese bei jeder Seite neu aufzubauen wäre ruinös, daher hält jedes Segment einen gecachten, unveränderlichen Snapshot sortierter Keys und baut ihn nur neu auf, wenn sich die Key-Menge ändert:

// 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;

Das Array wird einmal zugewiesen und nie verändert; ein nebenläufiger Neuaufbau erzeugt einfach ein neues Array und tauscht die Referenz. Der Scan-Durchlauf selbst nimmt also überhaupt keinen Lock — er sucht per Binärsuche den Start-Key und läuft in ordinaler Reihenfolge vorwärts, wobei er Live-Records aus dem Concurrent-Dictionary liest. Lese- und Schreibzugriffe auf das Segment blockieren den Scan nie, und der Scan blockiert sie nie.

Zwei Arten von Keys werden beim Durchlaufen stillschweigend übersprungen:

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

Ein gelöschter Key ist ein Tombstone — ein echter Record, der als IsDeleted markiert ist, weil ein Löschvorgang ein Record sein muss und keine Abwesenheit, damit die Replikation ihn weitertragen kann. Der Scan filtert diese heraus, ebenso Keys, deren TTL abgelaufen ist, deren Sweeper aber noch nicht gelaufen ist. Der Snapshot der sortierten Keys ist also eine Obermenge dessen, was Sie sehen; Ablauf und Löschung werden beim Lesen gegen den Live-Record aufgelöst und nicht im Snapshot eingefroren.

Der Durchlauf stoppt bei PageSize und liefert ein ResumeToken. Hier ist das erste ehrliche Detail: Auf Segmentebene ist das Token im Wesentlichen ein Offset — eine Zählung, wie viele passende Einträge bereits zurückgegeben wurden (ReturnedSoFar). Ein fortgesetzter Segment-Scan sucht erneut per Binärsuche denselben Start-Key und überspringt so viele Treffer, bevor er ausgibt. Es ist eine Position per Zählung, kein Seek per Key.

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

Diese Wahl ist wichtig für das, was die Operation verspricht, und wir kommen darauf zurück.

Schicht zwei: ein Node führt seine Segmente zu einem einzigen geordneten Strom zusammen​

Ein Node besitzt viele Segmente — nicht alle 256, sondern die, die den Partitionen zugeordnet sind, die er gerade bedient. Ein Scan auf Node-Ebene muss alle davon als ein geordnetes Ergebnis präsentieren, weil der Aufrufer nach einem Bereich gefragt hat, nicht nach Segment 42. Das ist ein klassisches Merge-Problem: Jedes Segment kann seine Keys sortiert liefern, und gewünscht ist die sortierte Vereinigung.

Die erste Seite eines Node-Scans tut genau das. Sie sammelt einen Fetcher für jedes lokal besessene Segment und führt mit einer Prioritätswarteschlange einen k-Wege-Merge über sie aus, wobei Keys ordinal verglichen werden:

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

Das zusammengeführte, geordnete Ergebnis wird in einen Buffer materialisiert, der von einem RouterQueryCoordinator gehalten wird — einer kurzlebigen, serverseitigen Session, die unter einer frisch erzeugten QueryId registriert ist:

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 };

Jede weitere Seite ist nur eine Scheibe dieses Buffers, und das Resume-Token des Nodes trägt die QueryId, damit der nächste Aufruf dieselbe Session findet:

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).");
}

Das ist das zweite ehrliche Detail, und es ist ein echter Kompromiss. Ein Scan auf Node-Ebene ist zustandsbehaftet: Das Paging ist stabil und die Ordnung pro Node exakt, aber der Preis ist, dass der Node beim Beginn des Scans seinen gesamten besessenen, zusammengeführten Keyspace in einen Buffer materialisiert und für die Dauer der Iteration eine Session hält. Scans sind ein Werkzeug für Administration und Massen-Iteration, kein Streaming-Cursor mit konstantem Speicherbedarf über Milliarden von Keys — und ein Resume-Token gilt nur gegenüber dem Node und der Session, die es erzeugt haben. Lassen Sie diese Session ablaufen oder versuchen Sie, an anderer Stelle fortzusetzen, erhalten Sie ein lautes „Session nicht gefunden" statt einer still falschen Antwort.

Schicht drei: Der Client verteilt per Fan-out und verzahnt die Owner​

Ein Node antwortet für die Segmente, die er besitzt. Ein Cluster-Scan muss jeden Owner abdecken, daher öffnet der clientseitige ScanClusterClient einen Scan gegen jeden Node parallel und verzahnt deren Seiten, sobald sie eintreffen, statt einen Node vollständig abzuarbeiten, bevor der nächste beginnt:

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));

Diese Parallelität ist der Grund, warum LimitCount Sorgfalt braucht. Jeder Node behandelt das Limit als Obergrenze pro Node; würde der Client es nicht zusätzlich durchsetzen, könnte ein LimitCount von 1.000 gegen vier Owner nach dem Zusammenführen bis zu 4.000 Zeilen liefern. Die Cluster-Schicht wendet das Limit daher als hartes Gesamtlimit an und liefert nichts mehr aus, sobald es erreicht ist — während sie die laufende Seite jedes Owners dennoch bis zum Ende abarbeitet, weil das Disposen eines asynchronen Enumerators mitten im Move nicht erlaubt ist und die Ergebnisse pro Node ohnehin begrenzt sind:

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

Die Konsequenz, die klar benannt sein muss: Innerhalb des Beitrags eines einzelnen Nodes kommen Keys geordnet an; zwischen Nodes werden sie nach Ankunft verzahnt, sodass ein vollständiger Cluster-Scan nicht global sortiert ist, es sei denn, Sie verlangen es ausdrücklich. (Der verwandte Search-Pfad trägt aus genau diesem Grund SortFields und führt mit einem Comparator zusammen.) Wenn Sie jeden Key im Cluster in ordinaler Reihenfolge brauchen, sortieren Sie das zusammengesetzte Ergebnis; SCAN selbst garantiert Ordnung pro Owner und Vollständigkeit, keine globale Sortierung.

Was ein SCAN verspricht — und was nicht​

Setzt man die drei Schichten zusammen, wird der tatsächliche Vertrag der Operation sichtbar, ohne dass etwas davon verborgen wird:

• Es ist kein Point-in-Time-Snapshot des Clusters. Jeder Node materialisiert seinen eigenen zusammengeführten Buffer, wenn sein Scan beginnt, und diese Zeitpunkte fallen nicht zusammen. Schreibzugriffe, die vor dem Aufbau des Buffers auf einem Node landen, sind enthalten; spätere nicht. Es gibt kein clusterweites Einfrieren.
• Gelöschte und abgelaufene Keys erscheinen nie. Tombstones und Records mit abgelaufener TTL werden beim Durchlaufen des Segments gegen den Live-Record gefiltert, ein Scan spiegelt also den logischen, nicht den physischen Inhalt wider.
• Das Fortsetzen ist eine Position per Zählung innerhalb einer Session. Da der Cursor pro Segment ein Offset ist, kann ein Key, der zwischen zwei Seiten vor der aktuellen Position eingefügt oder entfernt wird, die Grenze verschieben — ein Scan, der nebenläufig zu starker Mutation des gescannten Bereichs läuft, kann prinzipiell einen Key an der Nahtstelle wiederholen oder überspringen. Ein Scan eines ruhenden Bereichs ist exakt. Das ist dieselbe Garantiefamilie, die Redis SCAN bietet — eine Best-Effort-Vollständigkeits-Iteration, keine Snapshot-Isolation — und es ist der richtige Kompromiss für einen ungeordneten, nebenläufig beschriebenen Store.
• Der Keyspace kann sich unter Ihnen bewegen. Der Client verteilt per Fan-out an die Owner, die beim Start des Scans existieren. Partitionen können mitten in der Iteration migrieren oder ein Failover erleben; ein Scan ist ein Best-Effort-Durchlauf eines Live-Clusters, weshalb er das Werkzeug für Massen-Export, Reindexierung und administrative Abfragen ist und nicht für transaktionale Lesezugriffe. Für Read-your-writes auf einem einzelnen Key routen Sie stattdessen zum Owner.

Nichts davon sind Bugs, die man übertünchen müsste; es ist die ehrliche Form der Iteration über einen ungeordneten, geshardeten, sich verändernden Keyspace, ohne die Welt anzuhalten. Das Design macht den billigen, häufigen Fall schnell — einen lock-freien sortierten Snapshot und einen Merge pro Node — und ist bei den Rändern ausdrücklich.

Ein Hinweis zum RESP-Front-End​

Redis-Clients erreichen dieselbe Maschinerie über KEYS und SCAN auf dem RESP-Front-End, die auf den nativen Scan abgebildet werden. Ein Vorbehalt, der klar gesagt sein sollte: Das RESP-SCAN ist heute Single-Shot — es arbeitet den nativen Scan vollständig ab und antwortet in einem Round-Trip mit Cursor 0 (Iteration abgeschlossen), statt den inkrementellen Cursor von Redis durch jeden Aufruf zu fädeln. Es ist ehrlich bei der Vollständigkeit, aber noch nicht inkrementell. Der native Client ist derjenige, der mit einem Resume-Token seitenweise abruft.

Eine Operation, drei ehrliche Schichten​

Ein GET berührt einen Owner und einen Key; ein SCAN berührt jeden Owner und bittet jeden, seinen Ausschnitt eines geordneten Ganzen zu liefern. Die Arbeit teilt sich sauber auf: Ein Segment macht aus einem ungeordneten Dictionary einen sortierten, lock-freien Durchlauf; ein Node führt seine Segmente zu einem geordneten, stabil seitenweisen Strom hinter einem Session-Cursor zusammen; der Client verteilt per Fan-out an die Owner, verzahnt deren Seiten und setzt das eine Limit durch, das der Fan-out sonst brechen würde. Jede Schicht ist für sich einfach, und die Garantien der Operation — Ordnung pro Owner, Vollständigkeit über einen ruhenden Bereich, keine Snapshot-Isolation, kein globales Einfrieren — sind genau das, was diese drei einfachen Schichten gemeinsam ehrlicherweise liefern können.

Hier ist eine Frage, die einfach klingt und es nicht ist: Was passiert, wenn einem In-Memory-Store der Speicher ausgeht?

Die naive Antwort lautet „er stürzt ab" — der Prozess wächst, bis das Betriebssystem ihn beendet. Die etwas weniger naive Antwort lautet „er lehnt Schreibzugriffe ab". Zaris tut standardmäßig keines von beidem. Ein Zaris-Node ist ein In-Memory-Store, aber bewusst kein unbegrenzter: Jeder Node ist ein begrenzter Puffer mit einer harten Obergrenze, und wenn sich die Daten, die er besitzt, dieser Obergrenze nähern, entfernt der Node seine kältesten Daten, um Platz zu schaffen. Schreibzugriffe gelingen weiter; das Limit hält; der Prozess bläht sich nicht auf. Der Node verhält sich wie ein Cache, denn darunter ist er einer.

Jeder Node ist ein begrenzter Puffer​

Ein Zaris-Node wächst nicht ohne Grenze. Jeder Node bilanziert fortlaufend die Größe der Daten, die er aktiv besitzt, und hält diese laufende Summe unter einer konfigurierten Obergrenze. Diese Bilanzierung ist nie optional — ein Node ist immer ein begrenzter Puffer. Konfigurierbar sind nur, wie groß die Obergrenze ist und im Prinzip, was der Node tut, wenn er sie erreicht.

Die Standardobergrenze beträgt 1 GiB aktiv besessener Daten pro Node. Eine Einstellung „unbegrenzt" gibt es bewusst nicht. Setzen Sie keine Obergrenze, erhalten Sie den Default — Sie bekommen nie versehentlich Unendlich.

Ein Detail ist wichtig, um den Footprint eines Clusters zu beurteilen: Die Obergrenze deckt die Daten ab, die ein Node aktiv besitzt — die Primärkopien, die er Clients bereitstellt. Replica-Kopien, die ein Node für andere Partitionen hält, werden separat erfasst und zählen nicht gegen die Obergrenze für aktive Owner. Der tatsächlich belegte Speicher eines Nodes ist also sein besessenes Working Set plus alle Replica-Kopien, die er für seine Peers trägt; die Obergrenze regelt Ersteres, nicht die Summe.

Zwei Wege, die Linie zu halten​

Ein begrenzter Puffer kann genau zwei Dinge tun, wenn ein Schreibzugriff ihn über seine Obergrenze triebe: etwas Altes verwerfen, um Platz zu machen, oder den neuen Schreibzugriff ablehnen.

Bei aktivierter Eviction ist ein Node ein Cache: Unter Druck verwirft er die am wenigsten wertvollen Daten, damit Schreibzugriffe weiterfließen. Bei deaktivierter Eviction ist er ein Store, der bei voller Kapazität ablehnt und bestehende Daten schützt, indem er neue Schreibzugriffe abweist.

Hier kommt der ehrliche Teil. In der aktuellen Version läuft ein Node immer mit aktivierter Eviction und der LRU-Policy. Der Modus ohne Eviction und die alternativen Policies (LFU, TTL-bewusst) existieren in der Engine, sind aber noch nicht per Konfiguration wählbar. Praktische Folge: CapacityExceeded — der Status für Ablehnung bei voller Kapazität — ist heute im Wesentlichen nicht erreichbar: Ein voller Node entfernt Daten, statt abzulehnen. Es ist ein echter, typisierter Status, gegen den Sie Code schreiben können, aber unter der stets aktiven LRU-Policy werden Sie ihn normalerweise nicht sehen. Der eine Speicher-Regler, den Sie derzeit tatsächlich steuern, ist die Größe der Obergrenze selbst, memory.maxSizeBytes.

Der Eviction-Lauf bewegt sich in einem ruhigen Band​

Das Interessante an der Ingenieursarbeit ist nicht, dass ein Node Daten entfernt — sondern wie, denn ein naives Design „bei jedem Schreibzugriff entfernen, sobald voll" flattert kläglich. Stellen Sie sich einen Node vor, der genau an seiner Obergrenze sitzt: Jeder einzelne eingehende Schreibzugriff würde eine Eviction auslösen, um sich selbst Platz zu machen, und Sie würden diese Kosten für immer auf dem Hot Path zahlen.

Zaris vermeidet das mit zwei Maßnahmen. Erstens wird die Eviction von einer Hintergrundschleife getrieben, nicht vom einzelnen Schreibzugriff — der Schreibzugriff, der einen Node über die Kante kippt, wird zugelassen, und die Schleife schafft kurz darauf Platz, abseits des Request-Pfads. Zweitens nutzt die Schleife Hysterese: einen hohen Auslöser und ein niedrigeres Ziel, sodass sie in Schüben Platz schafft und dann ruhig wird, statt am Rand kontinuierlich zu feuern.

• Auslöser: Ein Lauf startet, wenn die aktive Nutzung über 80 % der Obergrenze steigt.
• Ziel: Einmal gestartet, entfernt der Lauf so lange Daten, bis wieder etwa 30 % der Obergrenze frei sind — bis die Nutzung auf etwa 70 % zurückgefallen ist.
• Taktung: Die Schleife wacht in einem festen Intervall auf (standardmäßig eine Sekunde) und zieht in jedem Zyklus eine begrenzte Stichprobe von Kandidaten.

Da das Ziel nach der Eviction (70 %) strikt unter dem Auslöser (80 %) liegt, senkt jeder Lauf die Nutzung in ein ruhiges Band, statt genau an dem Punkt zu stoppen, der ihn sofort wieder auslösen würde. Das ist der Sägezahn im Titelbild: Die Nutzung steigt auf 80 %, ein Lauf bringt sie zurück auf 70 %, und sie steigt erneut — nie an die Obergrenze gedrückt, nie mit einer Eviction pro Schreibzugriff flatternd.

Die Eviction-Policy selbst ist LRU — Least Recently Used — und sie arbeitet per Stichprobe, nicht strikt. Statt eine global geordnete Liste jedes Keys zu führen (was Speicher und Lock-Contention auf dem Hot Path kosten würde), stempelt Zaris auf dem Lesepfad ungefähre Aktualitätssignale an Ort und Stelle ein und zieht, wenn ein Lauf feuert, eine kleine Menge von Kandidaten und verwirft die mit der niedrigsten Bewertung. Es ist derselbe Stichprobenansatz, den Redis verwendet, und derselbe Kompromiss: Sie geben die perfekte Reihenfolge „den einen ältesten Key entfernen" auf und erhalten dafür eine Eviction, die fast nichts in der Pflege kostet und nie einen separaten Index braucht.

Die andere Obergrenze: die Größe pro Item​

Die gesamte Speicherobergrenze ist ein Limit für die Summe. Es gibt ein zweites, unabhängiges Limit für jedes einzelne Item: Standardmäßig darf ein Wert 4 MiB nicht überschreiten. Das wird bei jedem Schreibzugriff unabhängig vom Eviction-Modus geprüft, und hier trifft ein Schreibzugriff auf eine tatsächlich erreichbare Ablehnung.

Die Unterscheidung ist wichtig, weil die beiden Fehler entgegengesetzte Dinge bedeuten und entgegengesetzte Reaktionen verlangen:

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 ist in jedem Modus ein Live-, erreichbares Ergebnis — Eviction kann für einen Wert über dem Limit pro Item keinen Platz schaffen, denn bei dem Limit geht es nicht um freien Platz, sondern um einen einzelnen pathologischen Wert. CapacityExceeded erscheint, wie oben besprochen, nur im Modus ohne Eviction, den Sie noch nicht wählen können. Beide gleich zu behandeln ist ein Bug, der nur darauf wartet, aufzutreten: Einen ItemTooLarge-Schreibzugriff endlos zu wiederholen, wird nie gelingen.

Eine verwandte Eigenheit liegt an der Grenze zwischen diesem Limit pro Item und der .NET-Runtime: Werte ab etwa 85.000 Bytes landen auf dem Large Object Heap, daher ist das Anheben von maxItemSizeBytes, um große Werte zuzulassen, eine bewusste Entscheidung mit GC-Folgen und kein Regler zum Nulltarif. Wenn Sie große einfache Werte per Hot-Update ändern, ist das Zerlegen in Stücke unterhalb der LOH-Grenze der Mechanismus, der den LOH vom Churn bewahrt — ein eigenes Feature mit eigenen Kompromissen, das wir in Große Objekte speichern, ohne den Heap zu belasten aufgeschlüsselt haben.

Was Sie konfigurieren und was nicht​

Die Speicherobergrenze steht in der Store-Konfiguration im Abschnitt memory:

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

Das sind 2 GiB. Setzen Sie maxSizeBytes auf null oder lassen Sie es weg, erhalten Sie den Default von 1 GiB. In der aktuellen Version ist das die Speichereinstellung, die Sie steuern — die LRU-Policy, die Hysterese-Schwellen 80 %/70 % und die Taktung von 1 Sekunde sind feste Defaults, keine Regler. Es ist wichtig, hier nüchtern zu sein: Die Blogbeiträge und die Engine beschreiben einen reichhaltigeren Policy-Raum, als die Konfigurationsoberfläche derzeit bereitstellt, und dieser Beitrag beschreibt, was Sie heute tatsächlich einstellen können.

Was das für die Dimensionierung eines Clusters bedeutet​

Da jeder Node ein begrenzter Puffer ist, entspricht die Gesamtkapazität eines Stores grob der Obergrenze pro Node multipliziert mit der Anzahl der Partitionen, die ein Node besitzt, angepasst um den Replikationsfaktor (Replicas halten zusätzliche Kopien, die außerhalb der Obergrenze für aktive Owner liegen). Daraus ergeben sich zwei praktische Konsequenzen:

• Dimensionieren Sie die Obergrenze nach Ihrem Working Set plus Eviction-Spielraum, nicht nach Ihren Gesamtdaten. Ein Node betreibt heute einen stets aktiven LRU-Cache, sodass kalte Daten unter Druck verworfen statt abgelehnt werden. Passt Ihr Working Set unter etwa 70 % der Obergrenze, mit Raum für das Band zum Atmen, bleibt die Eviction ruhig und das Hot Set resident. Dimensionieren Sie die Obergrenze unter Ihrem Working Set, haben Sie einen Cache gebaut, der ständig Daten verwirft, die er gleich wieder braucht — korrekt, aber langsam, und aus dem Sägezahn wird ein Mahlen.
• Vergessen Sie den Replica-Footprint nicht. Die Obergrenze regelt besessene Daten, aber der tatsächliche RAM eines Nodes besteht aus besessenen Daten plus Replica-Kopien. Planen Sie beim Provisionieren von Speicher pro Pod oder pro Maschine beides ein, sonst läuft ein Node, der „auf seine Obergrenze" dimensioniert ist, immer noch heißer, als die Obergrenze vermuten lässt.

Für die Kapazitätsrechnung im Zusammenhang mit Partitionen, Replikationsfaktor und Pod-Anzahl rechnet Einen Zaris-Cluster für Dauerhaftigkeit unter Kubernetes dimensionieren die vollständige Berechnung durch.

Das Fazit​

Ein In-Memory-Store, der ohne Grenze wächst, ist kein Feature — er ist ein Ausfall, der auf eine Traffic-Spitze wartet. Zaris behandelt jeden Node als begrenzten Puffer mit einer echten Obergrenze (standardmäßig 1 GiB, keine unbegrenzte Option), einem stets aktiven Sampled-LRU-Cache darunter und einem Hysterese-Band, das Platz in ruhigen Schüben zurückgewinnt, statt am Rand mit einer Eviction pro Schreibzugriff zu flattern. Die Gesamtobergrenze und das Limit pro Item sind zwei verschiedene Limits mit zwei verschiedenen typisierten Status, und der, der heute tatsächlich erreichbar ist — ItemTooLarge — verlangt eine andere Reaktion als eine Retry-Schleife. Dimensionieren Sie die Obergrenze nach Ihrem Working Set, planen Sie Replica-Kopien obendrauf ein, und der Node hält seine Linie, ohne dass Sie ihn beobachten müssen.

Das vollständige Modell, einschließlich der Policies, die die Engine mitbringt, aber noch nicht bereitstellt, steht in Speicher und Eviction; die genauen Felder und Defaults stehen in der Konfigurationsreferenz, und jeder Kapazitätsstatus ist in der Status- und Exception-Referenz katalogisiert.

Das meiste von dem, was Zaris gut macht — einen Schreibzugriff auf ein Backup replizieren, eine hinterherhinkende Replica aufholen lassen, eine Partition auf einen neuen Owner umschalten —, läuft auf eine stille Frage hinaus: Was genau ist die Dateneinheit, die zwischen Nodes wandert? Stimmt diese Einheit, ist Konvergenz fast langweilig. Lässt sie ein Feld weg oder trägt das falsche, bekommen Sie einen wiederauferstandenen gelöschten Key, eine Replica, die Veraltetes nicht von Frischem unterscheiden kann, oder die Buchführung eines Nodes sickert auf einen anderen.

In Zaris ist diese Einheit ein einziger Typ — StoredRecord — und es lohnt sich, ihn Feld für Feld auseinanderzunehmen, denn jede Entscheidung darin ist tragend. Dieser Beitrag ist die Anatomie: was im Record steckt, wie er auf der Leitung gerahmt wird, warum ein Löschvorgang als Record statt als Abwesenheit reist, warum es zwei verschiedene Versionsnummern gibt und — genauso wichtig — was bewusst auf jedem Node zurückbleibt und die Leitung nie überquert.

Eine Payload, überall​

Ein Key/Value-Store hat überraschend viele Stellen, an denen „ein Wert" präzise beschrieben werden muss: die In-Memory-Map, der Replikationsstrom, der Migrations-Snapshot, das Operation-Log. Zaris verwendet für alle dieselbe Record-Form. Was im Dictionary des Segments liegt, ist dasselbe, was eine Replica erhält, und dasselbe, was ein neuer Owner beim Cut-over erhält. Diese Einheitlichkeit ist der Grund, warum das Operation-Log zwei Aufgaben zugleich erfüllen kann und warum ein Migrations-Snapshot und ein Replica-Backfill keine getrennten Kodierungen brauchen.

Hier ist der gesamte Typ, reduziert auf seine Wire-Oberfläche:

[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
}

Fünf Felder überqueren die Leitung. Zwei weitere leben auf dem Objekt, sind aber mit [IgnoreMember] markiert und reisen nie. Der Rest dieses Beitrags erklärt, warum jedes Feld dort sitzt, wo es sitzt.

Die Rahmung: MessagePack mit positionellen Keys​

Zaris serialisiert Records mit MessagePack, und die [Key(N)]-Attribute sind der Grund, warum die Leitung klein bleibt. MessagePack kann ein Objekt auf zwei Arten serialisieren: als Map von Feldname → Wert (selbstbeschreibend, aber jede Nachricht wiederholt jeden Feldnamen als String) oder als positionelles Array, in dem jedes Feld durch einen ganzzahligen Index identifiziert wird. Die Attribute [Key(0)], [Key(1)], … wählen die Array-Form. Auf der Leitung ist ein Record ein kurzes Array von Werten in fester Reihenfolge — keine Feldnamen, keine JSON-artige Interpunktion, nur die Payloads.

Das ist wichtig, weil dieser Record die heiße Datenstruktur des gesamten Systems ist. Er wird bei jedem replizierten Schreibzugriff und jedem migrierten Key serialisiert; bei Hunderttausenden Schreibzugriffen pro Sekunde ist der Unterschied zwischen dem millionenfachen Versand von "TimestampUtc" als String und dem Versand von nichts als der Position keine Mikrooptimierung, sondern das Budget.

Das positionelle Schema legt auch die Regel für die sichere Weiterentwicklung des Formats fest: Ganzzahl-Keys sind Append-only. Ein neues Feld bekommt den nächsten unbenutzten Index; bestehende Indizes ändern nie ihre Bedeutung. Ein älterer Node, der Index 7 nicht kennt, ignoriert ihn einfach; ein neuerer Node, der einen alten Record liest, findet Index 7 nicht vor und fällt auf einen Default zurück. Wir werden ein Feld sehen — Labels bei Map-Key 3 innerhalb der Metadaten —, das sich genau auf dieses Verhalten „abwesend heißt Default" stützt, um im Nichtgebrauch nichts zu kosten.

Im Entry: Key, Value und nicht-null Metadaten​

ZarisEntry ist das Feld Entry — der Teil, den ein Benutzer als „seine Daten" erkennen würde:

[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
}

Zwei Details hier lernt man nur, wenn man sich einmal verbrannt hat. Erstens ist Value als object typisiert, nicht als byte[] oder string — die konkrete Form des Wertes ist, was auch immer der Schreiber dort abgelegt hat, im Entry gerahmt; so trägt derselbe Record-Typ einen einfachen String, einen Zähler oder eine ganze replizierte Collection, ohne dass der Record wissen müsste, welche.

Zweitens werden Metadata über einen Getter bereitgestellt, der nie null zurückgeben kann:

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

MessagePack umgeht bei der Deserialisierung den Konstruktor und ruft Setter direkt auf, sodass ein einfacher Initialisierer = new() einen Round-Trip nicht überlebt — ein Record, der ohne Metadaten ankam, würde mit null deserialisiert, und jede nachgelagerte Aufrufstelle bräuchte eine Null-Prüfung. Der Getter macht die Garantie stattdessen strukturell: Metadaten sind immer da, auch wenn die Leitung keine trug. Eine Stelle, um die Invariante durchzusetzen, keine Null-Guards sonst irgendwo.

Metadaten, die im leeren Zustand nichts kosten​

EntryMetadata trägt die optionalen Attribute eines Keys — CreatedAt, Ttl, ContentType, ein optionales Lease- oder Lock-Handle und Labels. Das Labels-Feld ist eine kleine Meisterklasse darin, nicht für zu bezahlen, was man nicht nutzt. Die meisten Keys haben keine Labels, und ein naives, pro Entry initialisiertes Dictionary ist reine Verschwendung — in einem realen Store hielten 390K Entries ohne Labels jeweils ein leeres 80-Byte-Dictionary, etwa 31 MB an Nichts.

Die Lösung ist zweiseitig. Auf dem Heap teilen sich Entries ohne Labels ein einziges statisches leeres Dictionary, sodass Leser weiterhin eine nicht-null (leere) Map sehen, aber nichts allokiert wird. Auf der Leitung ist die serialisierte Oberfläche null, wenn es keine Labels gibt:

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

Ein Entry ohne Labels schreibt nil an Index 3, und der Leser stellt daraus „keine Labels" wieder her. Hier zeigt das Append-only-Key-Schema seinen Wert: Der Normalfall kostet ein Byte, und das Feature ist in vollem Umfang da, sobald ein Key tatsächlich ein Label braucht.

Zwei Zahlen, zwei Aufgaben: Revision und ItemVersion​

Die häufigste Verwirrung bei Zaris-Records ist, dass sie zwei monoton steigende Zahlen tragen. Sie sind nicht redundant — sie beantworten verschiedene Fragen, und sie zu vermischen würde die eine oder die andere Aufgabe brechen.

ItemVersion gilt pro Key. Sie beginnt bei 1 und wird um eins erhöht, jedes Mal, wenn dieser Key geschrieben wird. Das ist die Zahl, die der Client sieht, und die Zahl, gegen die das optimistische Compare-and-Swap prüft: „nur committen, wenn dieser Key noch auf Version 7 steht." Wenn der Store ein Put anwendet, ist die neue Version schlicht die alte Version des Keys plus eins:

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

Revision gilt pro Segment. Sie ist ein einziger Zähler, der von jedem Key der Partition geteilt und bei jedem Schreib- und Löschvorgang erhöht wird:

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

Damit ist Revision eine Totalordnung über alle Mutationen eines Segments, genau das, was Replikation und Recovery brauchen. Einer Replica ist es egal, dass der Key user:1 auf seiner 7. Version ist; ihr kommt es darauf an, welche segmentweiten Revisionen sie bereits gesehen hat, damit sie alles ab diesem Punkt anfordern kann. Das Operation-Log ist nach Revision geschlüsselt, das Catch-up-Protokoll fordert „alles nach Revision R" an, und die Konfliktauflösung zwischen einem eingehenden und einem lokalen Record vergleicht Revisionen, nicht Versionen pro Key:

// 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;

Also: ItemVersion ist die Einheit der für den Client sichtbaren optimistischen Nebenläufigkeit auf einem Key; Revision ist die Einheit der Ordnung und Konvergenz über Nodes hinweg im gesamten Segment. Derselbe Record, zwei Uhren, jede erledigt eine Aufgabe, die die andere nicht kann.

Ein Löschvorgang ist ein Record, keine Abwesenheit​

Hier ist das Feld, das die Leute am meisten überrascht: IsDeleted. Wenn Sie in Zaris einen Key löschen, entfernt der Store den Entry nicht einfach aus seinem Dictionary. Er schreibt einen StoredRecord mit IsDeleted = true — einen Tombstone —, versieht ihn mit der nächsten Segment-Revision und hängt ihn als Löschung an das Operation-Log an:

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

Der Grund ist der ganze Sinn des Record-Formats. Wäre ein Löschvorgang bloß eine Abwesenheit — der Key verschwindet stillschweigend aus einer Map —, gäbe es nichts zu replizieren. Eine Replica, die den Moment der Löschung verpasst hat, würde den alten Wert ewig weiter ausliefern, denn „nichts" reist nicht und lässt sich nicht gegen die umgebenden Schreibzugriffe ordnen. Indem die Löschung ein erstklassiger Record mit eigener Revision wird, fließt sie durch genau denselben Replikations- und Catch-up-Pfad wie ein Schreibzugriff und ordnet sich an der richtigen Stelle in die Totalordnung des Segments ein.

Tombstones schützen auch vor einem subtileren Fehler: einem wiederauferstehenden veralteten Schreibzugriff. Stellen Sie sich eine Löschung bei Revision 50 und ein älteres Put für denselben Key, Revision 48, vor, das noch im Netzwerk unterwegs ist. Ohne Gedächtnis für die Löschung würde das späte Put landen und den Key von den Toten zurückholen. Zaris merkt sich die Lösch-Revision und weist alles ab, was bei oder vor ihr liegt:

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

Die Kehrseite von Tombstones ist, dass sie sich nicht ewig ansammeln dürfen, sonst würde eine löschlastige Workload Speicher verlieren. Zaris trimmt Lösch-Revisionen, sobald sie sicher unterhalb der ältesten Revision liegen, die irgendeine Replica noch braucht — dieselbe Low-Water-Mark-Logik, die das Operation-Log trimmt —, sodass der Tombstone seine Konvergenzaufgabe erfüllt und dann zurückgewonnen wird. (Die Trimm-Disziplin ist das Thema des Operation-Log-Beitrags.)

Was zu Hause bleibt: die [IgnoreMember]-Felder​

Die beiden Felder, die der Record trägt, aber nie serialisiert, sind so bewusst gewählt wie die fünf, die er serialisiert. Beide sind mit [IgnoreMember] markiert, und beide sind node-lokal by Design — korrekt nur für den Node, der sie berechnet hat.

AccountedBytes ist der Speicher, der diesem Record im Budget des Stores angerechnet wird, einmal beim Schreiben gestempelt, damit der Store Byte-Deltas melden kann, ohne den vorherigen Record neu zu vermessen. Es wird ausdrücklich nicht serialisiert, weil jeder Node es aus dem eigenen Key und Value des Records nach seinen eigenen Bilanzierungsregeln berechnet. Würde es mitreisen, trüge ein von Node A replizierter Record die Byte-Schätzung von A in die Bücher von Node B — die Buchführung eines Nodes würde stillschweigend die eines anderen verzerren. Mit [IgnoreMember] berechnet jeder Node es unabhängig neu, und ein per Replikation oder Migration eintreffender Record wird von dem Node bilanziert, der ihn nun hält.

MaterializedValue ist eine träge aufgebaute, lebende In-Memory-Form einer nativen Collection (ein Hash, eine Liste, ein Set oder ein Sorted Set), die gecacht wird, damit Operationen auf Elementebene nicht jedes Mal den ganzen Wert neu deserialisieren müssen. Es ist reine lokale Beschleunigung. Die maßgebliche Form sind immer die gerahmten Wert-Bytes innerhalb von Entry; ein Record, der von einem anderen Node eintrifft, materialisiert diesen Cache träge beim ersten Zugriff. Ihn zu serialisieren hieße, den privaten Arbeitsspeicher eines Nodes zu versenden, als wären es Daten.

Die Disziplin hier ist eine klare, die man laut aussprechen sollte: Die Leitung trägt die Wahrheit, der Node trägt Annehmlichkeiten. Alles, was ein Node aus dem Record selbst neu berechnen kann — seine Speicherkosten, seine materialisierte Struktur —, bleibt lokal und wird mit [IgnoreMember] markiert. Alles, was zur Identität und Ordnung des Records gehört — Key, Value, Metadaten, die beiden Versionsnummern, das Tombstone-Flag —, überquert die Leitung. Die Attributgrenze ist genau die Grenze zwischen Wahrheit und Annehmlichkeit, und sie scharf zu halten macht den Record sicher kopierbar zwischen Nodes, ohne einen zweiten Gedanken.

Warum das testbar ist — und getestet wird​

Weil die Record-Form tragend für die Konvergenz ist, wird ihr Wire-Verhalten durch Tests festgenagelt statt der Inspektion überlassen. Zwei Invarianten verdienen eigene Assertions: Das Tombstone-Flag muss einen Round-Trip überleben (ein verlorenes IsDeleted lässt einen gelöschten Key auf einer Replica wiederauferstehen), und AccountedBytes muss nach einem Round-Trip als null zurückkommen (Beweis, dass es nie gereist ist):

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");

Diese lesen sich fast wie die These des ganzen Beitrags, als Assertions geschrieben: Was die Leitung überqueren muss, überlebt nachweislich; was nicht, verschwindet nachweislich.

Der Record ist der Vertrag​

Man denkt leicht, die schweren Probleme eines verteilten Stores lägen in den ausgefallenen Teilen — dem Failover-Protokoll, dem Cut-over-Handshake, dem Chaos-Testing. Das tun sie. Aber diese Protokolle sind nur so korrekt wie das, was sie bewegen, und das, was sie bewegen, ist dieser eine kleine Record. Ein Tombstone statt einer Abwesenheit ist der Grund, warum eine Löschung konvergiert. Zwei Versionsnummern sind der Grund, warum die optimistische Nebenläufigkeit eines Keys und die Ordnung eines ganzen Segments entflochten bleiben. Positionelle MessagePack-Keys sind der Grund, warum der Hot Path billig bleibt und das Format dennoch wachsen kann. Und ein Paar [IgnoreMember]-Felder ist der Grund, warum die Replikation einen Record zwischen Nodes kopieren und darauf vertrauen kann, dass nichts Node-Lokales mitgereist ist.

Bringt man die Dateneinheit in Ordnung, haben die großen Protokolle etwas Solides, worauf sie stehen können. Das ist das ganze Argument dafür, einen Blogbeitrag auf fünf Felder und zwei, die zu Hause bleiben, zu verwenden.

Hier ist ein Benchmark-Ergebnis, das wie ein Widerspruch aussieht. Ein Zaris-Node, der eine leselastige Workload bedient, erreicht seine Obergrenze bei knapp unter einer halben Million Ops/s und weigert sich zu steigen — fügen Sie mehr Client-Verbindungen und mehr Lastgeneratoren hinzu, die Zahl bewegt sich nicht. Die naheliegende Diagnose lautet „er ist gesättigt." Nur sagt das CPU-Diagramm etwas anderes: Der Node steht bei etwa einem Viertel seiner verfügbaren CPU. Drei von vier Kernen sind untätig, und der Durchsatz ist flach.

Das ist kein CPU-limitierter Node und — wenn Sie das sorgfältig ausgeschlossen haben — auch kein Client-limitierter Benchmark. Es ist eine dritte Sache, und zwar ein Klassiker: Der Worker-Pool für das Request-Dispatching war schmaler, als die Arbeit es wollte, sodass Requests in der Warteschlange standen, während Kerne Däumchen drehten.

Zuerst die üblichen Verdächtigen ausschließen​

Zwei Erklärungen müssen ausscheiden, bevor diese überhaupt auf den Tisch kommt, denn sie sind weit häufiger.

CPU-limitiert. Steht der Node bei oder nahe 100 % CPU und der Durchsatz ist flach, ist Ihnen tatsächlich die CPU ausgegangen — die Antwort sind mehr Kerne oder mehr Nodes, und Zaris skaliert Lesezugriffe durch zusätzliche Kerne. Das ist hier nicht der Fall: Die CPU ist untätig.

Client-limitiert. Ein einzelner Lastgenerator sättigt sich lange vor dem Server, und dann messen Sie Ihren Client, nicht Zaris. Ist der Durchsatz flach, während Sie Server-Kerne hinzufügen, verdächtigen Sie zuerst Ihren Client — fügen Sie Generatoren und Verbindungen hinzu, bis die Zahl auf der Serverseite tatsächlich reagiert. Wir haben diese Falle im Beitrag zum Lesen behandelt, und sie ist die, die Sie ausschließen müssen, bevor Sie weitermachen.

Was nach beiden übrig bleibt, ist der interessante Fall: genug angebotene Last, um den Node zu beschäftigen, reichlich CPU-Spielraum und trotzdem flacher Durchsatz. Wenn der Engpass im Server liegt, aber nicht die CPU ist, ist das, was man sich ansehen muss, die Nebenläufigkeit — wie viele Requests der Node gleichzeitig bearbeitet.

Der Dispatch-Pool ist das Nebenläufigkeitslimit​

Jeder Request, der an einem Zaris-Node ankommt, wird an einen Worker-Pool für das Request-Dispatching übergeben. Ein Worker nimmt den Request auf, routet ihn zur Partition, die den Key besitzt, führt die Operation gegen den In-Process-Store dieser Partition aus und schreibt die Antwort zurück. Bei einem Lesezugriff ist die Operation selbst ein Lookup im Speicher im Mikrosekundenbereich — wirklich winzig.

Die Breite dieses Pools — wie viele Worker gleichzeitig mitten in einem Request sein können — setzt eine harte Obergrenze für die Requests in Bearbeitung, und das ist eine andere Zahl als „wie schnell ist eine einzelne Operation". Der ursprüngliche Default leitete die Breite von einem kleinen Vielfachen von Environment.ProcessorCount ab. Auf einem Node mit 4 vCPUs sind zwei Mal die Kernzahl nur eine Handvoll Worker.

Hier ist die Feinheit, die das CPU-Diagramm falsch aussehen lässt. Würde jeder Worker seinen gesamten Slot damit verbringen, CPU für den Lookup zu verbrennen, wäre ein an die Kerne angepasster Pool genau richtig, und der Node würde 100 % CPU erreichen. Aber Worker verbringen nicht ihren ganzen Slot auf der CPU. Ein Worker parkt gelegentlich — eine await-Fortsetzung, ein Socket-Schreibvorgang, der nicht synchron abschließt, ein kurzer Lock auf eine gemeinsame Struktur. Ein geparkter Worker verbrennt keine CPU, aber er hält weiterhin seinen Pool-Slot. Bei nur einer Handvoll Slots genügen einige geparkte Worker, um den ganzen Node zum Stillstand zu bringen: Neue Requests stauen sich hinter ihnen, und weil die beschäftigten Worker meist warten statt zu rechnen, leuchten die Kerne nie auf. Flacher Durchsatz, untätige CPU. Die Pool-Breite war die Obergrenze, nicht das Silizium.

Das Erkennungsmerkmal, das dies von einem Client-limitierten Benchmark unterscheidet: Requests stauen sich am Server (die Latenz steigt, der Durchsatz ist flach), während die Server-CPU niedrig bleibt. Client-limitiert sieht anders aus — der Server ist untätig, weil nichts schnell genug ankommt. Hier kommt Arbeit an; der Node nimmt nur nicht genug davon gleichzeitig an.

Die Lösung: den Pool für die Arbeit dimensionieren, nicht für die Kernzahl​

Die Reparatur ist nicht exotisch. Lesezugriffe sind Lookups im Speicher im Mikrosekundenbereich, also sollte der Pool standardmäßig breit eingestellt sein — breit genug, dass eine Handvoll geparkter Worker den Node nicht aushungern kann — und er sollte abstimmbar sein, weil die richtige Breite vom Node und von der Workload abhängt, nicht von einem festen Vielfachen der Kernzahl.

Die Standardbreite des Pools beträgt jetzt CPU-Anzahl × 16, begrenzt auf ein sinnvolles Band von 64–1024, mit einer Untergrenze von max(4, CPU-Anzahl × 4). Zwei Umgebungsvariablen überschreiben sie:

# 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

Eine Eigenschaft ist hervorzuheben: Dies ist eine Änderung ausschließlich auf der Serverseite. Das Wire-Protokoll ändert sich nicht, das Client-SDK ändert sich nicht, und es gibt kein NuGet-Update, dem Sie nachlaufen müssten — Sie stimmen einen Node ab, indem Sie ihn mit einer anderen Umgebung neu starten, und jeder bestehende Client spricht unverändert weiter mit ihm.

Ehrlich abstimmen — Verbreitern ist nicht kostenlos​

Der Reflex nach der Lektüre ist, ZARIS_SERVER_MAX_WORKERS auf jedem Node bis zur Obergrenze hochzudrehen. Tun Sie das nicht. Ein breiterer Pool hilft in genau einer Situation und bewirkt in den anderen nichts — oder schadet leicht.

• Er hilft, wenn Requests sich stauen, während die CPU untätig ist. Das ist der Fall in diesem ganzen Beitrag: Die Nebenläufigkeit der Requests in Bearbeitung ist das Limit, also füllt deren stärkere Zulassung die Kerne. Hier sehen Sie den Durchsatz springen.
• Er bewirkt nichts, wenn Sie bereits CPU-limitiert sind. Steht der Node bei 100 % CPU, zaubern mehr Worker keinen Durchsatz aus dem Nichts — sie fügen einer Maschine ohne freie Zyklen nur Overhead durch Kontextwechsel hinzu. Mehr Worker sind nicht mehr Rechenleistung.
• Er kann schaden, wenn man ihn auf eine absurde Breite treibt. Tausende Worker, die einen Node mit 2 vCPUs belasten, verbringen echte Zeit mit Kontextwechseln statt mit dem Bedienen. Deshalb gibt es eine Begrenzung, und deshalb endet der Regler bei 4096 statt bei unendlich.

Die ehrliche Abstimmungsschleife lautet: Achten Sie auf die Signatur — steigende Latenz und flacher Durchsatz, während die CPU deutlich unter der Sättigung liegt —, erhöhen Sie MAX_WORKERS und messen Sie. Steigt die CPU und folgt der Durchsatz, war der Pool Ihre Obergrenze. Bewegt sich nichts, war er es nicht, und Sie sollten den Regler zurückstellen und anderswo suchen (den Netzwerkpfad, den Client oder den tatsächlichen Bedarf an mehr Nodes).

CPU dort messen, wo sie wirklich stimmt​

Diese ganze Untersuchung hängt davon ab, der CPU-Zahl zu vertrauen, und diese Zahl ist leicht falsch zu bekommen.

• Lesen Sie die CPU aus der cgroup, nicht aus einer Schätzung des Cluster-Metrics-Servers. Besonders unter Kubernetes hinkt und glättet der Wert des Metrics-Servers — er sagt Ihnen, ein Node stehe bei 40 %, obwohl die cgroup-Bilanzierung sagt, er sei am Anschlag, oder umgekehrt. Diagnostizieren Sie einen Fall „flacher Durchsatz, untätige CPU" aus der cgroup, sonst jagen Sie einer Zahl nach, die nicht real ist.
• Lokale Benchmarks sind Host-limitiert und verbergen die Obergrenze. Auf einem Laptop kämpfen Lastgenerator und Server um dieselben Kerne, sodass Sie dem Server nie saubere, ausreichende Last präsentieren — das Plateau, das Sie messen, ist Ihr Testaufbau, nicht Zaris. Die echte Worker-Pool-Obergrenze zeigte sich im großen Maßstab auf einem verwalteten Cluster mit Last von getrennten Maschinen, nicht auf einer Entwicklerkiste. Validieren Sie den Durchsatz dort, wo der Client nicht der Engpass sein kann.

Das Fazit​

Eine flache Durchsatzkurve hat drei sehr verschiedene Ursachen, und das CPU-Diagramm sagt Ihnen, welche Sie vor sich haben. Bei 100 % CPU sind Sie CPU-limitiert — fügen Sie Nodes hinzu. Ist der Server untätig, weil nichts schnell genug ankommt, sind Sie Client-limitiert — reparieren Sie den Test. Aber ein Node, der bei einem Viertel seiner CPU flach ist und bei dem sich Requests sichtbar stauen, ist keines von beidem: Es ist ein Nebenläufigkeitslimit, und bei Zaris ist das der Dispatch-Worker-Pool. Der Default ist jetzt breit genug, dass die meisten Workloads nie darauf stoßen, und ZARIS_SERVER_MAX_WORKERS gibt es für die, die es tun — um bewusst erhöht zu werden, wenn das CPU-Diagramm es sich verdient hat.

Die vollständige Oberfläche der Umgebungsvariablen und die genauen Defaults finden Sie in der Konfigurationsreferenz. Wenn Sie einen Cluster für Durchsatz dimensionieren, führt der Benchmarking-Leitfaden durch die Einstellungen, die die Zahlen tatsächlich bewegen, und Lesezugriffe, die mit Ihren Kernen skalieren behandelt die andere Hälfte der Geschichte — warum, sobald der Pool aus dem Weg ist, zusätzliche Kerne Lesekapazität hinzufügen, statt an eine Mauer mit einer einzigen Event-Loop zu stoßen.

Die meisten Gründe, in einer .NET-App zu einem verteilten Cache zu greifen, nennen den Cache gar nicht beim Namen. Sie aktivieren Output Caching, und es verlangt ein IDistributedCache. Sie aktivieren Sessions, und die Middleware will einen Backing-Store. Sie schalten das Teilen von Data-Protection-Schlüsseln über Instanzen hinweg ein, und wieder braucht es einen Ort für Bytes, den jeder Node sieht. Der Anwendungscode ist gegen eine Abstraktion geschrieben; offen ist nur, welche Implementierung Sie beim Start registrieren.

Zaris beantwortet diese Frage mit drei kleinen NuGet-Paketen, die jeweils eine bestimmte ASP.NET-Core-Nahtstelle bedienen: ein schlichtes IDistributedCache, ein zweistufiges HybridCache und ein Session-Store. Sie registrieren beim Start eine Zeile, und der Rest Ihrer App — einschließlich Drittanbieter-Bibliotheken, die nur die Abstraktion kennen — cacht auf einem Zaris-Cluster, ohne dass sich der Code ändert, der den Cache nutzt. Dieser Beitrag geht alle drei durch und ist dabei bewusst klar darüber, wo jedes ehrlicherweise endet.

Die drei Pakete​

Alle drei setzen auf demselben Zaris-.NET-Client auf. Sie erfinden keinen Seitenkanal — sie lösen aus einer Connection-String einen normalen Zaris-Client auf und übersetzen Get/Set/Remove in GetAsync/PutAsync/DeleteAsync des Clients. Wenn Sie Ein Connection-String, jede Plattform gelesen haben, wirkt die Verdrahtung vertraut: Der Cache ist nur ein weiterer Consumer eines benannten Stores.

1. Das Standard-IDistributedCache​

Das ist das Drop-in. IDistributedCache ist die Schnittstelle, die Microsoft.Extensions.Caching.Abstractions seit Jahren bereitstellt, und ein großer Teil des .NET-Ökosystems — Session, Output Caching, Auth-Ticket-Stores, Drittanbieter-Bibliotheken — hängt genau von dieser Schnittstelle ab und von nichts weiterem. Registrieren Sie Zaris als Implementierung, und all das wird von Ihrem Cluster getragen.

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

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

Die erste Zeile registriert einen Zaris-Client unter dem DI-Schlüssel app-cache; die zweite registriert ein IDistributedCache, das ihn nutzt. Von da an funktioniert alles, was ein IDistributedCache entgegennimmt — auch Code, den Sie nicht geschrieben haben:

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;
    }
}

Intern ist GetAsync ein client.GetAsync<byte[]> mit angewendetem konfiguriertem Präfix, und ein Cache-Miss (der Schlüssel existiert nicht) liefert null — genau den Vertrag, den die Schnittstelle verspricht. SetAsync mit AbsoluteExpirationRelativeToNow bildet dieses Fenster direkt auf ein Zaris-TTL ab, sodass der Store den Eintrag für Sie ablaufen lässt.

Zwei ehrliche Grenzen​

Nur die relative absolute Ablaufzeit wird abgebildet. Das Zaris-IDistributedCache liest AbsoluteExpirationRelativeToNow und macht daraus ein TTL. Setzen Sie keine Ablaufzeit, wird der Eintrag ohne TTL geschrieben und lebt, bis er per Eviction entfernt oder überschrieben wird. SlidingExpiration wird in diesem Allzweck-Cache nicht berücksichtigt — sein Refresh/RefreshAsync ist ein No-op. Das ist eine bewusste Abgrenzung, kein Versehen: Sliding Expiration ist ein Session-Thema, und das unten beschriebene Session-Paket implementiert sie ordentlich, statt sie hier halb zu implementieren.

Sie können mehr als eines registrieren, und standardmäßig gewinnt das erste. Jeder Aufruf von AddClustronDistributedCache registriert eine benannte Cache-Instanz, die an einen bestimmten Store gebunden ist. Die zuerst registrierte wird zum appweiten IDistributedCache; mit setAsDefault: true machen Sie stattdessen eine spätere Registrierung zum Default. Wenn Sie mehrere Caches auf verschiedenen Stores wollen, lösen Sie diese explizit über IClustronCacheProvider.GetCache("other-store") auf, statt sich auf den ambienten Default zu verlassen.

2. HybridCache — eine prozessinterne Stufe vor dem Cluster​

Die neuere HybridCache-Abstraktion von .NET löst ein Problem, das IDistributedCache Ihnen überlässt: die Kombination aus einem schnellen lokalen (L1) Cache und einem gemeinsamen verteilten (L2) Cache, plus Stampede-Schutz — sicherzustellen, dass nicht eine Thundering Herd gleichzeitiger Requests die teure Factory auf einmal ausführt, wenn ein beliebter Schlüssel abläuft.

Zaris implementiert die abstrakte Klasse HybridCache direkt. Der Kniff: Beide Stufen sind Zaris-Stores, die Sie benennen — L1 zeigen Sie auf einen prozessinternen Embedded-Store (kein Netzwerk, kein Serialisierungs-Hop aus der Maschine heraus) und L2 auf den verteilten Cluster:

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");

Der Lesepfad ist die klassische zweistufige Suche, und es lohnt sich, ihn vollständig zu sehen, denn jede Garantie unten ergibt sich daraus:

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" });

L1 wird zuerst ohne Lock geprüft. Bei einem Miss nimmt der Aufrufer ein Lock pro Schlüssel, prüft L1 erneut (falls ein anderer Aufrufer es gerade gefüllt hat), dann L2; nur wenn beide verfehlen, führt er die Factory aus, schreibt L2 und dann L1. Die TTLs stammen aus HybridCacheEntryOptions — Expiration für L2, LocalCacheExpiration für L1 —, und die Implementierung begrenzt L1 auf höchstens L2, sodass eine lokale Kopie die gemeinsame nie überleben kann. Ohne Optionen betragen beide standardmäßig fünf Minuten.

Stampede-Schutz, gemessen​

Das Lock pro Schlüssel ist der Stampede-Schutz. Der Test des Pakets feuert zwanzig gleichzeitige GetOrCreateAsync-Aufrufe auf einen kalten Schlüssel ab, jeweils mit einer Factory, die 100 ms schläft, und prüft, dass die Factory genau einmal lief — neunzehn Aufrufer warten auf das Lock, und der, der den Cache gefüllt hat, bedient alle. So wird ein potenzieller zwanzigfacher Hammerschlag auf Ihre Datenbank zu einem einzigen Ladevorgang.

Die ehrliche Grenze: Dieses Lock lebt in einem ConcurrentDictionary<string, SemaphoreSlim> innerhalb des Prozesses. Es bricht den Stampede innerhalb einer App-Instanz. Sind zehn App-Instanzen im selben Augenblick auf demselben Schlüssel kalt, können Sie weiterhin bis zu zehn Factory-Läufe sehen, einen je Prozess — nicht einen clusterweit. Das ist die normale Form des clientseitigen Stampede-Schutzes, und für den üblichen Fall (eine Handvoll Instanzen, eine Factory, die teuer, aber nicht katastrophal ist, ein paar Mal auszuführen) genau das, was Sie wollen. Brauchen Sie strikt einen Ladevorgang für die gesamte Flotte, ist das ein Problem für verteilte Locks, kein Cache-Feature — und eine Aufgabe, die sich besser mit dem Compare-and-Swap-Claim-Muster aus Race-freie Koordination modellieren lässt.

Tag-Invalidierung, und warum sie lazy ist​

HybridCache erlaubt es, Einträge zu taggen und eine ganze Gruppe auf einmal zu invalidieren:

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

Zaris implementiert das mit Zeitstempeln statt mit einem aktiven Sweep. Jeder Eintrag wird mit zwei Metadaten-Labels geschrieben: dem Zeitpunkt der Erstellung und seinen Tags. RemoveByTagAsync("catalog") schreibt einfach einen Schlüssel, der festhält, „catalog wurde zum Zeitpunkt T invalidiert." Beim nächsten Lesen eines getaggten Eintrags vergleicht der Cache: Wurde irgendein Tag des Eintrags nach dessen Erstellung invalidiert, wird der Eintrag als Miss behandelt, und die Factory läuft erneut. Der Test bestätigt es — Eintrag taggen, Tag invalidieren, erneut lesen, und die Factory wird ein zweites Mal aufgerufen.

Der Zielkonflikt, den Sie kennen sollten: Die Invalidierung ist lazy und lesegetriggert, kein eifriges Löschen. RemoveByTagAsync aufzurufen ist O(1) — es schreibt einen Marker und kehrt zurück —, aber die veralteten Einträge selbst bleiben im Store, bis sie jemand liest (und einen frischen Wert erhält) oder ihr TTL abläuft. Sie erhalten billige, sofortige logische Invalidierung; Sie erhalten keine sofortige Rückgewinnung des Speichers, den diese Einträge belegen. Für Cache-Daten ist das genau der richtige Handel. Verlassen Sie sich nur nicht darauf, um Daten aus Korrektheitsgründen zwangsweise zu löschen — dafür löscht RemoveAsync(key) beide Stufen ausdrücklich.

3. Sessions, mit echter Sliding Expiration​

ASP.NET-Core-Sessions brauchen einen Store, der etwas tut, was der allgemeine Cache bewusst nicht tut: die Ablaufzeit bei jedem Request, der die Session berührt, gleiten zu lassen, sodass die Session eines aktiven Benutzers ihm nie unter den Händen ablaufen, die eines inaktiven aber irgendwann schon. Das Session-Paket ist ein eigens gebautes IDistributedCache, das genau diese Semantik berücksichtigt und mit einem Aufruf eingebunden wird:

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();

Geben Sie eine Connection-String an, registriert es den Backing-Zaris-Store für Sie; lassen Sie sie weg, bindet es sich an einen Store, den Sie bereits unter StoreName registriert haben. In beiden Fällen nutzen Sie HttpContext.Session danach genau wie immer.

Entscheidend ist Refresh. Lädt die Session-Middleware eine Session, die gelesen, aber nicht verändert wurde, ruft sie RefreshAsync auf, um sie am Leben zu halten. Der Zaris-Session-Cache implementiert das als Read-then-Re-put mit einem frischen TTL in Höhe des Idle-Timeouts — jeder Request, der die Session berührt, schiebt also das 30-Minuten-Fenster weiter. Ein Schreibvorgang (SetAsync) leitet sein TTL aus der Sliding- oder absoluten Ablaufzeit des Eintrags ab und fällt auf den konfigurierten Idle-Timeout zurück. Das Ergebnis ist das übliche ASP.NET-Core-Session-Verhalten, getragen von einem Zaris-Cluster, das den Neustart einer App-Instanz übersteht, weil die Session-Daten im Store liegen und nicht im Speicher der Instanz.

Ein bewusster Implementierungshinweis aus dem Code selbst: Refresh ist ein Read-plus-Re-put statt eines nativen „setze einfach das TTL zurück"-Aufrufs. Das kostet einen zusätzlichen Roundtrip, hält das Sliding aber auf jedem Zaris-Deployment korrekt — auch dem eingebetteten prozessinternen — ohne von einem serverseitigen TTL-Reset-Primitiv abzuhängen. Korrektheit über jede Topologie hinweg schlug das Einsparen eines Roundtrips bei einer davon.

Das Richtige auswählen​

• Greifen Sie zu IDistributedCache, wenn etwas es bereits anfordert oder wenn Sie den einfachsten gemeinsamen Cache wollen und eine Bibliothek ihn für Sie nutzt. Es ist die Nahtstelle mit maximaler Kompatibilität.
• Greifen Sie zu HybridCache auf einem wirklich heißen Lesepfad, auf dem sich ein prozessinternes L1 lohnt und ein Stampede auf einen kalten, beliebten Schlüssel wehtäte. Sie zahlen mit einem zusätzlichen beweglichen Teil (zwei Stores, lokaler Speicher für L1); Sie erhalten wiederholte Lesevorgänge mit nahezu null Latenz und eine auf einen Ladevorgang je Instanz zusammengefallene Herde.
• Greifen Sie zu AddZarisSession speziell für ASP.NET-Core-Sessions — es ist das mit echter Sliding Expiration und kommt dem IDistributedCache Ihrer App nicht in die Quere.

Keines der drei verlangt, dass Sie eine cachespezifische API lernen. Sie treffen das Framework dort, wo es die Abstraktion ohnehin definiert, registrieren sich in einer Zeile und legen die Bytes auf einen Cluster, den Sie unabhängig von der App davor skalieren, absichern und auf Kubernetes betreiben können. Die beste Integration ist die, die Ihr Anwendungscode nie bemerken muss — und erfreulich oft ist das genau die, die Sie bekommen.

Ein Failover ist der Moment, in dem ein verteilter Store am ehrlichsten zeigt, was er wirklich ist. Im Normalbetrieb sehen alle Stores gleich aus: Ein Schreibvorgang landet auf einem Owner, wird bestätigt, weiter geht's. Das Design zeigt sich erst, wenn der Owner mitten im Satz verschwindet — ein Node hält die aktive Kopie einer Ihrer Partitionen, Schreibvorgänge landen gerade auf ihm, und dann ist er weg. Hart beendet. Netzwerkpartitioniert. OOM. Der Cluster hat ein paar Sekunden, um das zu bemerken, sich auf einen neuen Owner zu einigen und den Verkehr wieder fließen zu lassen — und ob er das korrekt tut, entscheidet darüber, ob Ihr bestätigter Schreibvorgang überlebt oder stillschweigend verdunstet.

Dieser Beitrag folgt dieser Abfolge von Anfang bis Ende, in der Reihenfolge, in der Zaris sie tatsächlich ausführt, und benennt die Fälle, in denen die Antwort wirklich „der Schreibvorgang ist verloren" lautet — denn ein Failover-Beitrag, der nur den Happy Path beschreibt, ist nicht lesenswert.

Die eine Invariante, die den Rest handhabbar macht​

Vor der Zeitachse die eine Designentscheidung, an der alles Weitere hängt: Zaris trennt die Partition-Map von der Partition-Runtime.

Die Partition-Map ist die langsame, bedachte Zuordnung — welche Nodes sind für Partition P zuständig: ein bevorzugter Primary und seine Replikate. Sie ändert sich nur bei echten Topologieereignissen (ein Node tritt dauerhaft bei oder aus, ein Scale-out, ein Rebalance) und über eine geplante, versionierte Neuberechnung.

Die Runtime ist die schnelle, aktuelle Antwort auf eine andere Frage — welcher zugewiesene Node ist gerade der aktive Owner, der P bedient, und in welchem Gesundheitszustand. Bei einem Failover bewegt sich die Map überhaupt nicht. Nur der Runtime-Active wechselt. Das ist die im Failover-Service selbst festgehaltene Invariante: Ein unabhängiges Ausfallsignal öffnet das Runtime-Failover-Gate, „PartitionMap remains stable and only PartitionRuntimeMap.Active is allowed to move during failover."

Warum das wichtig ist: Eine Partition-Map neu zu berechnen ist teuer und gefährlich — sie kann gesunde Partitionen umverteilen und Datenmigration auslösen. Ein sterbender Node sollte das nicht auslösen. Er sollte eine billige, lokale Runtime-Entscheidung auslösen: ein überlebendes Replikat derselben Partition auswählen und zum Active machen. Die Map sagt weiterhin „P gehört n1, n2, n3"; die Runtime wechselt von „active = n1" auf „active = n2". Dass diese beiden Ebenen getrennt bleiben, macht das Failover schnell, ohne leichtsinnig zu sein.

Schritt 1 — erkennen, aber dem ersten Gerücht nicht glauben​

Das Failover wird vom Leader koordiniert. Ein Node im Cluster ist der gewählte Leader, und nur der Leader befördert — ein Nicht-Leader, der ein Node-left-Ereignis hört, ignoriert es einfach. So wird vermieden, dass zwei Nodes unabhängig voneinander zwei verschiedene neue Owner für dieselbe Partition wählen.

Erhält der Leader ein NodeLeft-Signal für einen Node, befördert er nicht sofort Replikate für jede Partition, die dieser Node besaß. Die Promotion wird im Code als „irreversible, high-impact action" bezeichnet und ist abgesichert:

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);
}

Die Absicherung existiert, weil die Ausfall-Nachricht und die Peer-Tabelle der Mitgliedschaftsschicht asynchron aktualisiert werden. Ein NodeLeft kann einen Heartbeat vor der Peer-Tabelle eintreffen — oder schlicht falsch sein. Vor der folgenreichen Aktion prüft der Leader die Erreichbarkeit daher direkt erneut. Ein noch erreichbarer „toter" Owner bleibt genau dort, wo er ist.

Es gibt einen zweiten, langsameren Pfad für den Fall, den der erste nicht abdecken kann: ein aktiver Owner, der ohne sauberes NodeLeft verstummt ist. Ein periodischer Reconcile-Durchlauf (HandleUnavailableActiveOwnersAsync) geht jede Partition durch, und bei einem Owner, der nicht am Leben, aber nicht als ausgefallen bestätigt ist, startet er einen Verdachts-Timer, statt zu handeln:

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");

Erst nachdem der Owner das gesamte Eskalationsfenster lang (standardmäßig zehn Sekunden) unerreichbar war, bestätigt der Leader den Ausfall und fährt fort. Das Design ist bewusst asymmetrisch: Eine Partition wegen Replikatverlust als degradiert zu markieren ist billig und reversibel und erfolgt daher sofort; einen neuen Active zu befördern ist irreversibel und wartet daher auf einen Beweis.

Schritt 2 — einen Überlebenden wählen und die Epoch erhöhen​

Sobald der Owner als ausgefallen bestätigt ist, wählt der Leader ein Replikat zur Promotion. Die Auswahl ist Verfügbarkeit zuerst: Unter den zugewiesenen Replikaten der Partition bevorzugt er dasjenige, das die meisten Segmente synchronisiert hat — den Node, der am ehesten bald bedienen kann.

Die Promotion selbst ist ein einziger Broadcast, der eine Epoch je Partition erhöht:

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

Die Epoch ist das Fencing-Token und der stille Held des gesamten Mechanismus. Sie ist je Partition monoton, und der Generator weigert sich, rückwärts zu gehen — eine vorgeschlagene Epoch, die nicht strikt größer als die höchste bereits beobachtete ist, wird glatt abgelehnt:

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

Nach der Promotion ist der Active der Partition also „n2 bei Epoch 8". War der alte Owner n1 nur netzwerkpartitioniert (nicht tot) und kehrt zurück in dem Glauben, bei Epoch 7 noch der Active zu sein, verliert seine veraltete Epoch jeden Vergleich. Er kann den Besitz nicht zurückfordern, und jeder Schreibvorgang, den er als „Active" annehmen will, wird ausgesperrt. So vermeidet Zaris den Split-Brain mit zwei Primaries, bei dem ein geheilter, aber verwirrter alter Owner Schreibvorgänge annähme, die nie wieder jemand sieht.

Schritt 3 — der Possession-Proof: bedienen oder zuerst synchronisieren?​

Hier kommt der subtile Teil, an dessen Korrektheit wir ernsthaft debuggen mussten. Kann das gewählte, am meisten verfügbare Replikat tatsächlich sofort Lesevorgänge bedienen?

Nicht unbedingt — denn „die meisten Segmente synchronisiert" ist nicht dasselbe wie „hält jeden bestätigten Schlüssel". Ein Replikat kann bei der Anzahl der Segmente aufgeholt haben und dennoch bei den Daten der Segmente, die es hat, hinter der Wahrheit zurückliegen. Befördert man einen solchen Node direkt in einen bedienenden Zustand, wird er zu einem unvollständigen Active: Er antwortet NotFound auf Schlüssel, die auf dem toten Owner dauerhaft bestätigt wurden und auf einem vollständigeren Geschwister existieren. Das ist stiller Datenverlust im Gewand eines erfolgreichen Lesevorgangs.

Bevor der beförderte Node bedienen darf, wendet Zaris daher einen Possession-Proof an. Der Leader führt eine frische, zum Term passende Tabelle darüber, wie viele Schlüssel jeder Node für die Partition zu halten meldet. Die Regel ist ein reiner Vergleich:

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

Zwei Ergebnisse:

• Es existiert kein strikt vollständigerer lebender Halter — der Kandidat ist der vollständigste Node oder ein echter einziger Überlebender, ohne etwas, von dem er synchronisieren könnte. Er wird zu Degraded befördert: einem bedienenden Zustand. Er hat nichts Besseres, auf das er warten könnte, und ihn nicht bedienen zu lassen, würde die Partition nur unnötig unverfügbar machen. Er bedient sofort.
• Es existiert ein strikt vollständigerer lebender Halter — der Kandidat wird zu Recovering befördert: einem nicht bedienenden Zustand. Er synchronisiert zuerst von dieser besseren Quelle und beginnt erst zu bedienen, wenn seine Vollständigkeit erwiesen ist. Clients wird mitgeteilt, dass die Partition noch hochkommt, statt ihnen einen Node zu geben, der sie belügen würde.

Die Unterscheidung zwischen Degraded und Recovering ist genau die zwischen „die Redundanz ist reduziert, aber die Wahrheit wird bedient" und „diesem Owner für Lesevorgänge noch nicht trauen". Einen einzigen Überlebenden korrekt in Degraded zu bringen ist ebenso wichtig, wie einen unvollständigen Node in Recovering zu halten — eine einzelne verbliebene Kopie darf nie dauerhaft nicht bedienend festgenagelt werden, nur weil sie die letzte Kopie ist.

Ein Wort der Ehrlichkeit: Dieser Nachweis ist zählbasiert, gewonnen aus Berichten gehaltener Schlüssel je Node mit einer Frischegrenze (ein Bericht eines verstummten Nodes zählt nicht als lebende Quelle). Er ist ein starker, billiger Schutz davor, einen offensichtlich zurückliegenden Node zum Bedienen zu befördern; er ist keine kryptografische Bestätigung, dass zwei Nodes byte-identische Daten halten. Die Konvergenz, die die Kopien tatsächlich identisch macht, ist der Replica-Sync-Pfad, der weiter unten behandelt wird.

Schritt 4 — der Client routet um, und Ihr Retry landet​

Während all das auf dem Server geschieht: Was sieht der Client, der mitten im Schreibvorgang war?

Er sieht die Wahrheit als typisierten Status. Eine Anfrage, die den alten Owner erreicht (jetzt gefenct oder schlicht weg), hängt nicht und wirft keinen vagen Fehler — sie kommt als Moved oder OwnershipChanging zurück. Der Zaris-Client behandelt diese als wiederholbare Reroute-Signale: Er aktualisiert seine Ownership-Map, entdeckt den neuen Active und spielt die Operation dort erneut ab. Im Normalfall dauert Ihr PutAsync einfach ein paar Millisekunden länger und liefert Ok — gegen den neu beförderten Owner, bei der neuen Epoch. Der Anwendungscode erfährt nie, dass der Owner gewechselt hat.

Diese Client-Mechanik — die Status-Taxonomie, der Retry mit Versuchsbudget und Deadline, die Map-Aktualisierung — ist eine eigene Geschichte, erzählt in Retries, die Sie nicht schreiben müssen. Für diesen Beitrag zählt nur, dass die Epoch-Erhöhung des Servers und das Reroute des Clients zwei Hälften einer Übergabe sind: Der Server macht den alten Owner nicht mehr maßgeblich, und der Client hört auf, mit ihm zu sprechen.

Schritt 5 — konvergieren, dann zurück auf Healthy heilen​

Die Promotion stellt die Verfügbarkeit wieder her, nicht die Redundanz. Direkt nach einem Failover läuft die Partition als Degraded mit einer Kopie weniger als ihr Ziel. Danach geschehen im Hintergrund zwei Dinge.

Erstens holen der beförderte Node (falls er als Recovering hochkam) und alle zurückliegenden oder zurückkehrenden Replikate auf, indem sie das Operations-Log je Segment ab einer bekannten Revision erneut abspielen — dasselbe wiederabspielbare Substrat, das die gewöhnliche Replikation antreibt. Ein Node, der gerade die Active-Rolle geerbt hat, und ein Replikat, das lediglich zurückgefallen ist, konvergieren über denselben Mechanismus; das ist das Thema von One Log, Two Jobs.

Zweitens überführt der Recovery-Durchlauf des Leaders die Partition zurück nach Healthy, sobald jeder zugewiesene Teilnehmer wieder lebt und synchron ist — aber nur über denselben Epoch-erhöhenden Broadcast und erst nach einer kurzen Abkühlzeit, damit ein flatternder Node die Runtime nicht durch einen Sturm von Übergängen treiben kann. Der Gesundheits-Zustandsautomat ist somit eine kleine, geschlossene Schleife: Healthy → Degraded/Recovering → Healthy, jede Kante eine Epoch-Erhöhung, jede Promotion gefenct.

Überlebt gar kein geeignetes Replikat — ist jeder zugewiesene Node der Partition ausgefallen —, tut der Leader das einzig Ehrliche: Er markiert die Partition als Unavailable (kein Owner, keine falsche Promotion) und startet einen Eviction-Countdown, der, falls niemand rechtzeitig zurückkehrt, eine geplante Map-Neuberechnung die Partition neu verorten lässt. Eine Unavailable-Partition lässt Lese- und Schreibvorgänge laut scheitern, statt eine Lüge zu bedienen.

Wo ein Schreibvorgang tatsächlich verloren geht — klar benannt​

Ein Failover-Mechanismus verdient Vertrauen, indem er seine Grenzen präzise benennt, nicht indem er andeutet, es gäbe keine.

• Replikationsfaktor 1. Eine Partition mit einer einzigen Kopie und ohne Replikat hat nichts, was sie befördern könnte. Stirbt dieser Node, wird die Partition Unavailable, bis er zurückkehrt; die Daten sind nicht verloren (sie liegen im Speicher dieses Nodes), aber nicht verfügbar, und kehrt der Node nie zurück, sind sie weg. RF1 ist konstruktionsbedingt nicht dauerhaft — eine bewusste Wahl für Daten, die Sie sich leisten können zu verlieren, keine Garantie, die der Failover-Pfad retten könnte.
• Asynchrone Bestätigung. Zaris erlaubt, einen Schreibvorgang auf dem aktiven Owner zu bestätigen, bevor er ein Replikat erreicht hat — für die Latenz. Das ist der schnelle Pfad, und sein ehrlicher Preis ist ein Fenster: Stirbt der Active in der Lücke zwischen der Bestätigung gegenüber dem Client und dem Eintreffen der Operation bei irgendeinem überlebenden Halter, ist dieser bestätigte Schreibvorgang verloren. Der Possession-Proof schützt davor, einen bekanntermaßen zurückliegenden Node zum Bedienen zu befördern; er kann keine Operation herbeizaubern, die den toten Node nie verlassen hat. Muss ein Schreibvorgang den Verlust seines Owners überleben, darf er erst bestätigt werden, nachdem er auf einem Replikat dauerhaft ist — der synchrone Pfad tauscht ein wenig Latenz genau gegen diese Garantie. Wählen Sie pro Workload, mit offenen Augen.
• Das Bestätigungsfenster selbst. Während des Eskalations-Timeouts, nachdem ein Owner verstummt ist, befinden sich die Schreibvorgänge der Partition in der Schwebe — vom Client wiederholt, aber noch nicht auf einem neuen Owner gelandet. Die Korrektheit bleibt gewahrt (nichts wird fälschlich befördert), aber die Verfügbarkeit sinkt für dieses Fenster. Den Timeout zu verkürzen tauscht schnelleres Failover gegen mehr Fehlpromotions bei vorübergehenden Aussetzern; es ist ein Regler, kein Gratis-Mittagessen.

Nichts davon sind Bugs, die der Failover-Pfad wegkonstruieren könnte — es sind die echten Zielkonflikte zwischen Verfügbarkeit, Langlebigkeit und Latenz, und Zaris' Aufgabe ist es, die sichere Wahl zum Default und die schnelle Wahl explizit zu machen, ohne je so zu tun, als gäbe es das Fenster nicht.

Das Gesamtbild​

Reduziert man das Failover, sind es vier Züge auf einer Invariante. Die Invariante: Die Map bleibt stehen; nur der Runtime-Active bewegt sich. Die Züge: den Tod bestätigen, bevor man darauf reagiert, einen Überlebenden hinter einer monotonen Epoch befördern, die den alten Owner aussperrt, den Besitz nachweisen, sodass der neue Owner die Wahrheit bedient oder erst synchronisiert, bevor er überhaupt bedient, und den Client umleiten, sodass sein Retry beim neuen Owner landet. Dann die Kopien wieder konvergieren lassen und auf Healthy heilen.

Dass das hält, ist keine Frage der Argumentation — es wird gemessen. Derselbe Promotion-, Possession- und Konvergenzpfad läuft stundenlang kontinuierlich unter gezieltem Node-Kill-Chaos, und am Ende wird das Ledger auf einen einzigen verlorenen bestätigten Schreibvorgang geprüft. Diese Zertifizierung ist eine eigene Geschichte: Kein bestätigter Schreibvorgang bleibt zurück.

Der Großteil dieses Blogs ist jeweils tief in ein einzelnes Thema eingestiegen — Compare-and-Swap, Multi-Key-Transaktionen, native Datenstrukturen, Streams, Watch, das darunterliegende Op-Log. Jeder Beitrag beantwortet „wie funktioniert dies". Dieser beantwortet eine andere, praktischere Frage: Wonach greifen Sie, wenn ein Problem vor Ihnen liegt?

Diese Frage ist wichtig, weil die falsche Wahl selten ein Absturz ist. Es ist ein System, das in der Demo funktioniert und dann unter Last ein Update verliert, tausend Schreiber durch einen Schlüssel schleust oder eine Fire-and-Forget-Benachrichtigung nutzt, wo ein dauerhaftes Log nötig war. Die Primitive hindern Sie nicht daran, sie falsch zu benutzen. Dies ist also ein Feldführer: das mentale Modell, das sie verbindet, eine Entscheidungstabelle, ein Gang durch jeden Zweig mit ehrlicher Eignung und ehrlicher Grenze und am Ende ein Flussdiagramm.

Ein Kern, viele Views​

Beginnen wir mit dem, worauf alles andere aufbaut. Unter jedem Feature in diesem Beitrag ist Zaris ein einziger partitionierter, replizierter Key/Value-Store, und jeder Wert trägt eine vom Store verwaltete monotone Version. Das ist alles. Das ist der Kern.

Alles andere ist eines von zwei Dingen:

• Eine typisierte, serverseitige View über Schlüssel — ein Hash, eine Liste, ein Set, ein Sorted Set, ein Stream. Das sind keine Blobs, die Sie abrufen und in Ihrem Prozess verändern; es sind echte serverseitige Collections, die auf der Partition liegen, die ihren Schlüssel besitzt, und sie replizieren genau wie ein einfacher Wert.
• Eine Koordinations-Schicht über der Version — Compare-and-Swap, Multi-Key-Transaktionen, Locks, Watch. Sie nutzen die Version (und die Ownership-Mechanik darum herum), damit viele Clients sich darauf einigen können, was passiert ist, ohne sich auf die Füße zu treten.

Behalten Sie dieses Bild im Kopf, und die gesamte Oberfläche wirkt nicht mehr wie ein Sammelsurium von Features, sondern wie das, was sie ist: ein kleiner Kern und eine Reihe gezielt gebauter Werkzeuge, die jeweils eine bestimmte Problemklasse darauf lösen. Wählen Sie nach der Form Ihres Problems, nicht nach dem Namen, der am ehesten passt.

Die Entscheidungstabelle​

Der Rest dieses Beitrags ist diese Tabelle in Zeitlupe.

KV und Cache: wenn ein Wert nur ein Wert ist​

Müssen Sie lediglich Bytes irgendwo ablegen, wo jeder Node sie lesen kann — ein gerendertes Fragment, ein serialisiertes DTO, einen Konfigurations-Snapshot —, brauchen Sie keine Koordinationsschicht. PutAsync(key, value) und GetAsync<T>(key) sind die ganze Geschichte, und serverseitig werden diese Bytes für Sie partitioniert und repliziert.

Zwei ehrliche Hinweise. Erstens: Der Ablauf wird nicht beim Schreiben gesetzt. Die Schreiboptionen haben kein TTL-Feld; ein Time-to-Live setzen Sie mit einem separaten Aufruf — ExpireAsync(key, ttl) —, entfernen es mit PersistAsync(key) oder lesen den Rest mit GetTimeToLiveAsync(key). Zweitens: Ist Ihr Anwendungsfall buchstäblich „ein verteilter Cache für meine ASP.NET-Core-App", bauen Sie nichts davon selbst: Registrieren Sie eines der Drop-in-Cache-Pakete, und das IDistributedCache des Frameworks (oder HybridCache oder der Session-Store) wird von Ihrem Cluster getragen — mit einer einzeiligen Änderung beim Start und ohne dass Code die Cache-Abstraktion berührt.

Greifen Sie zu einfachem KV, wenn der Wert keine Nebenläufigkeits-Invariante hat — Last-Writer-Wins ist in Ordnung, oder es gibt immer nur einen Schreiber. Tun Sie es nicht, sobald zwei Schreiber um denselben Schlüssel konkurrieren können und es Sie stören würde, wenn einer den anderen stillschweigend überschreibt. Das ist die Aufgabe des nächsten Werkzeugs.

Compare-and-Swap: wenn ein Wert unter Nebenläufigkeit korrekt bleiben muss​

Ein Zähler mit Obergrenze, ein Kontostand, der nicht negativ werden darf, ein Konfigurationsobjekt, das zwei Admins gleichzeitig bearbeiten. Der Fehler, den Sie vermeiden wollen, ist das Lost Update — lesen, lesen, schreiben, schreiben, und der zweite Schreibvorgang löscht den ersten. CAS macht aus diesem stillen Verlust einen erkannten, wiederholbaren Konflikt: einen Wert samt Version lesen, nur zurückschreiben, wenn sich die Version nicht bewegt hat, und ein Conflict erhalten statt eines Überschreibens, wenn Ihnen jemand zuvorkam.

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

Das ist der gesamte Mechanismus, und der CAS-Feldführer zeigt, wie weit er trägt — ein Rate Limiter, ein Wallet, das unter tausend gleichzeitigen Abbuchungen nie überzogen wird, ein Job-Claim mit nur einem Gewinner (über „nur erstellen, wenn nicht vorhanden"), Konfiguration ohne Lost Updates und der Idempotenz-Haken, der gratis mitläuft.

Greifen Sie zu CAS, wenn die Invariante auf einem Schlüssel liegt und Sie Korrektheit ohne gehaltenes Lock wollen. Richten Sie nicht eine Menge Schreiber auf einen einzelnen heißen Schlüssel und erwarten Sie nicht, dass das skaliert — CAS lässt bewusst pro Runde genau einen Schreiber gewinnen, ein heißer Schlüssel wird also zum Serialisierungspunkt. Sharden Sie ihn (ein Bucket pro Client-Sekunde, ein in abgeglichene Teilguthaben zerlegter Kontostand), und die Contention schmilzt.

Multi-Key-Transaktionen: wenn die Invariante Schlüssel überspannt​

Die harte Linie, die CAS zieht, ist, dass es auf einem Schlüssel atomar ist. Geld von Konto A auf Konto B übertragen oder einen Sekundärindex im Gleichschritt mit dem Datensatz halten, auf den er zeigt — kein einzelnes Compare-and-Swap deckt beides ab. Das ist kein Grund, es mit zwei CAS-Schreibvorgängen vorzutäuschen und zu hoffen — es ist genau der Fall, für den die Multi-Key-Transaktion existiert.

Sie öffnen eine Transaktion, stagen Lese- und Schreibvorgänge hinein und committen. Intern ist es ein vom Client koordiniertes Two-Phase-Commit über optimistische Versionen: Die Schlüssel können auf verschiedenen Nodes liegen, der Client gruppiert das Write-Set also nach Owner, jeder Node prüft, dass jeder von Ihnen gelesene Schlüssel noch auf der gelesenen Version steht, und nimmt ein kurzlebiges Lock; nur wenn alle mit Ja stimmen, wird das gesamte Set angewendet. Hat sich irgendeine Version bewegt, liefert der Commit Conflict, und nichts ist verändert.

Greifen Sie zu einer Transaktion, wenn zwei oder mehr Schlüssel gemeinsam oder gar nicht wechseln müssen. Nutzen Sie sie nicht als Standard-Schreibpfad — sie ist ein echtes 2PC mit Prepare-/Commit-Roundtrips und kurzlebigen Locks, schwerer als ein einzelnes CAS. Passt die Invariante ehrlich auf einen Schlüssel, lassen Sie sie auf einem Schlüssel.

Native Datenstrukturen: wenn die Daten eine Collection sind​

Manchmal ist der Wert kein Skalar, den Sie schützen, sondern eine Form. Ein Benutzerprofil ist eine Map von Feldern. Ein Feed jüngster Aktivitäten ist eine Liste. Eine Tag-Mitgliedschaft ist ein Set. Eine Bestenliste ist ein Ranking. Sie könnten jedes als einen Blob serialisieren und per CAS absichern, aber dann schreibt jede Einzelfeld-Änderung das gesamte Objekt neu, und aus einem O(1)-Update wird ein O(n)-Update.

Zaris gibt diesen eigene native, serverseitige Collection-Typen — Hashes, Listen, Sets, Sorted Sets —, bei denen eine Operation auf einem Feld oder Element nur dieses Element auf dem Server berührt, nicht den gesamten Wert in Ihrem Prozess. Sie werden wie jeder Schlüssel partitioniert und repliziert, und weil das RESP-Frontend dieselben Redis-Befehle auf dieselben serverseitigen Collections abbildet, berühren ein .NET-Service und ein Python-Service, die HSET nutzen, denselben Hash.

Greifen Sie zu einer Collection, wenn Ihr Zugriffsmuster elementweise ist — ein Feld setzen, einen Eintrag pushen, eine Mitgliedschaft prüfen, die Top N nach Score lesen. Greifen Sie nicht zu einem Sorted Set, wenn Sie eigentlich ein geordnetes, bestätigtes, wiederabspielbares Event-Log brauchen. Das ist ein Stream.

Streams: wenn Sie ein geordnetes, wiederabspielbares Log brauchen​

Eine Queue und ein Log sehen ähnlich aus, bis ein Consumer abstürzt. Zaris-Streams sind ein echtes Append-only-Log: Einträge erhalten monotone IDs, Sie können Bereiche lesen, und eine Consumer Group verteilt das Log auf einen Pool von Workern, verfolgt die Pending-Einträge jedes Workers (zugestellt, aber nicht bestätigt) und lässt einen anderen Worker übernehmen, was ein abgestürzter nie bestätigt hat. Diese Pending-und-Ack-Mechanik liefert At-least-once-Zustellung — das, was eine Fire-and-Forget-Benachrichtigung nicht leisten kann.

Greifen Sie zu einem Stream, wenn Sie dauerhafte, geordnete, wiederabspielbare Events mit expliziter Bestätigung und Arbeitsteilung brauchen — Order-Ingestion, ein Outbox-Pattern, ein Audit-Trail, aus dem sich eine Projektion neu aufbaut. Nutzen Sie ihn nicht als Prioritäts-Queue oder Request/Response-Kanal; er ist ein Log, und seine Stärken sind Ordnung und Replay, nicht Routing.

Watch, Benachrichtigungen und die Fan-out-Familie: wenn Sie auf Änderungen reagieren​

Es gibt mehrere Wege zu erfahren, dass sich etwas geändert hat, und sie sind nicht austauschbar — der Unterschied liegt darin, ob das Signal dauerhaft ist.

Der Weg aus .NET ist Watch: ein nativer, clusterweiter Change Feed. Sie abonnieren einen Schlüssel oder ein Präfix, binden optional einen initialen Snapshot ein, damit zwischen „aktuellen Zustand lesen" und „Änderungen abonnieren" keine Lücke entsteht, und erhalten Events, sobald Schreibvorgänge landen:

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

Die wichtige Eigenschaft ist, dass der Watch clusterweit registriert ist und Failover übersteht — er ist nicht an den einen Node gebunden, der zufällig einen Schreibvorgang verarbeitet hat. Deshalb sind die Redis-Keyspace-Benachrichtigungen, die Zaris spricht (__keyevent@0__ / __keyspace@0__, ein einfaches PSUBSCRIBE von jedem Redis-Client), hier mehr wert als auf einer einzelnen Redis-Box: Sie sind eine dünne Brücke auf denselben replizierten Watch, sodass ein Failover den Event-Strom nicht stillschweigend abreißen lässt.

Greifen Sie zu Watch/Keyspace-Benachrichtigungen, wenn Sie auf Zustandsänderungen reagieren wollen — einen Cache invalidieren, einen Worker wecken, eine Projektion aktualisieren. Verwechseln Sie einfaches Best-Effort-Pub/Sub-Fan-out nicht mit einem dauerhaften Feed: Brauchen Sie jedes Event auch über Abstürze und Neustarts hinweg, ist das ein Stream, keine Benachrichtigung.

Locks: grober gegenseitiger Ausschluss, mit einem scharfen Vorbehalt​

Zaris hat tatsächlich einen erstklassigen verteilten Lock — ein benanntes, Lease-basiertes Gate mit TTL, vom Client erworben und beim Dispose oder bei Ablauf nach einem Absturz freigegeben:

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

Er ist wirklich nützlich für groben gegenseitigen Ausschluss — verhindern, dass zwei Scheduler denselben Sweep ausführen, einen Wartungstask serialisieren —, und das TTL sorgt dafür, dass ein abgestürzter Halter den Lock nicht für immer blockiert.

Doch hier ist der Vorbehalt, den die glänzende Version weglässt, und es ist der wichtigste Satz dieses Beitrags über Locks: Ein Lease-basierter Lock ist kein Korrektheits-Fence. Pausiert Ihr Halter — ein GC-Stall, ein langsamer Syscall — lange genug, dass die Lease abläuft, kann ein zweiter Halter denselben Lock erwerben, während der erste noch glaubt, ihn zu halten, und nun befinden sich zwei Worker gleichzeitig im kritischen Abschnitt. Für Liveness und Effizienz (meist läuft nur ein Worker den Job, geringe Contention) ist ein Lease-Lock genau richtig. Für eine Korrektheits-Invariante, die nie verletzt werden darf, verlassen Sie sich nicht darauf, dass der Lock sie durchsetzt — setzen Sie sie auf den Daten durch, mit Compare-and-Swap oder einer Transaktion, damit selbst ein irrtümlicher zweiter Akteur beim Schreiben durch eine Versionsprüfung abgewiesen wird.

Greifen Sie zu einem Lock, wenn Sie groben Best-Effort-gegenseitigen-Ausschluss wollen und gelegentliche Überlappung lediglich verschwenderisch, nicht falsch ist. Greifen Sie stattdessen zu CAS, wenn Überlappung Daten beschädigen würde — lassen Sie die Version, nicht den Lock, das Nein sagen.

Der übergreifende Teil: Ownership, Langlebigkeit, Konsistenz​

Drei Eigenschaften gelten für jedes obige Primitiv, weil sie Eigenschaften des Kerns sind, nicht eines einzelnen Werkzeugs:

• Der Owner wechselt, und Sie müssen es nicht bemerken. Jeder Schlüssel gehört einer Partition, die per Failover wechseln, migrieren oder zurückfallen kann. Der .NET-Client macht aus diesem Churn ein typisiertes, wiederholbares Signal und routet zum neuen Owner um, begrenzt durch ein Versuchsbudget und eine Wanduhr-Deadline — ein PutAsync während eines Failovers dauert also meist nur ein paar Millisekunden länger und liefert Erfolg.
• Langlebigkeit entsteht durch Replikation, nicht durch Festplatte. Zaris hält Daten im Speicher und macht sie dauerhaft, indem es Kopien auf anderen Nodes hält. Deshalb ist der Replikationsfaktor nicht dasselbe wie Fehlertoleranz: Die Zahl schützt Sie nur, wenn die Topologie tatsächlich eine zweite Kopie auf einem Node platziert, der den Verlust des ersten überleben kann. Das gesamte Ownership-und-Recovery-Fundament existiert, damit kein bestätigter Schreibvorgang verloren geht, während der Besitz in Bewegung ist.
• Schreib- und Lesevorgänge werden zum aktuellen Owner geroutet. Die Retry-und-Reroute-Mechanik sorgt dafür, dass Ihre Operationen den Node finden, der den Schlüssel gerade besitzt, sodass ein Lesevorgang einem committeten Schreibvorgang folgt, statt dem soeben erfolgten Ownership-Wechsel vorauszueilen.

Nichts davon ist ein Primitiv, das Sie wählen. Es ist der Boden, auf dem jede Wahl steht.

Das Flussdiagramm​

Die Kurzfassung​

Die Länge der Feature-Liste war nie der Punkt. Zaris ist ein versionierter, partitionierter, replizierter Key/Value-Kern, plus typisierte serverseitige Views (Hash, Liste, Set, Sorted Set, Stream) und Koordinationsschichten über der Version (CAS, Transaktionen, Locks, Watch). Ordnen Sie das Werkzeug der Form des Problems zu: Ein Skalar unter Contention will CAS; eine schlüsselübergreifende Invariante will eine Transaktion; Daten, die eine Collection sind, wollen die passende Collection; dauerhafte geordnete Events wollen einen Stream; auf Änderungen zu reagieren will Watch; grober gegenseitiger Ausschluss will einen Lock — und alles, was nie verletzt werden darf, will seine Garantie auf den Daten durchgesetzt haben, mit einer Versionsprüfung, nicht auf einem Lock, der verfallen kann.

Wählen Sie nach der Form, verlassen Sie sich für die Korrektheit auf die Version, und der kleine Kern trägt erstaunlich viel System.

Das meiste, was man über einen Datenspeicher liest, handelt vom Datenpfad — Lese- und Schreibvorgänge, das Wire-Protokoll, wie schnell es ist. Doch bevor das alles zählt, muss jemand das Ding aufsetzen: entscheiden, wie viele Partitionen es hat, wie viele Kopien jeder davon, wo die Ports liegen, es starten, bestätigen, dass es gesund hochgekommen ist, und es im Betrieb beobachten. Das ist die Steuerungsebene, und in Zaris lebt sie in PowerShell.

Dies ist eine Day-one-Anleitung für Operatoren. Wir legen einen Workspace an, stellen einen Store bereit, starten ihn und lesen dann seinen Live-Zustand zurück — alles aus dem Modul AdminShell. Keine Web-Konsole nötig, nichts von Hand bearbeitet. Und weil bei einer Operator-Geschichte Vertrauen der ganze Punkt ist, benennen wir klar die Entscheidungen, die New-ZrStore Ihnen vorlegt, und was jede tatsächlich kostet.

Zwei Shells, zwei Ebenen​

Zaris liefert seine Kommandozeilenoberfläche als zwei getrennte PowerShell-Module, und die Trennung ist nicht kosmetisch — sie spiegelt die beiden Ebenen des Systems:

• AdminShell ist die Steuerungsebene. Ihre Cmdlets stellen Stores bereit, starten, stoppen, inspizieren und skalieren sie. Sie sprechen mit dem Zaris-Management Service (dem „Manager"), nicht direkt mit den Datenknoten. Das sind die Verben New-ZrStore, Get-ZrNode, Watch-ZrStoreMetrics.
• ClientShell ist die Datenebene. Ihre Cmdlets — Connect-ZrStore, Get-ZrItem, Set-ZrItem — öffnen eine Verbindung direkt zu den Nodes des Stores und bewegen Key/Value-Daten. Das ist die Oberfläche, die eine Anwendung nutzt, und das Thema des Beitrags zu Connection-Strings.

Ein Operator, der einen Cluster aufsetzt, lebt fast ausschließlich in AdminShell. Der Manager, mit dem sie spricht, ist die Komponente, die die gewünschte Form jedes Stores kennt und die realen Prozesse darauf zutreibt. Das Erste ist also, Ihrer Shell zu sagen, mit welchen Managern sie sprechen soll.

Schritt 0 — ein Workspace als Ziel​

Ein Workspace ist eine benannte Menge von Managern, auf die Admin-Cmdlets zielen, und wird unter ~/.clustron persistiert, sodass er Sitzungen überdauert. Sie legen ihn einmal an und wechseln in ihn, wann immer Sie eine Shell öffnen:

# 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

Jeder Manager-Endpunkt ist ein Beobachter eines Clusters — listen Sie alle auf, und die Admin-Cmdlets aggregieren den Zustand über den gesamten Cluster, statt über das, was eine einzelne Maschine zufällig weiß. Ist in Ihrem Cluster Security aktiviert, hinterlegen Sie ein Admin-Token im Workspace (-Token) oder authentifizieren die Sitzung mit Connect-ZrManager -Credential (Get-Credential) -Force, das Benutzername und Passwort gegen ein Sitzungs-Token tauscht. (Connect-ZrManager ist das ältere Ad-hoc-Connect und funktioniert weiterhin, aber die Workspace-Cmdlets sind der aktuelle Weg — auf sie bilden sich die gespeicherten Workspaces der Web-Konsole ab.)

Eine ehrliche Weggabelung: Die folgende Anleitung folgt dem Supervisor-Modell, bei dem jeder Manager seine lokalen Zaris-Prozesse forkt und besitzt — das native Windows-Deployment. Laufen Ihre Nodes stattdessen unter einem Orchestrator wie Kubernetes (das Attach-Modell), erstellt der Manager keine Prozesse; Sie definieren den Store mit Ihrem Orchestrator und übernehmen ihn mit Register-ZrStore statt New-ZrStore. New-ZrStore erkennt einen Manager im Attach-Modus und sagt es Ihnen, statt tief im Stack zu scheitern.

Schritt 1 — den Store bereitstellen​

Dies ist das Cmdlet mit den echten Entscheidungen. Die minimale Produktionsform ist kurz:

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

Das erstellt einen Store namens orders über alle Maschinen im Workspace, mit zwei Kopien jeder Partition. Vier Parameter tragen das Gewicht, also seien wir bei jedem präzise.

-ReplicationFactor ist die Gesamtzahl der Kopien jeder Partition — Primary plus Replikate. In der Produktion darf er höchstens der Anzahl der Maschinen entsprechen, damit jede Kopie auf einer anderen Maschine liegt; das macht aus ihm Fehlertoleranz statt Dekoration. Auf einer einzelnen Dev-Box wird die Einschränkung mit einer Warnung gelockert — Replikate teilen sich eine Maschine, was zum Testen in Ordnung ist und bei einem echten Ausfall nichts bringt. Das Cmdlet sagt das laut, statt Sie etwas anderes glauben zu lassen.

-PartitionsPerNode ist standardmäßig 1, die Produktionstopologie. Die Gesamtzahl der Partitionen wird aus der aktuellen Cluster-Mitgliedschaft abgeleitet — PartitionsPerNode × live nodes — und bei jeder Mitgliedschaftsänderung neu berechnet, ist also keine Zahl, die Sie bei der Erstellung einfrieren. Sie erhöhen sie über 1 hauptsächlich für lokale Tests, wenn Sie partitionsbewusstes Verhalten (Segment-Routing, Rebalance beim Scale-out) auf einer einzelnen Maschine beobachten wollen, ohne ein Rack aufzubauen.

-BaseClusterPort / -BaseClientPort sind die ersten Ports zweier Bereiche: der interne Gossip-/Cluster-Port und der clientseitige Port, pro Prozess auf jeder Maschine um eins erhöht. Das Cmdlet prüft, dass sich die beiden Bereiche nicht überschneiden, und weigert sich, einen Store zu erstellen, der mit sich selbst kollidieren würde — ein kleiner Schutz, der einen verwirrenden Fehlstart erspart.

Drei weitere sind erwähnenswert, weil sie einen echten Zielkonflikt bei der Dauerhaftigkeit abbilden:

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

• -ReplicationMode ist standardmäßig Async: Der Primary schreibt lokal und kehrt sofort zurück, die Replikation läuft im Hintergrund. Das ist die schnellste Option und der richtige Default für einen Cache — aber machen Sie sich klar, dass ein unter Async bestätigter Schreibvorgang noch nicht garantiert auf einem Replikat liegt. Wählen Sie Sync, wartet der Primary auf die Bestätigung der Replikate, bevor er Ok liefert, und tauscht Latenz gegen Dauerhaftigkeit.
• -WriteQuorumPolicy greift nur unter Sync: All (jedes Replikat muss bestätigen), Majority (floor(RF/2)+1 müssen bestätigen) oder BestEffort (Fehler werden protokolliert, lassen den Schreibvorgang aber nicht scheitern).
• -AllowReplicaReads erlaubt Clients, von Replikat-Nodes zu lesen, um die Leselast zu verteilen — mit dem ehrlichen Vorbehalt, dass ein Replikat-Lesevorgang leicht veraltete Daten liefern kann, weil ein Replikat dem Primary hinterherhinken kann. Lassen Sie es aus, wenn Sie Read-your-writes brauchen; schalten Sie es ein, wenn Sie lieber den Durchsatz hätten und den Lag tolerieren.

Beachten Sie, was die Defaults über Zaris' Haltung sagen: Async + Lesen vom Primary ist ein schneller, standardmäßig korrekter Cache. Die Dauerhaftigkeits-Regler sind da, wenn Sie sie brauchen, klar benannt, jeweils mit sichtbaren Kosten.

Schritt 2 — starten und bestätigen, dass er hochgekommen ist​

Das Erstellen eines Stores definiert seine Form; es führt die Prozesse nicht aus. Start-ZrStore zählt die Instanzen des Stores auf jedem Manager auf und startet sie, wobei Erfolg oder Misserfolg pro Instanz gemeldet wird:

Start-ZrStore -Name "orders"

Nun der Teil, der einen Operator von jemandem unterscheidet, der einen Befehl ausführte und hoffte. Get-ZrStore liest den Live-Zustand des Stores von den Managern zurück — Gesamtstatus, Uptime und den Laufzustand jedes Nodes:

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

Der Store-Status ist eine Zusammenfassung: Running, wenn jeder Node läuft, Stopped, wenn alle ausgefallen sind, und Partial, wenn manche laufen und manche nicht — genau der Zustand, den Sie laut angezeigt haben wollen, denn ein Partial-Store ist einer, der ungleichmäßig gestartet ist. Die Uptime ist bewusst die vom Kern gemeldete Cluster-Bildungszeit — der früheste Node-Start, der den Churn überlebt hat —, nicht der älteste aktuell laufende Prozess, damit ein Store, der seit Stunden bedient, nicht „ein paar Minuten" meldet, nur weil ein Node neu gestartet wurde.

Für die nächste Ebene darunter zeigt Get-ZrNode Rollen und die Partition-Map:

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

Die Spalte Primary/Replica zeigt, wer gerade jede Partition besitzt, und v7 ist die Version der Partition-Map — die Generationsnummer der Ownership-Map. Stimmen alle Nodes in derselben Map-Version überein, ist der Besitz konvergiert; ein Node, der auf einer älteren Version festhängt, hat die jüngste Umverteilung noch nicht eingeholt. Fragen Sie einen einzelnen Node nach Details (Get-ZrNode orders 10.0.0.10-n0), erweitert sich das auf die exakten Primary- und Replikat-Partitions-IDs, die er hält, und wann sich seine Rolle zuletzt änderte — die Ansicht, zu der Sie greifen, wenn gerade ein Failover stattgefunden hat und Sie wissen wollen, wo der Besitz gelandet ist.

Schritt 3 — im Betrieb beobachten​

Ein Snapshot sagt Ihnen, dass der Store läuft. Eine Live-Ansicht sagt Ihnen, was er tut. Watch-ZrStoreMetrics fragt die Manager ab und zeichnet in einem Intervall eine Tabelle pro Node neu, bis Sie abbrechen:

Watch-ZrStoreMetrics -StoreName orders -RefreshSec 2

Sie legt zuerst die alltäglichen Zähler aus — Request-Rate, Gets, Puts, Deletes, Item-Anzahl, Speicherverbrauch — und schiebt die erweiterten Replikations- und Sync-Diagnosen nach unten, sodass die Zahlen, die Sie auf einen Blick prüfen, oben stehen. Fehlerzähler werden rot, sobald ihre Rate über null steigt; der Durchsatz färbt sich grüner, je höher er steigt. Sie hebt auch Rollenwechsel inline hervor: Kippt ein Failover einen Primary zu einem Replikat, während Sie zusehen, wird eine Zeile [ROLE CHANGE] mit Zeitstempel ausgegeben — das Live-Signal, dass eine Partition gerade den Besitzer gewechselt hat.

Ein bewusstes Detail, das es wert ist, genannt zu werden, weil es ein Werkzeug um 2 Uhr nachts benutzbar macht: Die Ansicht holt den nächsten Frame, bevor sie den Bildschirm löscht, und ein vorübergehend leerer Poll behält den letzten guten Frame, statt zu leeren. Sie erhalten eine ruhige Tabelle statt einer flackernden, egal wie langsam ein Manager antwortet.

Zur Abrundung der Nur-Lese-Befehle meldet Get-ZrInfo die installierte Version, die Installations- und Datenverzeichnisse, beide Modulpfade, die Host-Runtime — und prüft jeden Manager auf Erreichbarkeit. Ein abgesicherter Manager, der mit 401 antwortet, wird als erreichbar, aber Authentifizierung nötig gemeldet, nicht als „down", sodass Sie ein Netzwerkproblem auf einen Blick von einem fehlenden Token unterscheiden können.

Schritt 4 — stoppen, und die Form darunter​

Einen Store herunterzufahren ist das Lebenszyklus-Gegenstück zum Starten:

# 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

Der Default ist ein schneller harter Kill, das richtige Verhalten, wenn der gesamte Store auf einmal herunterfährt — es gibt keinen überlebenden Cluster, an den ein scheidender Node übergeben könnte, ein Drain bringt also nichts. Verwenden Sie -Graceful, wenn jeder Node sauber drainen und den Cluster verlassen soll, was wichtig ist, wenn Sie nur eine Teilmenge statt des Ganzen stoppen.

Unter jedem Cmdlet in diesem Beitrag liegt eine Idee: Ein Zaris-Store hat eine gewünschte Form — eine kanonische Definition der Server und Partitionen, die er haben soll —, und der Manager läuft unter einem Supervisor-Modell, das die Live-Prozesse kontinuierlich darauf zutreibt. New-ZrStore schreibt diese Form; Start-ZrStore realisiert sie; Get-ZrStore und Get-ZrNode melden, wie nah die Realität ihr ist. Dasselbe Modell macht elastisches Resizing zu einem Einzeiler statt zu einem Runbook — die gewünschte Form mit Add-ZrServer / Remove-ZrServer ändern und den Supervisor abgleichen lassen, was eine eigene Geschichte über elastische Skalierung ist.

Die ehrliche Zusammenfassung​

Der vollständige Day-one-Lebenszyklus besteht aus fünf Befehlen und zwei Lesevorgängen:

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?

Was dies zu einer Steuerungsebene macht und nicht nur zu einem Haufen Skripte, ist, dass die Cmdlets live aggregierte Wahrheit melden — nicht, was Sie angefordert haben, sondern was der Cluster tatsächlich ist — und dass die Entscheidungen mit echten Konsequenzen offen benannt sind: Replikationsfaktor gegenüber Maschinenanzahl, Async gegenüber Sync, Replikat-Lesevorgänge gegenüber Veralterung. Einen Store aufsetzen, die Konvergenz bestätigen und ihn im Auge behalten — alles, ohne die Shell zu verlassen.

Die meisten verteilten Datenspeicher zwingen Sie, sich früh und endgültig zwischen zwei Welten zu entscheiden. Da ist der „echte" Store — ein Cluster, den Sie deployen, auf den Sie einen Client über das Netzwerk richten und mit dem Sie über ein Wire-Protokoll sprechen. Und da ist der „falsche" Store, zu dem Sie in Unit-Tests greifen: ein In-Memory-Dictionary, ein Mock, ein handgeschriebener Stub, der gerade genug der Schnittstelle implementiert, damit der Test kompiliert. Beide haben nichts gemeinsam. Ihr Test prüft das Verhalten des Stubs, nicht das des Stores, und die Lücke dazwischen ist genau der Ort, an dem sich Bugs verstecken.

Zaris hebt diese Entscheidung auf. Derselbe typisierte .NET-Client, der über TLS mit einem verteilten Cluster spricht, betreibt den Store auch eingebettet in Ihrem Prozess, ohne Socket, ohne Partition-Map und ohne Deployment — und zwar mit derselben Store-Engine, nicht mit einem Ersatz. Welchen von beiden Sie bekommen, wählen Sie mit einer einzigen Connection-String. Dieser Beitrag erklärt, wie das funktioniert, wofür es sich wirklich eignet und wo die harte Grenze verläuft, an der der Embedded-Modus endet und ein Cluster beginnt.

Eine Zeichenfolge ist der ganze Schalter​

Ein Zaris-Client wird immer aus einer Connection-String konfiguriert. Die Zeichenfolge enthält den Transport, die Seed-Endpunkte, den Store-Namen und Optionen. Es gibt zwei Formen, und der Unterschied zwischen ihnen ist der Unterschied zwischen einem Cluster und einem eingebetteten Store:

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

Das Host-Token inproc ist reserviert. Sieht der Client es, gibt es keine Endpunkte zu wählen, keinen Transport auszuhandeln, keinen TLS-Handshake und kein Token — der Store wird aus dem Speicher im aktuellen Prozess bedient. Alles andere an Ihrem Code bleibt identisch:

// 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");

In ASP.NET Core ist es dieselbe Geschichte über Dependency Injection — die Connection-String stammt üblicherweise aus der Konfiguration, der Wechsel ist also ein Konfigurationswert, keine Codeänderung:

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

Tragen Sie zaris://inproc/orders in appsettings.Development.json und zariss://.../orders in die Produktion ein, und dieselbe Binärdatei läuft eingebettet auf dem Laptop eines Entwicklers und geclustert in der Cloud, ohne dass etwas neu kompiliert wird.

Warum „derselbe Client" der Punkt ist​

Der Grund, warum das wichtig ist, steckt im zurückgegebenen Typ. ConnectAsync liefert unabhängig vom Modus ein IZarisClient — oder, für die volle Feature-Oberfläche, IZaris. Der Embedded-Modus wird von einer Klasse namens ZarisInProcClient bedient, die exakt dieselben Schnittstellen wie der Cluster-Client implementiert:

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; }
}

Jede dieser Oberflächen ist im Embedded-Modus vorhanden, getragen von derselben Store-Engine, die der Cluster nutzt. Key/Value-Get/Put/Delete, Bulk und Batch, Multi-Item-Transaktionen, TTL und Ablauf, optimistisches Compare-and-Swap, Watch für reaktive Lesevorgänge, native Streams mit Consumer Groups, die replizierten Datenstrukturen — all das wird gegen den eingebetteten Store aufgelöst, nicht gegen einen Mock.

Diese gemeinsame Engine macht den eingebetteten Store zu einem getreuen Testziel. Eine Compare-and-Swap-Schleife, die darauf angewiesen ist, dass ein Konflikt präzise gemeldet wird, ein Watch-Abonnement, das feuern muss, wenn sich ein Schlüssel ändert, eine Transaktion, die atomar committen muss oder gar nicht — jedes verhält sich eingebettet so wie geclustert, weil es buchstäblich derselbe Codepfad auswertet. Ein KvStatus.Conflict bedeutet eingebettet dasselbe wie in der Produktion. Ein handgeschriebener Dictionary-Stub kann das nicht versprechen.

Was der Embedded-Host tatsächlich ist​

Es lohnt sich, genau zu sein, was zaris://inproc startet, denn die ehrlichen Grenzen ergeben sich direkt daraus. Der Embedded-Host ist eine feste Ein-Node-Topologie, die jedes Segment besitzt. Es gibt keine Partition-Map, weil es nur einen Teilnehmer gibt; es gibt keine Replikation, weil es keine zweite Kopie gibt; es gibt keinen Transport, weil es keinen zweiten Prozess gibt, den man erreichen müsste.

Was tatsächlich läuft, ist die echte Mechanik, die Sie in einem Test haben wollen. Der Store stellt sein Segment vorab bereit, bindet den Lease-Service, den Watch-Service und lokale Metriken ein und startet den TTL-Sweeper in seinem normalen Takt — ein Schlüssel, den Sie mit ExpireAsync auf 50 ms TTL setzen, verschwindet also tatsächlich, per Timer, genau wie in einem Cluster. Ablauf, Eviction-Buchhaltung, Versionierung und Watch-Benachrichtigungen sind alle aktiv. Es ist ein vollständiger Store, der zufällig die Cluster-Größe eins hat.

Innerhalb eines Prozesses werden Clients nach Store-Namen geteilt. Zwei Aufrufe ConnectAsync("zaris://inproc/orders") im selben Prozess lösen zum selben eingebetteten Store auf, sodass ein Wert, den der eine schreibt, der andere liest — praktisch, wenn Ihr Test einen Producer und einen Consumer startet und erwartet, dass sie sich gegenseitig sehen. Verschiedene Store-Namen ergeben verschiedene Stores; verschiedene Prozesse erhalten völlig getrennte eingebettete Stores (mehr zu dieser Grenze unten).

Wo sich der Embedded-Modus bewährt​

Unit- und Integrationstests, die den echten Store ausüben. Das ist der Hauptanwendungsfall. Ihr Repository, Ihre Cache-Schicht, Ihr Saga-Koordinator — testen Sie sie gegen zaris://inproc/test-{Guid}, erhalten Sie pro Test einen frischen, isolierten Store und prüfen die echte Semantik: echte Versionierung für Ihre CAS-Schleifen, echten TTL-Ablauf auf einem echten Timer, echte Transaktions-Atomarität, echte Watch-Events. Kein Docker-Container, der in der CI gestartet werden muss, kein Port, der zu vergeben wäre, keine instabile Aufräumphase. Der Store wird beim ersten Connect erstellt und stirbt mit dem Prozess.

Single-Process-Anwendungen, die später erwachsen werden könnten. Eine Desktop-App, ein Hintergrund-Worker, ein CLI-Tool oder ein kleiner Service, der heute einen schnellen strukturierten Store braucht, morgen aber ein geclustertes Deployment werden könnte. Beginnen Sie eingebettet. An dem Tag, an dem Sie diese Daten über Instanzen hinweg teilen müssen, ändern Sie die Connection-String auf einen Cluster — und weil Sie die ganze Zeit gegen IZaris programmiert haben, bewegt sich sonst nichts.

Integrationen, die standardmäßig eingebettet ausgeliefert werden. Der Zaris-ASP.NET-Core-Session-Provider ist ein konkretes Beispiel: Zaris als Session-Store einzubinden ist ein Aufruf, und in seinem Sample läuft er vollständig eingebettet —

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

— sodass ein Entwickler die App mit F5 starten und funktionierende Sessions ohne jede Infrastruktur haben kann, um dann für ein Multi-Instanz-Deployment auf zariss://.../sessions zu wechseln, ohne den Session-Code anzufassen.

Um den Embedded-Modus zu nutzen, referenzieren Sie das Paket Clustron.Zaris.InProc neben dem Client (es zielt auf .NET 8). Das Paket registriert sich selbst: Der Client entdeckt und lädt die In-Process-Factory bei der ersten Verwendung, die bloße Referenz genügt also. In einer Test-Assembly, in der Sie lieber explizit sein möchten, verdrahtet new InProcBootstrap().Register(); es deterministisch.

Wo er ehrlicherweise endet​

Der Embedded-Modus ist ein echter Store, aber ein Single-Node-In-Memory-Store, und etwas anderes vorzugeben wäre genau der Marketing-Nebel, den dieser Blog vermeiden will. Drei harte Grenzen, direkt aus dem Design:

Keine Dauerhaftigkeit. Der eingebettete Store hält Daten im Prozessspeicher und nirgendwo sonst. In diesem Modus gibt es weder Replikation noch ein On-Disk-Log — beendet sich der Prozess, sind die Daten weg. Das ist genau das, was Sie für einen Test wollen (jeder Lauf mit sauberem Zustand), und genau das, worauf Sie sich bei allem, was einen Neustart überleben soll, nicht verlassen dürfen. Der Embedded-Modus ist keine Datenbank, auf die Sie Ihre Produktionsdaten stützen.

Keine Hochverfügbarkeit, kein Scale-out. Ein Cluster aus einem Node toleriert den Verlust von null Nodes und skaliert bis zu Speicher und CPU eines Prozesses. All die Gründe, aus denen Sie zum verteilten Zaris greifen würden — einen Node-Ausfall ohne Datenverlust überstehen, Replikate für Dauerhaftigkeit dimensionieren, den Durchsatz über Kerne und Maschinen skalieren — treffen auf einen Embedded-Host schlicht nicht zu, weil es nur einen davon gibt. Brauchen Sie diese Eigenschaften, brauchen Sie den Cluster.

Kein prozessübergreifendes Teilen. Die In-Process-Registry teilt einen Store nach Namen innerhalb eines Prozesses. Zwei verschiedene Prozesse, die beide zaris://inproc/orders öffnen, erhalten zwei unabhängige Stores, die nichts voneinander wissen — zwischen ihnen gibt es per Definition keinen Socket. In dem Moment, in dem Ihre Daten für einen zweiten Prozess oder eine zweite Maschine sichtbar sein müssen, ist der Embedded-Modus das falsche Werkzeug und ein Cluster das richtige.

Nichts davon sind Bugs, die zu beheben wären; es ist die Definition von „embedded". Der Wert liegt nicht darin, dass der In-Process-Store heimlich verteilt wäre — sondern darin, dass an dem Tag, an dem Sie Verteilung brauchen, das Einzige, was Sie ändern, die Zeichenfolge ist, die sagt, wo der Store lebt.

Dasselbe Versprechen, zweimal gehalten​

Der Pitch ist klein und konkret. Sie schreiben Ihre Anwendung gegen eine Client-Oberfläche. In einem Test, auf einem Laptop oder in einem Single-Process-Tool wird diese Oberfläche von einem echten Zaris-Store bedient, der in Ihrem eigenen Speicher läuft — schnell erstellt, getreu in seiner Semantik und weg, wenn der Prozess endet. In der Produktion spricht derselbe Code über TLS mit einem verteilten Cluster. Das Verhalten, das Ihre Tests festgenagelt haben, ist das Verhalten, das Sie ausliefern, weil es nie eine andere Implementierung war — nur ein anderer Ort, an dem der Store lebt.

Das ist die ganze Idee hinter zaris://inproc: Die Lücke zwischen „dem Store in meinem Test" und „dem Store in der Produktion" ist eine Connection-String breit, und Sie entscheiden pro Umgebung, auf welcher Seite Sie stehen.

Es gibt eine Frage, die jeder Entwickler irgendwann an einen verteilten Store richtet, meist direkt nach einem verwirrenden Bug-Report: Wenn ich einen Wert schreibe und ihn sofort zurücklese, sehe ich dann garantiert, was ich geschrieben habe? Das klingt, als müsste es eine Ein-Wort-Antwort geben. Gibt es nicht — nicht für irgendeinen partitionierten, replizierten Store, und nicht für Zaris. Die ehrliche Antwort lautet „ja, innerhalb einer Partition, weil Lesevorgänge zum selben einzelnen Owner gehen wie Ihr Schreibvorgang" — und das Interessante ist alles, was in dieser Einschränkung steckt.

Dieser Beitrag ist das Konsistenzmodell von Zaris an einem Ort zusammengetragen. Über die Einzelteile haben wir separat geschrieben — optimistisches Compare-and-Swap, transparenter Retry bei Ownership-Churn, das wiederabspielbare Op-Log, das Replikate speist, Multi-Key-Transaktionen. Hier verbinden wir sie aus Sicht des Lesers und beantworten die einzige Frage, die an der Tastatur zählt: Was wird mir beim Lesen tatsächlich zugesichert? Einschließlich, und vor allem, wo die Zusicherung endet.

Das Modell in einem Satz​

Zaris ist ein AP-lastiger Store, bei dem die Konsistenzgrenze um die Ownership gezogen ist, nicht um jeden Schreibvorgang. Die Datenebene bleibt verfügbar — ein einzelner Node bedient weiter die Segmente, die er hält —, und die Single-Writer-Disziplin, die Lesevorgänge vernünftig hält, wird in der Ownership-Ebene durchgesetzt: Zu jedem Zeitpunkt gibt es genau einen aktiven Owner pro Partition. Schreibvorgänge auf eine Partition werden durch diesen einen Node serialisiert. Auf dem Schreibpfad gibt es bewusst kein Quorum und keinen Konsens, und Zaris behauptet nicht globale strikte Linearisierbarkeit.

Fast alles, was ein Leser beobachtet, folgt aus dieser einen strukturellen Tatsache, daher lohnt es, die Kette explizit zu machen:

key → segment → partition → one runtime active owner

Ein Schlüssel wird deterministisch auf ein Segment gehasht; ein Segment gehört zu einer Partition; eine Partition hat genau einen aktiven Owner, der ihre Schreibvorgänge annimmt und ihre Lesevorgänge bedient. Ownership ist eine Lease, die in der Partition-Map als (LeaderTerm, OwnershipGeneration) geführt wird — vom Cluster-Leader vergeben, über Neustarts hinweg dauerhaft und an jeden Node propagiert. Diese Lease garantiert das „genau einer" — sie ersetzte ein älteres Schema „höchste Epoch gewinnt", das bei einem Neustart zurückgesetzt werden konnte und kurzzeitig zwei Nodes hervorbrachte, die beide glaubten, dieselbe Partition zu besitzen.

Warum Owner-geroutete Lesevorgänge Read-your-writes liefern​

Hier kommt der Teil, der die Eingangsfrage beantwortet. In Zaris werden Lesevorgänge zum aktiven Owner geroutet, demselben Node, an den Ihr Schreibvorgang ging. Clients lesen standardmäßig nicht von Replikaten. Wenn Sie also einen Schlüssel mit PutAsync schreiben und dann mit GetAsync lesen, werden beide Requests — über dieselbe Routing-Tabelle, aufgebaut aus der Partition-Map plus dem Runtime-Ownership-Snapshot — zum selben Owner-Node aufgelöst, und dieser Node hat Ihren Schreibvorgang bereits in seinem lokalen Store.

Das ist der gesamte Mechanismus. Read-your-writes wird nicht als Session-Garantie oder clientseitiger Cache aufgesetzt; es ergibt sich aus dem Routing. Sie lesen Ihre Schreibvorgänge innerhalb einer Partition, weil ein einzelner Node die maßgebliche Instanz für Lese- und Schreibvorgänge dieser Partition ist und Schreibvorgänge darauf nacheinander serialisiert werden. Das Replikat in diesem Diagramm mag einige Millisekunden hinter dem Owner zurückliegen — die Replikation hat einen asynchronen Schwanz —, aber standardmäßig lesen Sie nie das Replikat, sodass dieser Lag für Sie unsichtbar bleibt.

Die Einschränkung „innerhalb einer Partition" ist tragend, und wir kommen darauf zurück, was sie ausschließt.

Die Version, die Sie sehen dürfen​

Jeder Wert, den der Owner ausliefert, trägt zwei monotone Zahlen, und sie machen „derselbe Wert" zu einer präzisen Aussage statt zu einem Gefühl:

• eine vom Store verwaltete Revision — eine strikt steigende Sequenznummer, die der Owner jeder Mutation in Commit-Reihenfolge aufprägt, und
• eine ItemVersion pro Item — die Version dieses konkreten Schlüssels, die IfMatchVersion in einem Compare-and-Swap-Schreibvorgang absichert.

Da der Owner diese in Commit-Reihenfolge vergibt und Lesevorgänge aus demselben committeten Zustand bedient, bewegen aufeinanderfolgende Lesevorgänge eines Schlüssels vom Owner die Version vorwärts, nie rückwärts. Sie lesen nicht Version 42 und einen Augenblick später Version 40. Diese Monotonie ist genau das, was die CAS-Schleife korrekt macht: Ein Leser sieht eine Version, rechnet dagegen und schreibt unter der Bedingung zurück, dass sie noch diese Version ist. Ließe das Modell Lesevorgänge zwischen Versionen flattern, stünde optimistische Nebenläufigkeit auf Sand. Ein Owner, in Commit-Reihenfolge vergebene Revisionen, vom Owner bediente Lesevorgänge — das ist das Fundament, auf dem die gesamte Koordinationsgeschichte im CAS-Beitrag steht.

Das Fenster, in dem ein Lesevorgang ehrlich „noch nicht" sagt​

Owner-geroutete Lesevorgänge sind im Normalbetrieb sauber. Die interessanten Momente sind die Übergänge — ein Failover, eine Migration, ein bevorzugter Primary, der zurückfällt —, denn während einer Übergabe ist der Node, zu dem Sie routen würden, möglicherweise gerade nicht die maßgebliche Instanz. Zaris trifft hier die ehrliche Wahl: Statt einen Lesevorgang von einem Node zu bedienen, der nicht der beständige Owner ist, liefert es einen wiederholbaren Status. Ein Lese- (oder Schreib-)Vorgang in einem solchen Fenster kann zurückkommen als:

• Moved — Ihre Routing-Tabelle ist veraltet; der Schlüssel liegt jetzt auf einem anderen Node.
• OwnershipChanging — der Besitz an diesem Segment befindet sich gerade aktiv im Übergang; es ist eine Übergabe, kein beständiger Routing-Fehler.
• Migrating — das Segment wird gerade zu einem neuen Owner migriert.
• ReplicaSyncPending — dieser Node bringt die Kopie eines Segments auf den neuesten Stand und bedient daraus noch keinen möglicherweise unvollständigen Lesevorgang.
• Unavailable — die Partition hat in diesem Augenblick keinen erreichbaren Owner.

Keiner davon ist eine Exception, die Sie aus einem Stacktrace herauslesen müssen — es sind maschinenlesbare Ergebnisse, und der .NET-Client behandelt sie als vorübergehend und wiederholt mit Reroute, aktualisiert seine Cluster-Map und geht zu dem, den die Map nun als Owner nennt. Der Effekt: Ihr GetAsync dauert einfach ein paar Millisekunden länger und liefert dann den richtigen Wert. Die Designentscheidung darunter verdient klare Worte: Zaris lässt Sie lieber einen Moment warten, als Ihnen einen Lesevorgang zu geben, bei dem es sich nicht sicher ist, ob er maßgeblich ist. Ein wiederholbares „noch nicht" ist eine bessere Antwort als ein selbstsicheres Falsch.

Deshalb überlebt Read-your-writes auch ein Failover: Die Write-Fence-Arbeit sorgt dafür, dass ein bestätigter Schreibvorgang im Übergabefenster nicht zurückbleibt (zur ehrlichen Grenze davon kommen wir unten), und die Promotion macht einen Node erst zum Owner, wenn er dazu berechtigt ist — der Lesevorgang, der nach einem Failover umgeroutet wird, geht also zu einem Node, der Ihre Daten hat.

Der Regler, den Sie drehen können — und was er heute tatsächlich bewirkt​

Zaris stellt eine Oberfläche für Lesekonsistenz bereit. GetOptions trägt eine ReadConsistency von Leader, Quorum oder Any, und ein Store hat ein Flag AllowReplicaReads (standardmäßig aus). Die Absicht ist der klassische Handel: Lesevorgänge von Replikaten bedienen zu lassen, um die Leselast zu verteilen, im Austausch dafür, dass ein Replikat hinter dem Owner zurückliegen kann — eine begrenzte Veralterung, auf die Sie sich bewusst einlassen.

Hier der ehrliche aktuelle Stand, denn genau das würde Werbetext verwischen: Heute sind Lesevorgänge Owner-only. AllowReplicaReads und ReadConsistency.Any sind eine Konfigurations- und Request-Formungsoberfläche, die existiert und durch die Store-Definition fließt, aber es gibt noch keinen serverseitigen Codepfad, der einen Lesevorgang tatsächlich von einem Replikat bedient. In der Praxis heißt das: Sie bekommen derzeit das starke Ende des Reglers — jeder Lesevorgang ist ein Owner-Lesevorgang, also gilt Read-your-writes — und Sie bekommen nicht das Verhalten veralteter Replikat-Lesevorgänge, selbst wenn Sie das Flag umlegen.

Warum einen Regler erwähnen, der faktisch auf eine Einstellung festgenagelt ist? Weil er zeigt, was der Konsistenzvertrag Sie künftig tauschen lassen wird, und weil die Asymmetrie wichtig ist, wenn Sie über Veralterung nachdenken. Sobald Replikat-bedienende Lesevorgänge landen, ist das Einschalten von AllowReplicaReads der Moment, in dem Read-your-writes nicht mehr garantiert ist: Ein zu einem Replikat gerouteter Lesevorgang kann eine Version hinter der des Owners beobachten, solange der asynchrone Replikationsschwanz zurückliegt. Bis dahin ist die Garantie einfacher und stärker, als der Regler suggeriert. Wir möchten, dass Sie das wissen, statt anzunehmen, Sie verteilten Lesevorgänge bereits über Replikate, obwohl das nicht der Fall ist.

Was „bestätigt" für den nächsten Leser bedeutet​

Read-your-writes handelt davon, dass Sie Ihren eigenen Schreibvorgang auf dem Owner lesen. Eine andere, schärfere Frage lautet: Sobald der Owner Ihnen einen Schreibvorgang bestätigt, ist dieser sicher, wenn der Owner danach stirbt, sodass der Leser, der zum neuen Owner umgeroutet wird, ihn noch sieht?

Der ehrliche Bestätigungsvertrag heute: Ein Schreibvorgang gilt als bestätigt, wenn er im lokalen Store des aktiven Owners gelandet ist. Die Replikation auf die RF−1 Replikate läuft als asynchroner Schwanz hinter dieser Bestätigung. Die Konsequenzen sollte man einplanen, statt sie wegzuwinken:

• Bei Redundanz 1 — kein synchronisiertes Replikat — ist ein Schreibvorgang wirklich Best-Effort. Er darf nicht als Single-Fault-dauerhaft betrachtet werden, denn es gibt genau eine Kopie.
• Selbst mit Replikaten kann ein bestätigter Schreibvorgang verloren gehen, wenn der einzige aktive Owner im schmalen Fenster nach der Bestätigung, aber vor dem Eintreffen des Schreibvorgangs bei einem Replikat verloren geht.

Die stärkere Eigenschaft — erst bestätigen, wenn der Schreibvorgang auf mindestens einem synchronisierten Replikat liegt, sodass ein bestätigter Schreibvorgang den Verlust eines beliebigen Nodes überlebt — ist das Designziel (das „W1"-Ack-Gate), noch nicht die ausgelieferte Bestätigungssemantik. Es ist die Richtung, in die die Arbeit am Durability-Fundament konsolidiert, und dieser Beitrag ist bei derselben Unterscheidung sorgfältig: Die starke Aussage, die er validiert, ist auf bestätigte Schreibvorgänge, wenn ein synchronisiertes Replikat existiert, unter den vom Chaos-Lauf ausgelösten Fehlerklassen beschränkt — kein bedingungsloses „nichts kann je verloren gehen". Die Op-Log- und Migrationsmechanik ist, wie ein Replikat oder ein neuer Owner überhaupt zum committeten Zustand des Owners aufschließt; beim Ack-Gate geht es darum, wann der Owner „erledigt" sagen darf.

Die präzise Aussage für Leser lautet also: Read-your-writes auf dem Owner ist solide; die Fault-übergreifende Dauerhaftigkeit eines bestätigten Schreibvorgangs ist stark und wird stärker, mit dem oben genannten aktuellen Vorbehalt und einer harten Untergrenze bei RF1, die kein Store wegkonstruieren kann — eine Kopie ist eine Kopie.

Über Partitionen hinweg gibt es keine gemeinsame Uhr​

Die letzte Stelle, an der die Einschränkung „innerhalb einer Partition" zubeißt: Es gibt keine globale Ordnung und keinen globalen Snapshot über Partitionen hinweg. Jede Partition wird durch ihren eigenen Owner serialisiert; zwei verschiedene Partitionen sind zwei verschiedene Owner mit zwei unabhängigen Revisionsfolgen. Schreiben Sie Schlüssel A (Partition 1) und dann Schlüssel B (Partition 2), kann ein gleichzeitiger Leser den neuen Wert von B und den alten von A beobachten oder umgekehrt — es gibt keinen clusterweiten Zeitpunkt, an dem „beides geschehen" ist. Bulk- und Batch-Operationen sind darunter pro Schlüssel; sie sind bequem, nicht atomar.

Wenn eine Invariante wirklich Schlüssel überspannen muss — einen Saldo von A nach B verschieben, einen Index im Gleichschritt mit dem Datensatz halten, auf den er zeigt —, sind genau dafür Multi-Key-Transaktionen da. Sie bieten Serializable-Isolation über einen vom Client koordinierten Commit über optimistische Versionen und sind die einzige Oberfläche für schlüsselübergreifende Atomarität. Gewöhnliche Multi-Key-Lese- und Schreibvorgänge sind keine Transaktion und sollten nicht dafür gehalten werden.

Was garantiert ist und was nicht​

Klar zusammengefasst, damit Sie das ganze Modell auf einmal im Kopf behalten:

Die ehrliche Form des Ganzen​

Ein gutes Konsistenzmodell ist nicht das mit der längsten Liste an Garantien, sondern das, dessen Garantien Sie tatsächlich benennen und dessen Grenzen Sie tatsächlich sehen können. Zaris zieht seine Grenze um die Ownership und ist offen über den Handel: Sie erhalten Read-your-writes und monotone Lesevorgänge innerhalb einer Partition gratis, weil ein Owner beide Seiten bedient und Ihnen in Commit-Reihenfolge vergebene Versionen gibt; Sie erhalten während einer Übergabe ein wiederholbares „noch nicht" statt einer selbstsicheren falschen Antwort; und Sie verzichten auf globale Linearisierbarkeit und partitionsübergreifende Ordnung, die Sie sich explizit mit einer Transaktion zurückkaufen, wenn eine bestimmte Invariante sie braucht.

Die beiden Vorbehalte, die Sie im Kopf behalten sollten, sind die, die dieser Beitrag benannt statt geglättet hat: Der Replikat-Lese-Regler ist heute faktisch auf die starke Einstellung festgenagelt, Sie sind also konsistenter, als der Regler vermuten lässt; und „bestätigt" bedeutet derzeit auf dem Owner, wobei volle Single-Fault-Dauerhaftigkeit ein Ziel ist, das die Durability-Arbeit gerade umsetzt, und es bei Redundanz 1 eine echte Untergrenze gibt. Wissen Sie diese zwei Dinge, ist der Rest des Modells genau so einfach, wie er aussieht: den Owner finden, die eigenen Schreibvorgänge lesen.

Für das tiefere Design siehe Konsistenz und Partitionierung und Replikation in der Dokumentation.

Keyspace-Benachrichtigungen sind eines der nützlichsten Features von Redis und eines der unauffällig fragilsten. Die Idee ist wunderbar: Jedes Mal, wenn ein Schlüssel geschrieben, gelöscht oder ablaufend ist, veröffentlicht der Server ein Event auf einem wohlbekannten Pub/Sub-Kanal, und jeder Interessierte kann per PSUBSCRIBE reagieren — einen Cache invalidieren, einen Worker wecken, eine Projektion aktualisieren. Kein Polling, kein GET in einer Schleife, das fragt „hat es sich schon geändert?".

Die Fragilität steckt im Kleingedruckten. Redis-Keyspace-Benachrichtigungen sind Fire-and-Forget-Pub/Sub, ausgesendet von dem Node, der den Befehl verarbeitet hat, an Subscriber, die mit genau diesem Node verbunden sind. In einem geclusterten Deployment heißt das: Ein Subscriber hört nur von Schreibvorgängen, die zufällig auf dem Node landeten, an den er angebunden ist, und fällt dieser Node per Failover aus, geht die Subscription — und der Event-Strom, den sie trug — mit. Das Feature funktioniert auf einer einzelnen Box wunderbar und wird schnell subtil, sobald es mehr als eine gibt.

Zaris spricht exakt dasselbe Protokoll — CONFIG SET notify-keyspace-events, die Kanäle __keyspace@0__ und __keyevent@0__, ein gewöhnliches PSUBSCRIBE von jedem Redis-Client in jeder Sprache. Die Mechanik darunter ist jedoch keine Neuimplementierung des Redis-Notifiers. Es ist eine dünne Brücke auf ein Feature, das Zaris bereits hatte: einen nativen, clusterweiten, replizierten Watch. Das ändert, was die Benachrichtigungen wert sind.

Einschalten — exakt auf Redis-Art​

Am Aktivieren und Konsumieren des Features ist nichts Zaris-spezifisch. Richten Sie einen beliebigen Redis-Client auf das RESP-Frontend und verwenden Sie die Befehle, die Sie bereits kennen:

# 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"

Von einem typisierten Client — hier StackExchange.Redis — sieht es genauso aus, ganz ohne Zaris-SDK:

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}"));