Zum Hauptinhalt springen

Überblick über den Entwicklerleitfaden

Dieser Leitfaden zeigt Ihnen, wie Sie .NET-Anwendungen auf Clustron Zaris entwickeln: wie Sie einen Client erhalten, Daten speichern und abrufen, Bulk- und Batch-Operationen ausführen, Daten löschen, das Schreibverhalten über Optionen steuern und die Serialisierung verwalten. Er behandelt außerdem die Koordinationsprimitive (Leases, Locks, Counter, Watch, Transaktionen), die den sicheren Einsatz von Zaris aus vielen Prozessen gleichzeitig ermöglichen.

Jede Aufgabe in diesem Leitfaden nutzt dieselbe Client-Schnittstelle, IZarisClient, und derselbe Code funktioniert unabhängig davon, ob der Store In-Process oder in einem verteilten Cluster läuft.

Was Sie lernen werden​

Der Leitfaden ist aufgabenorientiert. Am Ende können Sie:

  • Einen Client aus der Dependency Injection auflösen und korrekt wiederverwenden.
  • Einzelne Schlüssel speichern, lesen und löschen und das zurückgegebene KvResult interpretieren.
  • Viele Schlüssel gleichzeitig mit Bulk-Operationen verschieben und Operationstypen mit Batches mischen.
  • Ein Präfix, einen Schlüsselbereich oder den gesamten Store leeren.
  • TTL, Labels, Leases und Concurrency-Prüfungen über PutOptions an einen Schreibvorgang anhängen.
  • Steuern, wie Ihre Objekte serialisiert und deserialisiert werden.
  • Schlüssel und Labels so entwerfen, dass Scans, Abfragen und Watches effizient bleiben.
  • Operationen mit den integrierten Wiederholungen des Clients und sicher wiederholbaren Mustern widerstandsfähig machen.
  • Einen Store anhand der ausgegebenen Metriken beobachten und Ihren Code gegen einen In-Process-Store testen.
  • Best Practices anwenden, typische Fallstricke vermeiden und Zaris als ASP.NET-Core-Cache verwenden.

Der typische Workflow​

Die meisten Anwendungen folgen demselben Muster. Sie lösen einmal beim Start einen Client auf und verwenden ihn dann für jede Operation wieder.

// 1. Resolve a client for a named store.
var client = await provider.GetAsync("default");

// 2. Write and read data.
await client.PutAsync("key", "value");
var result = await client.GetAsync<string>("key");

// 3. Inspect the result.
if (result.IsSuccess)
{
    Console.WriteLine(result.Value);
}

Jede Operation liefert ein Ergebnisobjekt zurück, anstatt bei einem fehlenden Schlüssel oder einem abgelehnten Schreibvorgang eine Exception auszulösen. Sie prüfen IsSuccess (oder den spezifischeren Status), statt für erwartete Ergebnisse Exceptions abzufangen. Die Seite zu den grundlegenden Operationen behandelt dieses Muster ausführlich.

Koordinationsprimitive​

Lese- und Schreibzugriffe auf einzelne Schlüssel genügen für einen Cache. Wenn sich mehrere Prozesse denselben Store teilen, müssen Sie sie zusätzlich koordinieren. Zaris stellt diese Primitive über denselben Client bereit:

  • Leases gewähren zeitlich begrenzten Besitz an einem Schlüssel. Läuft die Lease ab, werden die daran gebundenen Schlüssel entfernt.
  • Locks geben einem Aufrufer exklusiven Zugriff auf einen Schlüssel, während er eine Änderung vornimmt.
  • Counter bieten atomares Inkrementieren und Dekrementieren für gemeinsam genutzten numerischen Zustand.
  • Watch liefert Änderungsbenachrichtigungen, damit Ihr Code auf Aktualisierungen reagiert, statt zu pollen.
  • Transaktionen fassen mehrere Operationen zu einer Alles-oder-nichts-Einheit zusammen.

Jedes Primitiv hat weiter hinten in diesem Leitfaden eine eigene Seite.

Datenstrukturen, Pub/Sub und Streams​

Über einfaches Key/Value hinaus bietet Zaris 2.0.0 native serverseitige Collections und Messaging, jeweils als vollwertige Client-API und zusätzlich über das Redis-Protokoll-Frontend erreichbar:

  • Datenstrukturen — Hashes, Listen, Sets und Sorted Sets, die Entsprechungen der Redis-Typen.
  • Pub/Sub — clusterweites Publish/Subscribe-Messaging.
  • Streams — ein dauerhaftes Append-only-Log mit Consumer Groups und blockierenden Lesezugriffen.

Das Redis-Protokoll-Frontend (RESP) stellt all dies (zusätzlich zu einfachem KV) gewöhnlichen Redis-Clients in jeder Sprache zur Verfügung.

Dieselbe API überall​

Die Client-API ändert sich zwischen den Deployment-Modi nicht. Ein als InProc konfigurierter Store läuft innerhalb Ihres Prozesses; ein als Remote konfigurierter Store kommuniziert über das Netzwerk mit einem Cluster. Ihr Anwendungscode ist in beiden Fällen identisch, sodass Sie gegen einen In-Process-Store entwickeln und gegen einen Cluster deployen können, ohne Aufrufe umzuschreiben. Unter „Einen Client erhalten“ erfahren Sie, wie Sie den Modus über die Konfiguration auswählen.

Nächste Schritte​