Architektur
Clustron Zaris ist eine verteilte Key/Value-Datenengine für Workloads mit hohem Durchsatz und niedriger Latenz in Microservice-Umgebungen. Diese Seite ist eine Rundreise auf hoher Ebene durch die Engine — wie ein Node aufgebaut ist und wie Nodes einen Cluster bilden —, damit Sie nachvollziehen können, wo Ihre Operationen laufen und warum sich das System so verhält.
Diese Seite führt auf konzeptioneller Ebene durch die Engine. Eine diagrammreiche, aktuelle Darstellung des Clusters — Manager und Nodes, Partitionierung und Replikation, Deployment-Modelle, Sicherheit und TLS, Skalierung und die Web-Konsole — finden Sie im Abschnitt Architektur und Betrieb.
Entwurfsziele
Clustron Zaris ist ein verteiltes Datenfundament, kein einfacher Cache. Seine Struktur ergibt sich aus wenigen Zielen, die jede der folgenden Schichten prägen:
- Horizontale Skalierbarkeit, sodass Sie Kapazität durch zusätzliche Nodes hinzufügen.
- Eine klare Trennung zwischen Steuerungs- und Datenverantwortlichkeiten.
- Erweiterbare interne Engine-Komponenten, die sich ohne Neuentwicklung weiterentwickeln.
- Vorhersagbare Performance unter Last.
- Isolation auf Instanzebene, sodass Instanzen einander nicht stören.
Clustron-Zaris-Architektur
Jeder Node läuft als unabhängiger Prozess und nimmt an der Cluster-Koordination teil. Der Rest dieser Seite geht von innen nach außen vor: zuerst die Trennung von Steuerung und Daten, dann die Komponenten innerhalb eines Nodes, dann wie Nodes einen Cluster bilden.
Steuerungsebene und Datenebene
Clustron Zaris trennt die Arbeit des Datenbedienens von der Arbeit der Cluster-Verwaltung. Die Trennung dieser Ebenen verschafft dem System sowohl betriebliche Klarheit als auch Spielraum zum Skalieren, da jede Ebene für sich betrachtet und abgestimmt werden kann.
Datenebene
Die Datenebene bearbeitet jede Anfrage, die Ihre Daten berührt. Sie ist der Pfad, den Ihre Anwendung bei jeder Operation durchläuft, und in erster Linie auf Durchsatz optimiert.
Sie ist zuständig für:
- Key/Value-Operationen (Get, Put, Delete)
- Präfix-Abfragen
- Watch-Abonnements
- TTL-Durchsetzung
- Index-Lookups
- Abfrageausführung
- Lease- und Locking-Primitive
- Counter-Operationen
Damit dieser Pfad schnell bleibt, ist die Datenebene auf Durchsatz, minimalen Garbage-Collection-Druck, effizientes asynchrones Networking und Serialisierung mit geringem Overhead optimiert.
Steuerungsebene
Die Steuerungsebene verwaltet den Cluster selbst statt der darin enthaltenen Daten. Sie läuft, wenn Stores und Instanzen erstellt, konfiguriert und abgebaut werden — nicht bei jeder Anfrage.
Sie ist zuständig für:
- Store-Erstellung
- Verwaltung des Instanz-Lebenszyklus
- Cluster-Konfiguration
- Port-Verwaltung
- Instanzisolation
- Starten und Beenden von Nodes
- Konfigurationsvorlagen
Aufgrund dieser Trennung läuft jede Zaris-Instanz unabhängig, hat ihre eigene Konfiguration, führt isoliertes Logging und kann mehrfach pro Host bereitgestellt werden.
Im Inneren eines Nodes
Ein einzelner Clustron-Zaris-Node besteht aus einer Reihe fokussierter Engine-Komponenten. Jede verantwortet einen eigenen Abschnitt des Weges einer Anfrage, wodurch die Engine schnell bleibt und sich Stück für Stück weiterentwickeln kann.
Request-Pipeline
Die Request-Pipeline ist die Eingangstür: Sie nimmt Client-Anfragen entgegen und leitet sie an die richtige Engine-Komponente weiter. Sie ist auf asynchrone I/O-Effizienz, minimale Kontextwechsel, Backpressure-Behandlung und strukturierte Fehlerweitergabe ausgelegt, sodass der Node bei Lastspitzen reaktionsfähig bleibt.
Segment-Store
Der Segment-Store ist die zentrale In-Memory-Speicher-Engine — dort leben Ihre Schlüssel und Werte tatsächlich. Er übernimmt Schlüssel-Partitionierung, nebenläufigen Zugriff, Datenlayout und effiziente Speichernutzung. Seine segmentbasierte Partitionierung ist die Kernidee: Die Arbeit wird auf Segmente verteilt, sodass viele Operationen ohne einen einzigen globalen Lock nebenläufig ablaufen.
Index-Manager
Der Index-Manager beschleunigt Abfragen, damit sie nicht auf das Durchsuchen aller Schlüssel zurückfallen. Er bietet Gleichheits-Indizierung, Range-Indizierung und effiziente Lookup-Pfade und pflegt diese Indizes neben dem Primärspeicher, sodass Abfrageoperationen vollständige Scans vermeiden.
Expiration-Engine
Die Expiration-Engine setzt die TTL durch. Sie nutzt ein an das TimeWheel angelehntes Modell, das Abläufe in O(1) einplant und die Bereinigungskosten vorhersagbar hält, statt mit der Schlüsselanzahl zu wachsen. Das vermeidet Timer-Overhead pro Schlüssel und teure Scans, sodass die Performance auch bei großen TTL-Workloads erhalten bleibt.
Watch-Engine
Die Watch-Engine treibt reaktive Anwendungen an, indem sie Änderungen zustellt, sobald sie passieren. Sie unterstützt Abonnements auf Schlüsselpräfixe, stellt Events bei Mutationen zu, bietet einen Snapshot gefolgt von Live-Events und gibt Events in Reihenfolge weiter — die Grundlage für Systeme, die reagieren statt zu pollen.
Lease- und Lock-Engine
Die Lease- und Lock-Engine stellt die verteilten Koordinationsprimitive bereit: Leases, Lock-Erwerb, ablaufbasierte Koordination und sichere Freigabe. Sie sind die Bausteine, aus denen übergeordnete Workflows — exklusiver Zugriff, Leader-Election, Presence — zusammengesetzt werden.
Counter-Engine
Die Counter-Engine führt atomare verteilte Counter mit Increment, Decrement, Lesen und TTL-Unterstützung. Sie ist für Metriken, Throttling und Koordinationsszenarien gebaut, in denen viele Clients dieselbe Zahl sicher aktualisieren.
Das Cluster-Modell
Clustron-Zaris-Nodes bilden einen einzigen logischen Cluster. Der Cluster ist so ausgelegt, dass Operationen innerhalb der Besitzgrenzen eines Nodes konsistent bleiben, während das System als Ganzes horizontal skaliert.
Seine wesentlichen Merkmale sind:
- Peer-to-Peer-Koordination zwischen Nodes
- Node-bewusstes Routing von Anfragen
- Ausfallerkennung
- Rebalancing, wenn der Cluster wächst oder schrumpft, gesteuert durch elastische Skalierung (
Add-ZrServer/Remove-ZrServer) - Konfigurierbares prioritätsbasiertes Reconnect-Verhalten
Clients sind aktive Teilnehmer in diesem Modell. Jeder Client führt eine priorisierte Serverliste, eine Reconnect-Verzögerungsstrategie und Failover-Behandlung, sodass er weiterarbeiten kann, wenn sich die Verfügbarkeit von Nodes ändert.
Multi-Instanz-Deployment
Clustron Zaris unterstützt den Betrieb mehrerer Instanzen auf einer Maschine. Jede Instanz läuft auf einem eigenen Port, führt isolierte Konfiguration und Logs und kann einzeln gestartet oder gestoppt werden. Das macht es praktikabel, Ressourcen aufzuteilen, Umgebungen zu isolieren und kontrollierte Multi-Tenant-Deployments auf gemeinsam genutzter Hardware zu betreiben.
Netzwerk
Die Netzwerkschicht ist auf asynchrone Operationen mit hohem Durchsatz, effiziente Socket-Nutzung, kontrollierte Verbindungslebenszyklen und sanftes Failover ausgelegt. Sie verzichtet bewusst auf unnötige Abstraktionsschichten, denn jede zusätzliche Schicht auf dem Anfragepfad fügt Overhead hinzu, den die Engine abbauen will.
Skalierungsphilosophie
Clustron Zaris skaliert nach außen statt nach oben. Diese Entscheidung bestimmt den Rest des Designs: zustandsloses Client-Design, vorhersagbares Speicherverhalten, kontrollierter Koordinations-Overhead und modulare Erweiterbarkeit. Die Engine ist so aufgebaut, dass neue Fähigkeiten ohne Umbau des Kerns ergänzt werden können — geplante Richtungen umfassen erweiterte Abfragefähigkeiten, Vektor- und Ähnlichkeitssuche, verteiltes Job-Scheduling und zusätzliche verteilte Primitive.
Observability
Zaris liefert Observability integriert mit. Live-Metriken pro Store und pro Node werden über Watch-ZrStoreMetrics gestreamt, der Cluster meldet seinen eigenen Zustand, und verteiltes Tracing ist pro Store (New-ZrStore -Tracing) oder bei Bedarf von einem Client aus (Enable-ZrTrace) verfügbar. Das vollständige operative Bild finden Sie unter Monitoring.
Entwurfsprinzipien
Die Architektur folgt einem konsistenten Satz von Prinzipien: Performance zuerst, Vorhersagbarkeit vor Abstraktion, Erweiterbarkeit ohne Umbau der Kern-Engine, klare Trennung der Verantwortlichkeiten, betriebliche Klarheit und praxisnahes Engineering verteilter Systeme.
Aktueller Status
Clustron Zaris befindet sich in aktiver Entwicklung. Die Stabilisierung der Kern-Engine und die Dokumentation laufen weiter. Eine öffentliche Open-Source-Veröffentlichung der Kern-Engine ist für 2026 unter einer Business Source License geplant.