Zum Hauptinhalt springen

Koordinationsmodell

Clustron Zaris stellt Primitive bereit, mit denen unabhängige Anwendungsinstanzen sich über gemeinsamen Zustand sicher koordinieren können. Dieser Artikel erklärt das Modell hinter Locks, Countern und Watch — wofür sie gedacht sind und warum sie sich bei Ausfällen vorhersagbar verhalten —, damit Sie entscheiden können, welches ein gegebenes Problem braucht.

Die Kernidee​

Koordination in Clustron Zaris beruht auf drei zusammenwirkenden Ideen:

gemeinsamer Zustand + kontrollierter Besitz + automatische Wiederherstellung

Der Store hält den gemeinsamen Zustand, Leases liefern kontrollierten, zeitlich begrenzten Besitz, und der Ablauf sorgt für automatische Wiederherstellung, wenn ein Besitzer ausfällt. Deshalb verhalten sich koordinierte Anwendungen auch dann vorhersagbar, wenn ein Prozess abstürzt: Dieselbe Maschinerie, die die Lebensdauer der Daten steuert, regelt auch, wer wofür verantwortlich ist.

Die Primitive sind keine separaten Subsysteme, die neben den Daten angeflanscht wurden. Sie bauen auf den Schichten auf, die Sie bereits kennen:

Keys → TTL → Leases → Koordination

Schlüssel speichern den Zustand, TTL steuert seine Lebensdauer, Leases verwalten den Besitz, und die Koordinationsprimitive bauen darauf auf. Da sie ein gemeinsames Fundament teilen, lassen sie sich sauber kombinieren und scheitern gemeinsam sicher.

Die drei Primitive​

Clustron Zaris bietet Ihnen drei Koordinationsprimitive, die jeweils eine andere Frage beantworten: Locks beantworten „Wer darf handeln", Counter „Wie viele" und Watch „Was hat sich geändert".

Locks​

Ein Lock stellt sicher, dass nur ein Client zur Zeit auf eine Ressource einwirken kann. Verwenden Sie ihn, wenn ein kritischer Abschnitt im gesamten System genau einmal laufen muss — um doppelte Jobausführung zu verhindern, sicherzustellen, dass ein einzelner Worker eine Aufgabe bearbeitet, oder eine gemeinsame Ressource vor nebenläufiger Änderung zu schützen.

Locks geben Ihnen exklusiven Besitz, und weil sie von Leases getragen werden, sind sie bei Ausfällen sicher: Stürzt der Besitzer ab, läuft sein Lease ab und der Lock wird automatisch freigegeben. Es gibt keine manuelle Bereinigung und kein Risiko, dass ein toter Besitzer alle anderen blockiert.

Counter​

Ein Counter führt gemeinsamen numerischen Zustand, den viele Clients gleichzeitig aktualisieren. Verwenden Sie ihn, um Zählstände wie aktive Worker zu verfolgen, Ratenbegrenzungen durchzusetzen oder verteilte Metriken zu sammeln.

Counter-Updates sind atomar und über Nodes hinweg konsistent, sodass nebenläufige Inkremente und Dekremente keine Updates verlieren und Sie keine manuelle Synchronisierung darum herum brauchen. Das ist der sichere Weg, eine laufende Summe zu führen, zu der mehrere Instanzen beitragen — wo ein einfaches Read-Modify-Write auf einem Schlüssel das Risiko verlorener Updates birgt.

Watch​

Mit Watch kann ein Client Änderungen an Schlüsseln oder Schlüsselpräfixen beobachten und sofort reagieren. Verwenden Sie es, um auf Konfigurationsänderungen zu reagieren, Zustandsübergänge zu überwachen oder Workflows in dem Moment auszulösen, in dem sich Daten ändern.

Watch liefert Echtzeit-Benachrichtigungen, funktioniert über verteilte Nodes hinweg und beseitigt Polling: Statt wiederholt nach Änderungen zu suchen, wird Ihre Anwendung über sie informiert. So wird aus einem System, das fragt „Hat sich etwas geändert?", eines, das reagiert, wenn es so ist.

Warum ein einheitliches Modell zählt​

Ohne einheitliches Modell gebaute verteilte Systeme sammeln tendenziell getrennte Infrastruktur an — ein System für Locking, ein anderes für Messaging und handgeschriebenen Klebecode, um sie zu koordinieren. Clustron Zaris fasst all das in einem einzigen System mit einer konsistenten API zusammen, mit integrierter Sicherheit und Lebenszyklusverwaltung. Sie interagieren mit Locks, Countern und Watch auf dieselbe Weise wie mit Daten, und sie erben dieselben Garantien.

Nächste Schritte​