Ich lerne gerade und mag das Schauspieler-Muster wirklich. Ich benutze gerade Scala, aber ich bin interessiert an dem architektonischen Stil im Allgemeinen, wie er in Scala, Erlang, Groovy, etc. verwendet wird.
Der Fall, an den ich denke, ist, wo ich Dinge gleichzeitig tun muss, wie zum Beispiel "einen Job ausführen".
Beim Threading würde ich einen Thread-Pool und eine blockierende Warteschlange erstellen und jeden Thread die blockierende Warteschlange abfragen lassen und Jobs verarbeiten, wenn sie in die Warteschlange hinein und aus der Warteschlange kommen.
Was ist mit Schauspielern der beste Weg, damit umzugehen? Macht es Sinn, einen Pool von Akteuren zu erstellen und irgendwie Nachrichten an sie zu senden, die die Jobs enthalten? Vielleicht mit einem "Koordinator" Schauspieler?
Hinweis : Ein Aspekt des Falls, den ich vergessen habe zu erwähnen, war: Was, wenn ich die Anzahl der Jobs beschränken möchte, die meine App gleichzeitig verarbeitet? Vielleicht mit einer Konfigurationseinstellung? Ich dachte, dass ein Pool es leicht machen könnte, dies zu tun.
Danke!
Manchmal ist es sinnvoll, die Anzahl der Arbeitsprozesse, die gleichzeitig auf einer großen Aufgabenliste ausgeführt werden, zu begrenzen, da die Aufgabe, für die der Prozess ausgeführt wird, Ressourcenzuweisungen umfasst. Zumindest verbrauchen Prozesse Speicher, aber sie können auch Dateien und / oder Sockets offen halten, die dazu neigen, auf nur Tausende beschränkt zu sein und scheitern kläglich und unberechenbar, sobald Sie ausgehen.
Um einen Pull-driven Task-Pool zu haben, kann man N verknüpfte Prozesse erzeugen, die nach einer Aufgabe fragen, und ihnen eine Funktion geben, die sie spawn_monitor können. Sobald der überwachte Prozess beendet ist, kommen sie für die nächste Aufgabe zurück. Spezifische Bedürfnisse treiben die Details, aber das ist der Grundriss eines Ansatzes.
Der Grund dafür, dass jede Aufgabe einen neuen Prozess hervorbringt, liegt darin, dass Prozesse einen gewissen Status haben und es nett ist, einen sauberen Plan zu starten. Es ist eine häufige Feinabstimmung, um die Min-Heap-Größe von Prozessen einzustellen, die angepasst werden, um die Anzahl von GCs zu minimieren, die während ihrer Lebensdauer benötigt werden. Es ist auch eine sehr effiziente Speicherbereinigung, um den gesamten Speicher für einen Prozess freizugeben und mit einem neuen für die nächste Aufgabe zu beginnen.
Fühlt es sich komisch an, die doppelte Anzahl solcher Prozesse zu verwenden? Es ist ein Gefühl, das Sie in Erlang Programmierung überwinden müssen.
Ein Pool ist ein Mechanismus, den Sie verwenden, wenn die Kosten für die Erstellung und das Abbauen einer Ressource hoch sind. In Erlang ist dies nicht der Fall, also sollten Sie keinen Pool pflegen.
Sie sollten Prozesse erzeugen, wenn Sie sie brauchen, und sie zerstören, wenn Sie damit fertig sind.
Es gibt keinen besten Weg für alle Fälle. Die Entscheidung hängt von der Anzahl, Dauer, Ankunft und der erforderlichen Ausführungszeit der Aufträge ab.
Der offensichtlichste Unterschied zwischen dem bloßen Abspringen von Schauspielern und dem Verwenden von Pools ist, dass im ersten Fall Ihre Jobs fast gleichzeitig beendet werden, während im letzteren Fall die Bearbeitungszeiten zeitlich verteilt werden. Die durchschnittliche Bearbeitungszeit ist jedoch die gleiche.
Der Vorteil der Verwendung von Schauspielern ist die Einfachheit der Codierung, da keine zusätzliche Handhabung erforderlich ist. Der Kompromiss besteht darin, dass Ihre Schauspieler um Ihre CPU-Kerne konkurrieren. Sie können nicht mehr parallele Jobs als CPU-Kerne (oder HTs, was auch immer) haben, egal welches Programmierparadigma Sie verwenden.
Stellen Sie sich als Beispiel vor, dass Sie 100'000 Jobs ausführen müssen, die jeweils eine Minute dauern und die Ergebnisse im nächsten Monat fällig sind. Sie haben vier Kerne. Würden Sie 100'000 Schauspieler spawnen, die jeweils für einen Monat über die Ressourcen konkurrieren, oder würden Sie Ihre Jobs einfach anstellen und vier gleichzeitig ausführen?
Stellen Sie sich als Gegenbeispiel einen Webserver vor, der auf demselben Computer ausgeführt wird. Wenn Sie fünf Anfragen haben, würden Sie es vorziehen, vier Benutzer in T-Zeit und eine in 2T zu bedienen oder alle fünf in 1.2T-Zeit zu bedienen?
Tags und Links scala concurrency actor erlang