Wann man dazu greift
- Nebenläufigkeit und Isolation kritisch sind.
- Agenten ihren eigenen internen Zustand besitzen.
- Skalierung über unabhängige Einheiten erfolgen soll.
/pattern/actor-model/
Agenten oder Komponenten laufen als unabhängige Actors: jeder besitzt seinen privaten Zustand, verarbeitet jeweils eine Nachricht aus seinem Postfach und kann weitere Actors erzeugen — so gibt es keine Shared-Memory-Konkurrenz und ein Absturz bleibt auf einen einzelnen Actor begrenzt.
In der PraxisEin Hochdurchsatz-Dokumentenverarbeitungssystem weist jede hochgeladene Datei einem unabhängigen Actor zu, sodass ein Absturz im verarbeitenden Actor einer Datei die anderen parallel laufenden niemals beeinträchtigt.
Wann man dazu greift
Wann es nach hinten losgeht
Die Abwägung
Starke Isolation und Skalierbarkeit werden auf Kosten komplexerer Nachrichten- und Fehlersemantik gewonnen.
Isolierte Actors tauschen Nachrichten aus, um sich abzustimmen.
Ein Actor stürzt zwischen Empfang und Bestätigung ab. Die Nachricht verschwindet; der Sender glaubt, sie wurde verarbeitet; das System verliert lautlos Arbeit.
Lösung · Mindestens-einmal-Zustellung mit idempotenten Handlern verwenden oder das Postfach vor der Verarbeitung persistieren. Nachrichtenverlust zu einem sichtbaren Fehler machen, nicht zu einem stillen.
Ein Actor verbraucht Nachrichten langsamer als sie eintreffen. Sein Postfach schwillt an, bis der Speicher erschöpft ist, und die Backlog-Latenz kaskadiert zu allen, die auf seine Antworten warten.
Lösung · Postfächer begrenzen und bei Überlauf Backpressure oder Load-Shedding anwenden; die Warteschlangentiefe pro Actor überwachen und skalieren oder abwerfen, bevor daraus ein Ausfall wird.
Weitermachen
Patterns, Frameworks und Seiten durchsuchen.