Verteilte Koordination in .NET
Koordination ist die Art, wie unabhängige Prozesse sich darauf einigen, wer was in welcher Reihenfolge tut und wer das Sagen hat — ohne sich gegenseitig in die Quere zu kommen. Dieser Artikel erklärt die Koordinationsprobleme, auf die verteilte .NET-Anwendungen stoßen, und die Primitive, mit denen Clustron sie löst.
Warum Koordination schwierig ist
Wenn ein Prozess die gesamte Arbeit erledigt, sind Reihenfolge und Zuständigkeit kostenlos: Es gibt nur einen Akteur. Führen Sie denselben Code als mehrere Instanzen aus, entfällt diese Garantie. Zwei Instanzen können nun denselben Job gleichzeitig versuchen, veraltete Kopien gemeinsamen Zustands lesen oder nach einem Netzwerkaussetzer beide glauben, der Leader zu sein. Ungelöst zeigen sich diese Probleme als:
- Race Conditions, wenn zwei Instanzen dieselbe Ressource gleichzeitig verändern.
- Inkonsistenter Zustand, wenn Instanzen auf unterschiedlichen Sichten der Daten arbeiten.
- Doppelte Verarbeitung, wenn mehr als eine Instanz einen Job ausführt, der nur einmal laufen soll.
- Split-Brain, wenn eine Partition dazu führt, dass zwei Instanzen jeweils als alleinige Autorität agieren.
Koordinationsprimitive sind die erprobten Bausteine, die diese Ergebnisse verhindern, sodass Sie sie nicht pro Anwendung neu implementieren müssen.
Koordinationsprimitive
Die folgenden Primitive bilden das gängige Vokabular verteilter Koordination. Jedes löst einen der oben genannten Fehlermodi.
| Primitiv | Was es garantiert | Typische Verwendung |
|---|---|---|
| Verteilter Lock | Nur ein Halter führt einen Abschnitt zur Zeit aus | Doppelte Jobausführung verhindern; einen kritischen Abschnitt schützen |
| Leader-Election | Eine Gruppe einigt sich auf einen koordinierenden Node | Einen Singleton-Scheduler betreiben; Arbeit von einer Stelle aus zuweisen |
| Transaktion | Eine Menge von Operationen wird atomar angewendet, ganz oder gar nicht | Updates über mehrere Schlüssel, die nicht teilweise greifen dürfen |
| Watch-Benachrichtigung | Clients werden über Zustandsänderungen informiert, statt zu pollen | In Echtzeit auf Konfigurations- oder Zustandsänderungen reagieren |
Wie Clustron Koordination bereitstellt
Clustron verteilt die Koordination auf zwei Schichten seiner Produktfamilie, sodass Sie die Schicht nutzen können, die zu Ihrem Problem passt.
Koordination auf Cluster-Ebene stammt von Clustron Nodus. Nodus ist der Clustering- und Messaging-Kern: Prozesse treten einem Peer-to-Peer-Cluster bei, wählen über austauschbare Strategien einen Leader, erkennen Peer-Ausfälle und tauschen typisierte Nachrichten aus — ohne externen Koordinator wie ZooKeeper oder etcd, den Sie betreiben müssten. Leader-Election und Ausfallerkennung liegen hier.
Koordination auf Datenebene stammt von Clustron Zaris. Zaris ist der verteilte Key/Value-Store. Auf gemeinsamem Zustand bietet er verteilte Locks, atomare Counter, Transaktionen, Watch-Benachrichtigungen und Leases. Diese basieren auf den Schlüsseln, der TTL und dem Lease-Lebenszyklus des Stores selbst, sodass ein Lock automatisch freigegeben wird, wenn sein Besitzer stirbt, und ein Watch ohne Polling-Schleife auslöst.
Beide greifen ineinander: Zaris clustert auf Nodus, sodass ein Zaris-Deployment unter seinen Datenprimitiven bereits Mitgliedschaft und Leader-Election mitbringt. Wenn Sie nur Cluster-Koordination brauchen — einen Scheduler nur für den Leader, einen Work Distributor —, verwenden Sie Nodus direkt. Wenn Sie gemeinsamen Zustand und die Locks und Watches brauchen, die ihn absichern, verwenden Sie Zaris.
Leader-Election ist eine Nodus-Fähigkeit. Wenn Sie Zaris betreiben, erhalten Sie sie als Teil des Clusters unter Ihrem Store; Sie müssen kein separates Wahlsystem aufsetzen.
Da diese Primitive in denselben .NET-Bibliotheken wie Ihr Datenzugriff ausgeliefert werden, können Sie verteilte Workflows, Hintergrundverarbeitungssysteme und Microservice-Koordination aufbauen, ohne einen separaten Koordinationsdienst einzuführen.