Zum Hauptinhalt springen

Store

Ein Store ist die zentrale Einheit, gegen die Sie in Clustron Zaris arbeiten. Jede Daten- und Koordinationsoperation findet innerhalb eines Stores statt, und der Store definiert die Grenze, innerhalb derer diese Operationen konsistent und isoliert sind.

Was ein Store ist​

Ein Store ist ein logischer Cluster. Er ist ein Container für Ihre Daten und Ihre Koordinationsprimitive und die Grenze für Konsistenz und Lebenszyklusverwaltung — der Geltungsbereich, in dem Keys, Locks, Zähler und Leases zueinander in Beziehung stehen. Sie interagieren mit Clustron Zaris stets über einen Store; es gibt keine tiefere Ebene, die Sie direkt ansprechen.

Dieselbe Store-Abstraktion funktioniert, ob sie in einem Prozess oder über viele Maschinen hinweg läuft. Was sich zwischen diesen Fällen ändert, ist die Anzahl der Nodes hinter dem Store, nicht die Art, wie Sie ihn verwenden.

Ein Store, viele Nodes​

Im verteilten Modus wird ein Store von mehreren Nodes getragen. Ein Node ist eine einzelne laufende Instanz des Stores. Die Nodes teilen sich die Daten und den Koordinationszustand des Stores und präsentieren sich Ihnen als eine logische Einheit:

Store (TestStore)
  ├── Node 1
  ├── Node 2
  └── Node N

Jeder Node nimmt am Cluster teil, Daten und Koordinationszustand werden zwischen ihnen geteilt, und das System verhält sich als ein einziger Store. Sie routen Requests nicht selbst an bestimmte Nodes — Clients können sich mit einem beliebigen Node verbinden, und der Cluster koordiniert im Hintergrund.

In-Process- und verteilte Stores​

Derselbe Store läuft in zwei Modi. Im In-Process-Modus läuft er vollständig innerhalb Ihrer Anwendung, ohne Netzwerkkommunikation und ohne externe Abhängigkeiten:

Application
  └── Store (InProc)

Im verteilten Modus läuft der Store über Maschinen hinweg — zum Beispiel Node 1 auf Maschine A, Node 2 auf Maschine B, Node 3 auf Maschine C. Die Nodes kommunizieren miteinander, Clients können sich mit jedem von ihnen verbinden, und der Cluster pflegt geteilten Zustand. Die API ist in beiden Modi identisch, der Unterschied liegt also darin, wo der Store läuft, nicht darin, wie Sie dagegen programmieren. In-Process- und verteilte Modi behandelt die Abwägungen.

Einen Store benennen​

Jeder Store hat einen eindeutigen Namen, etwa TestStore, orders oder cache. Der Name ist das Handle, mit dem Sie den Store erstellen, Clients damit verbinden und ihn aus der Konfiguration auflösen. Da alles den Store über den Namen findet, halten Sie ihn stabil und aussagekräftig.

Ein Store ist eine Grenze​

Das Wichtigste, was man über einen Store verstehen muss, ist, dass er harte Grenzen zieht. Diese Grenzen machen Stores zu einer Isolationseinheit, über die Sie nachvollziehbar nachdenken können.

  • Datengrenze. Keys leben innerhalb eines Stores. Verschiedene Stores teilen nie Daten, und jeder Store führt seinen eigenen Key-Raum. Ein Key in einem Store ist für einen anderen unsichtbar.
  • Koordinationsgrenze. Locks, Zähler und Watches sind auf einen einzelnen Store beschränkt. Es gibt keine storeübergreifende Koordination — ein Lock in einem Store bedeutet in einem anderen nichts.
  • Fehlergrenze. Fehler und Wiederherstellung finden innerhalb eines Stores statt. Jeder Store arbeitet unabhängig, sodass sich Probleme in einem nicht auf einen anderen ausbreiten.

Mehrere Stores betreiben​

Da jeder Store isoliert ist, können Sie in derselben Umgebung mehrere betreiben — zum Beispiel orders-store, inventory-store und session-store. Jeder wird unabhängig verwaltet, sodass Sie Workloads isolieren, einen bestimmten Store für sich skalieren und je Store unterschiedliche Konfiguration anwenden können. Das ist der Hauptgrund, warum Stores in Clustron Zaris die Einheit für Skalierung und Modularität sind: Sie zerlegen Ihr System entlang der Store-Grenzen und behandeln jeden Store als eigenes Anliegen.

Nächste Schritte​