Distributed Systems Basics in Erlang

Was sich aendert, wenn ein System verteilt wird

Auf einer Maschine bleiben viele Annahmen unsichtbar. Ueber mehrere Maschinen hinweg werden sie Teil des Problems. Antworten koennen spaet kommen, Nodes koennen wegfallen, ein Request kann remote erfolgreich sein, waehrend der Aufrufer lokal in den Timeout laeuft. Deshalb darf verteiltes Denken nicht einfach von lokalem Code uebernommen werden.

Die erste Lektion fuer Anfaenger ist daher nicht „Node-Syntax auswendig lernen“, sondern „Ausfall und Verzoegerung als normale Design-Eingaben behandeln“. Das macht verteiltes Erlang realistisch.

Nodes und Remote Messaging

Ein Node ist eine laufende Erlang-Instanz, die mit anderen Instanzen kommunizieren kann, wenn Namen und Erreichbarkeit stimmen. Remote Messaging sieht syntaktisch oft einfach aus. Genau das ist Staerke und Gefahr zugleich. Die Syntax ist leicht, die Betriebsannahmen dahinter nicht.

Deshalb sollte jedes Remote-Beispiel sofort mit einer Frage verbunden werden: was passiert, wenn keine Antwort kommt? Was passiert bei Node-Ausfall? Wie reagiert der Caller dann?

{service, 'worker@host'} ! ping.
receive
    reply -> ok
after 2000 ->
    timeout
end.

Warum Timeouts in den ersten Entwurf gehoeren

Ein Timeout ist kein Spaet-Patch, sondern Teil des Protokolls. Wenn eine Antwort remote spaet oder gar nicht kommen kann, braucht der Caller eine definierte Reaktion. Retry, Logging, Fehler rueckgeben oder Eskalation sind Designentscheidungen.

Genau hier unterscheidet sich verteiltes Denken vom lokalen. Ein robustes verteiltes System plant den schwierigen Pfad von Anfang an ein.

Typische Anfaengerfehler bei verteiltem Erlang

Ein haeufiger Fehler ist, Verteilung zu frueh einzubauen, bevor das Modell auf einem Node sauber ist. Ein anderer ist, Remote-Beispiele ohne Timeout-Handling zu schreiben. Ausserdem wird Netzwerkausfall oft wie ein Ausnahmefall statt wie ein normaler Systemzustand behandelt.

Die staerkste Uebung ist, Erfolgs- und Fehlerpfad nebeneinander zu designen. Wenn ein entfernter Node wegfaellt, was ist dann nur verzoegert, was kann retryen und was muss sauber stoppen? Genau diese Fragen fuehren zu besseren Systemen.

Was du danach tun solltest

• Einen receive-Block um einen Timeout erweitern.
• Einen Remote-Fehler und eine passende Reaktion benennen.
• Das Ein-Node-Design erst sauber machen, dann verteilen.
• Danach das Abschlussprojekt bauen.

Hauefige Fragen