Wenn Anwendungen über mehrere Rechner skalieren, wird die Koordination zu einem der schwierigsten Probleme.
Verteilte Systeme betreiben oft mehrere identische Nodes, die alle dieselbe Arbeit verrichten können. Ohne Koordination versuchen diese Nodes möglicherweise gleichzeitig dieselbe Aufgabe auszuführen, was zu doppelter Arbeit, Race Conditions oder inkonsistentem Zustand führt.

Eine der gängigsten Methoden, dieses Problem zu lösen, ist die Leader-Election.

Die Leader-Election stellt sicher, dass ein Node vorübergehend zum Leader wird, während die übrigen Nodes Follower bleiben. Der Leader übernimmt Koordinationsaufgaben, während die Follower auf einen Wechsel der Führung warten.

Dieses Muster wird breit eingesetzt in verteilten Datenbanken, Job-Schedulern, Container-Orchestrierungsplattformen und Konfigurationssystemen.

---

---

Ein einfaches Beispiel

Stellen Sie sich ein verteiltes Worker-System mit drei Nodes vor:

Worker A Worker B Worker C

Jeder Worker kann Hintergrundjobs ausführen.

Führen alle Worker denselben geplanten Job aus, läuft er dreimal.
Stattdessen soll genau ein Worker den Job ausführen.

Hier kommt die Leader-Election ins Spiel. Ein Worker wird zum Leader, und nur der Leader führt den Job aus.

---

Das einfachste Leader-Election-Muster

Ein gängiger Ansatz nutzt einen gemeinsamen Koordinations-Store.

Die Idee ist einfach:

1. Jeder Node versucht, die Führung zu übernehmen.
2. Der Node, dem das gelingt, wird zum Leader.
3. Der Leader erneuert seine Führung regelmäßig.
4. Fällt der Leader aus, übernimmt ein anderer Node.

Typischerweise wird dies mit einem Lease umgesetzt.

Ein Lease funktioniert wie ein Lock mit Ablaufzeit. Verschwindet der Node, der den Lease hält, kann ein anderer Node die Führung gefahrlos übernehmen.

---

Ein minimales .NET-Beispiel

Das folgende vereinfachte Beispiel zeigt die Idee hinter Lease-basierter Führung.

public class LeaderElection
{
    private readonly ILeaseStore _store;
    private readonly string _nodeId;

    public LeaderElection(ILeaseStore store, string nodeId)
    {
        _store = store;
        _nodeId = nodeId;
    }

    public async Task RunAsync()
    {
        while (true)
        {
            var acquired = await _store.TryAcquireLeaseAsync("cluster-leader", _nodeId, TimeSpan.FromSeconds(10));

            if (acquired)
            {
                Console.WriteLine($"{_nodeId} is leader");

                await PerformLeaderWork();

                await _store.RenewLeaseAsync("cluster-leader", _nodeId);
            }

            await Task.Delay(2000);
        }
    }

    private Task PerformLeaderWork()
    {
        Console.WriteLine("Running scheduled tasks...");
        return Task.CompletedTask;
    }
}

In diesem Beispiel gilt:

• Jeder Node versucht, den Lease "cluster-leader" zu erwerben.
• Der Node, dem das gelingt, wird zum Leader.
• Der Leader erneuert den Lease regelmäßig.
• Stürzt der Leader ab, läuft der Lease ab, und ein anderer Node übernimmt.

Dieses Muster bietet automatisches Failover.

---

Probleme bei selbstgebauter Leader-Election

Obwohl das obige Beispiel einfach aussieht, bringen reale verteilte Systeme Komplikationen mit sich:

Netzwerkpartitionen können dazu führen, dass Nodes glauben, noch Leader zu sein.

Clock Drift kann Probleme beim Ablauf von Leases verursachen.

Eine langsame Fehlererkennung kann den Wechsel der Führung verzögern.

Einen robusten Leader-Election-Mechanismus zu bauen, erfordert den sorgfältigen Umgang mit den Randfällen verteilter Systeme.

Deshalb setzen viele Systeme auf spezialisierte Koordinationsplattformen wie:

• etcd
• ZooKeeper
• Consul

Diese Systeme implementieren zuverlässige Koordinationsprimitive.

---

Leader-Election mit Clustron

Clustron bietet eine Clustering-Plattform für verteilte Systeme in .NET.

Statt Koordinationsinfrastruktur selbst zu bauen, können Anwendungen die integrierten Primitive der Plattform nutzen.

Beispiel mit dem Lease-Konzept von Clustron:

using Clustron.DKV.Client;

var client = await DKVClient.InitializeRemote(
    "teststore",
    new[] { new DkvServerInfo("localhost", 7861) });

var lease = await client.GrantLeaseAsync(TimeSpan.FromSeconds(10));

if (lease.Acquired)
{
    Console.WriteLine("This node is the leader.");

    while (true)
    {
        await client.RefreshLeaseAsync(lease.Id);
        await Task.Delay(3000);
    }
}

Hier fordert der Node einen Lease vom Cluster an.

Wird der Lease gewährt, wird der Node zum Leader.
Solange der Node den Lease aktualisiert, bleibt die Führung gültig.

Stürzt der Node ab oder erneuert er den Lease nicht mehr, kann ein anderer Node die Führung automatisch übernehmen.

---

Wann Leader-Election nützlich ist

Leader-Election tritt in vielen realen verteilten Systemen auf:

• Verteilte Job-Scheduler
• Verarbeitung von Hintergrundaufgaben
• Cluster-Manager
• Koordination von Microservices
• Konfigurations-Controller

Immer wenn ein System genau einen Node zur Koordination der Aktivitäten benötigt, wird die Leader-Election unverzichtbar.

---

Zusammenfassung

Die Leader-Election ist ein grundlegender Baustein verteilter Systeme.

Sie ermöglicht es Node-Clustern, ihr Verhalten zu koordinieren und dabei Hochverfügbarkeit zu wahren.

Ein Lease-basierter Ansatz bietet eine einfache und wirksame Implementierungsstrategie, und verteilte Plattformen wie Clustron stellen diese Primitive direkt für .NET-Anwendungen bereit.

Statt Koordinationslogik von Grund auf zu bauen, können sich Entwickler auf das Anwendungsverhalten konzentrieren, während die Clustering-Plattform Führung, Failover und Koordination übernimmt.