Actor Model
Ein Konzept zur Modellierung nebenläufiger und verteilter Systeme durch isolierte, zustandsbehaftete Akteure, die ausschließlich per asynchroner Nachricht interagieren.
Klassifikation
- KomplexitätHoch
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Ungedachte Fehlerszenarien können zu versteckten Neustart-Schleifen führen.
- Übermäßiges Messaging kann zu Leistungsengpässen und Backpressure führen.
- Falsche Partitionierung von Verantwortung erzeugt inkonsistente Zustände.
- Begrenze Actor-Zustand auf das notwendige Minimum.
- Nutze Supervisoren klar strukturiert und dokumentiert.
- Implementiere Observability (Metriken, Tracing) für Mailbox- und Restart-Raten.
I/O & Ressourcen
- Anforderungen an Nebenläufigkeit und Fehlertoleranz
- Ereignis- oder Nachrichtenquellen
- Laufzeitumgebung mit Actor-Implementierung (z. B. Akka, Erlang, Orleans)
- Isolierte, zustandsbehaftete Komponenten
- Verbesserte Fehlertoleranz durch Supervisor-Strategien
- Skalierbare Message-Processing-Pipelines
Beschreibung
Das Actor Model ist ein fundamentales Berechnungsmodell für nebenläufige und verteilte Systeme. Es modelliert Akteure als isolierte, zustandsbehaftete Einheiten, die durch asynchrone Nachrichten kommunizieren. Es erleichtert Skalierung, Fehlertoleranz und lose Kopplung, erfordert aber bewusstes Design von Zustandsmanagement und Fehlerstrategien. Häufige Implementierungen nutzen Mailboxen, Supervisor-Hierarchien und fehlertolerante Muster.
✔Vorteile
- Skalierbarkeit durch lose Kopplung und unabhängige Ausführungsinstanzen.
- Verbesserte Fehlereindämmung durch Supervisor-Hierarchien.
- Klares Mentalmodell für nebenläufige Prozesse und Zustandsverwaltung.
✖Limitationen
- Zustandsmanagement über viele Akteure hinweg kann komplex werden.
- Verteilte Konsistenz und Transaktionen sind nicht automatisch gelöst.
- Debugging asynchroner Nachrichtenflüsse erfordert spezialisierte Tools.
Trade-offs
Metriken
- Mailbox-Latenz
Mittlere Zeit zwischen Nachrichteneingang und -bearbeitung.
- Actor-Neustart-Rate
Anzahl der Neustarts pro Actor pro Zeiteinheit.
- Durchsatz pro Actor-Typ
Verarbeitete Nachrichten pro Sekunde für einen Actor-Typ.
Beispiele & Implementierungen
Erlang/OTP Supervisors
Erlang implementiert Actor-ähnliche Prozesse mit Supervisor-Bäumen zur Fehlereindämmung.
Akka (JVM) Actor-System
Akka bietet ein skalierbares Actor-Framework mit Typed Actors und Supervisor-Strategien.
Orleans (Microsoft) Virtual Actors
Orleans nutzt das Virtual-Actor-Modell für vereinfachte Lebenszyklusverwaltung und Skalierung.
Implementierungsschritte
Konzeption: Grenzen von Akteuren und Nachrichtenfluss definieren.
Prototyp: kritische Komponenten als Actors implementieren und messen.
Sicherung: Supervisor-Strukturen und Persistenz-/Snapshot-Strategien einführen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unzureichende Snapshot- und Migrationsstrategien für Actor-Zustand.
- Ad-hoc Supervisor-Regeln ohne Tests und Rollback-Pläne.
- Keine standardisierte Nachrichtenformatierung führt zu Kompatibilitätsproblemen.
Bekannte Engpässe
Beispiele für Missbrauch
- Verwendung von Actors als Ersatz für fehlende Transaktionslogik.
- Persistenz von großen Zuständen direkt in Actor-Speicher statt externalisieren.
- Fehlerhafte Supervisor-Konfiguration, die wiederholte Neustarts erzeugt.
Typische Fallen
- Unterschätze Latenz bei verteilten Nachrichtenwegen.
- Ignoriere Backpressure-Strategien bei hohen Lasten.
- Vernachlässige Monitoring und Alerting für Neustart-Raten.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Keine eingebauten verteilten Transaktionen; externe Koordination nötig.
- • Abhängigkeit von Laufzeit für Mailbox- und Supervisor-Verhalten.
- • Latenz und Durchsatz werden durch Messaging-Infrastruktur begrenzt.