Loading content
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 Impl…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was du verstehen musst, um ein Themenfeld sinnvoll zu denken.
Das Actor Model beschreibt nebenläufige Systeme als Menge isolierter Akteure mit eigenem Zustand. Sie reagieren auf Nachrichten, ändern nur ihren privaten Zustand und koordinieren sich ohne geteilten Speicher.
Das Modell wurde 1973 in Arbeiten von Carl Hewitt, Peter Bishop und Richard Steiger formuliert. Es entstand aus dem Problem, viele unabhängige Recheneinheiten auf Maschinen mit lokaler Speicherung und hoher Parallelität zu koordinieren, ohne Lock-basierte Synchronisation oder geteilte Variablen. Nachrichten statt Speicherzugriff machen die Interaktion explizit und eignen sich für Systeme, die isolierte Verarbeitung und verteilte Kontrolle brauchen.
Stell dir ein Actor-System als Reihe abgeschlossener Arbeitsräume vor, in denen jeweils nur eine Einheit zur Zeit handelt. Jeder Raum hat ein Postfach und einen privaten Zustand. Nachrichten kommen asynchron an, werden nacheinander verarbeitet, können den Zustand verändern und neue Actors anstoßen. Abstimmung entsteht durch Weitergeben von Nachrichten, nicht durch direkten Zugriff auf fremde Daten.
Actors beeinflussen sich ausschließlich über Nachrichten; direkte Speicherzugriffe entfallen.
Mehrere Actors können unabhängig und gleichzeitig arbeiten, ohne sich über gemeinsame Variablen zu blockieren.
Jeder Actor verwaltet seinen eigenen Zustand und hält ihn gegenüber anderen Akteuren abgeschirmt.
Nachrichten werden gepuffert und geordnet verarbeitet, statt direkt in Aufrufe übersetzt zu werden.
Fehler lassen sich eher auf einzelne Actors oder eine Überwachungshierarchie begrenzen, wenn Wiederanlauf bewusst modelliert ist.
Das Modell ist nützlich für verteilte Dienste, Echtzeit-Workflows und Systeme mit vielen unabhängigen Aufgaben oder Störungen. Es reduziert Lock-Konkurrenz und erleichtert Skalierung, verlangt aber klare Nachrichtenverträge, idempotente Verarbeitung und ein bewusstes Fehlerdesign; globale Konsistenz und synchrone Abstimmung werden dafür aufwendiger.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.