Verteilter Cache für .NET
Ein verteilter Cache hält gemeinsam genutzte Daten mit schnellem Zugriff im Arbeitsspeicher über mehrere Prozesse oder Maschinen hinweg, sodass jede Instanz Ihrer Anwendung dieselben Werte sieht. Dieser Artikel erklärt, was ein verteilter Cache ist, wann eine .NET-Anwendung einen braucht und wie Clustron Zaris diese Rolle ausfüllt.
Was ein verteilter Cache ist
Ein Cache speichert berechnete oder abgerufene Werte im Arbeitsspeicher, damit Sie den Aufwand, sie zu erzeugen, nicht erneut zahlen. Ein verteilter Cache verteilt diesen Speicher auf mehr als einen Node und macht die zwischengespeicherten Daten von jeder Instanz Ihrer Anwendung aus erreichbar.
Der Unterschied wird wichtig, sobald Ihre Anwendung als mehr als ein Prozess läuft. Ein In-Process-Cache lebt innerhalb einer einzelnen Instanz: Jede Instanz hat ihre eigene Kopie, die Kopien laufen auseinander, und keine überlebt einen Neustart. Ein verteilter Cache hält einen logischen Datenbestand, den jede Instanz liest und schreibt, sodass ein von einer Instanz geschriebener Wert bei der nächsten Anfrage sichtbar ist, selbst wenn eine andere Instanz sie bearbeitet.
Wann Sie einen brauchen
Greifen Sie zu einem verteilten Cache, wenn Ihre Anwendung als mehrere Instanzen läuft — für Skalierung, für Verfügbarkeit oder weil sie in Containern lebt — und diese Instanzen eine gemeinsame, konsistente Sicht auf häufig genutzte Daten benötigen. Typische Workloads sind:
- Session-State, damit jede Instanz hinter einem Load Balancer die nächste Anfrage eines Benutzers bedienen kann.
- API- und Abfrage-Response-Caching, damit ein einmal berechnetes, aufwendiges Ergebnis in der gesamten Flotte wiederverwendet wird.
- Konfiguration und Feature-Flags, damit sich eine Änderung ohne erneutes Deployment auf jede Instanz überträgt.
- Gemeinsamer Anwendungszustand, etwa Counter oder abgeleitete Werte, die mehrere Instanzen aktualisieren.
Wie Clustron Zaris als verteilter Cache dient
Clustron Zaris ist ein verteilter In-Memory-Key/Value-Store für .NET. Als Cache liefert er die Bestandteile, die Sie von einer Caching-Schicht erwarten:
- Verteilte Key/Value-Speicherung, über Nodes partitioniert, sodass die Kapazität mit jedem hinzugefügten Node wächst.
- Horizontale Skalierung über einen Multi-Node-Cluster.
- Time-to-Live-(TTL-)Ablauf, damit zwischengespeicherte Einträge von selbst altern.
- Asynchrone .NET-Client-APIs für Lese- und Schreibzugriffe.
- Eine clusterweite Sicht auf die Daten, sodass jeder Node eine Anfrage für jeden Schlüssel bedienen kann.
Sie installieren ihn als NuGet-Paket und sprechen ihn über den nativen .NET-Client an. In der Entwicklung können Sie den Store In-Process betreiben — eingebettet in Ihre Anwendung, ohne separaten Server — und denselben Client-Code später auf einen echten Remote-Cluster richten, ohne ihn umzuschreiben.
Starten Sie beim Entwickeln und Testen In-Process und wechseln Sie für die Produktion zu einem Remote-Cluster. Die Client-API ist in beiden Modi dieselbe, der Wechsel ist also eine Konfigurationsänderung und kein Umbau.
Mehr als ein Cache
Zaris ist ein koordinationsfähiger Store, nicht nur ein Cache. Neben Get und Set bietet er Primitive, die ein einfacher Cache nicht kennt:
- Verteilte Locks, damit nur eine Instanz einen kritischen Abschnitt zur Zeit ausführt.
- Transaktionen, damit mehrere Operationen atomar angewendet werden.
- Watch-Benachrichtigungen, damit ein Client auf die Änderung eines Schlüssels reagiert, statt zu pollen.
- Atomare Counter und Leases, für gemeinsamen numerischen Zustand und Besitz mit Ablauf.
So können Sie einen Store sowohl für zwischengespeicherte Daten als auch für die Koordinationslogik nutzen, die sonst ein zweites System braucht. Eine ausführlichere Behandlung dieser Primitive finden Sie im Koordinationsleitfaden weiter unten.