Wann ist es NICHT gut, Schauspieler in akka / erlang einzusetzen?

Ich arbeite jetzt täglich seit 7-8 Monaten mit akka. Als ich anfing, arbeitete ich an Anwendungen und bemerkte, dass Akteure im Prinzip irgendwo innerhalb des Aktorsystems für die Kommunikation zwischen den meisten Objekten verwendet wurden. Also habe ich das gleiche getan - einen anderen Schauspieler für x / y / z aufdrehen.

Es scheint mir, dass dies zu wahllos ist und die Komplexität dort erhöht, wo es nicht benötigt wird - aber ich kann keine Diskussionen darüber finden, wo Akteure gegen reine synchrone oder sogar asynchrone Logik über Futures eingesetzt werden sollten. Ich dachte über meine Haltung nach, nachdem mein Kollege etwas Ähnliches erwähnt hatte. In letzter Zeit habe ich mehrere Fälle erkannt, in denen ich über eine Aufgabe nachgedacht habe und es dann vermieden habe, einen anderen Akteur zu erstellen, weil ich in einer unveränderlichen Implementierung sicher das gleiche Ergebnis erzielen konnte - z. B. Konfigurationswerte von einer Datenbank oder einer Datei abrufen, auf die Sie nur sehr selten zugreifen Warten Sie, bis das Ergebnis der tatsächliche Anwendungsfall ist.

Insbesondere scheint es mir, dass in jedem Fall, in dem Sie mit unveränderlichen Zuständen spielen, Akteure Komplexität erzeugen und den Durchsatz begrenzen - eine reine Funktion in einem Objekt kann zum Beispiel gleichzeitig aufgerufen werden, ohne dass ein Risiko für eine Nebenläufigkeitsstufe besteht Ein Akteur kann jeweils nur eine Nachricht verarbeiten. Die andere Überlegung ist, dass Sie den Thread parken, wenn Sie auf das Ergebnis warten müssen, es sei denn, Sie beginnen mit der Verwendung von Futures. In Fällen, in denen Sie sich nicht um asynchrone Nachrichten oder Skalierung kümmern müssen, scheint es übertrieben zu sein, einen Schauspieler einzustellen.

Meine Frage ist also: Gibt es eine schlechte Zeit, um Schauspieler einzusetzen? Ich bin neugierig, wie erlang aussieht und würde gerne die Einsicht anderer Menschen haben. Oder ob es einige Prinzipien gibt, die sich mit der Verwendung von Schauspielern befassen.

Dies ist eine Frage, die mich interessiert und an der ich einige Untersuchungen durchgeführt habe. Weitere Informationen finden Sie in diesem Blogbeitrag von Noel Walsh oder in dieser Frage zum Stapelüberlauf. Ich habe einige Meinungen, die ich anbieten möchte:

• Ich denke, Akka, weil es mit Nachrichten funktioniert, fördert eine "Push-Denkweise". Aus Gründen der Parallelität würde ich oft argumentieren, dass dies nicht das ist, was Sie wollen. Ziehen ist viel sicherer. Beispielsweise besteht ein gängiges Muster für verteilte Systeme darin, dass eine Gruppe von Mitarbeitern Informationen in einer Warteschlange verarbeitet . Natürlich ist dies in Akka möglich, aber es scheint nicht unbedingt der erste Ansatz zu sein, den die Leute versuchen . Akka bietet auch dauerhafte Postfächer an, aber es hängt auch davon ab, wie Sie sie verwenden - eine einzelne gemeinsam genutzte Warteschlange ist viel flexibler als Warteschlangen pro Mitarbeiter zum Ausgleichen / erneuten Zuweisen von Arbeit.
• Es ist ganz einfach, Ihre Klassen durch Schauspieler zu ersetzen. In der Tat scheinen einige Leute es sogar zu befürworten, indem sie sagen, Schauspieler sollten nur eine Sache tun . Aus logischer Sicht erhöht dies die Komplexität des Codes, wie Jason beschreibt, denn wenn jede Klasse ein Schauspieler ist, bedeutet dies eine Menge zusätzlicher Nachrichten und Empfangs- / Sendeblöcke. Außerdem wird es schwieriger, den Code zu verstehen und zu testen, da Sie die Formalität der Schnittstellen verlieren - und ich bin nicht davon überzeugt, dass Kommentare eine Lösung dafür sind . Auch trotz Akkas legendärer Effizienz bin ich der Meinung, dass die Verbreitung von Darstellern keine gute Idee ist - wenn wir Java-Threads verwenden, wissen wir, dass sie wertvoll sind und bewahren sie entsprechend auf.
• Es hat etwas mit dem vorherigen Punkt zu tun, aber ein weiteres Ärgernis ist der Verlust von Typinformationen, die Noel und Pino hervorheben, da für viele von uns Scala statt anderer Sprachen wie Python verwendet wird. Es gibt einige Möglichkeiten, um dies zu umgehen, aber sie sind entweder nicht standardgemäß , nicht empfohlen oder experimentell .
• Schließlich ist die Parallelität auch dann schwierig , wenn Sie die Einstellung "Absturz zulassen" haben . Alternative Programmiermodelle können helfen, aber sie lassen die Probleme nicht verschwinden - sie ändern sie - deshalb ist es gut, formal darüber nachzudenken . Joe Average-Entwickler greifen deshalb auch auf fertige Tools wie RabbitMQ-, Storm-, Hadoop-, Spark-, Kafka- oder NoSQL-Datenbanken zurück. Akka hat einige vorgefertigte Tools und Komponenten, was cool ist, aber es fühlt sich auch ziemlich niedrig an, so dass fertigere gemeinsame Elemente verteilter Systeme Entwicklern helfen und sicherstellen würden, dass Systeme richtig erstellt werden.

Wie Jason bin ich sehr gespannt auf die Einsichten anderer Leute. Wie kann ich einige der oben genannten Probleme lösen und Akka besser nutzen?

Es lohnt sich zu überlegen, wofür das Darstellermodell verwendet wird: das Darstellermodell

1. ein Parallelitätsmodell
2. das vermeidet den gleichzeitigen Zugriff auf den veränderlichen Zustand
3. Verwenden von asynchronen Kommunikationsmechanismen zur Bereitstellung von Parallelität.

Dies ist hilfreich, da die Verwendung des gemeinsam genutzten Status mehrerer Threads sehr schwierig wird, insbesondere wenn Beziehungen zwischen verschiedenen Komponenten des gemeinsam genutzten Status bestehen, die synchronisiert bleiben müssen. Wenn Sie jedoch Domänenkomponenten haben, in denen:

• Sie erlauben keine Parallelität, ODER
• Sie erlauben keinen veränderlichen Zustand (wie bei der funktionalen Programmierung) ODER
• Sie müssen sich auf einen synchronen Kommunikationsmechanismus verlassen,

dann wird das Schauspielermodell nicht viel (wenn überhaupt) Nutzen bringen.

Ich hoffe, das hilft.

Ihre Intuition ist richtig, IMHO. Überall Schauspieler einzusetzen ist, als hätte man den sprichwörtlichen Hammer und sieht nur Nägel.

Die bewährte Methode von Erlang besteht darin, Prozesse / Akteure für alle Aktivitäten zu verwenden, die gleichzeitig stattfinden. Das heißt, genau wie im wirklichen Leben. Manchmal ist es schwierig, die richtige Granularität zu finden, aber meistens wissen Sie es nur, wenn Sie sich die modellierte Domäne ansehen und ein wenig gesunden Menschenverstand verwenden. Ich fürchte, ich habe keine bessere Methode, aber ich hoffe, es hilft.

In der Reihenfolge Eingabe / Ausgabe von Nachrichten:

Ich habe kürzlich eine akka-basierte Anwendung kennengelernt, bei der das Actor-Modell tatsächlich Parallelitätsprobleme verursachte. Ein einfacheres Modell hätte unter Last besser gereicht.

Das Problem bestand darin, dass sich die eingehenden Nachrichten auf verschiedenen „Spuren“ bewegten (über verschiedene Akteurspfade), der Code jedoch davon ausging, dass die Nachrichten in der gleichen Reihenfolge an ihrem endgültigen Ziel ankamen, in der sie ankamen. Solange Daten mit ausreichend großen Intervallen eintrafen, funktionierte dies, da nur eine einzige widersprüchliche Nachricht zum Ziel raste. Als die Intervalle abnahmen, kamen sie nicht mehr in Ordnung und verursachten seltsames Verhalten.

Das Problem hätte mit ein bisschen weniger Schauspielern richtig gelöst werden können, aber es ist ein leichter Fehler, wenn man sie überbeansprucht.

Meiner Meinung nach gibt es zwei Anwendungsfälle für Schauspieler. Gemeinsame Ressourcen wie Ports und dergleichen und großer Zustand. Der erste Punkt ist in der Diskussion bisher gut behandelt worden, aber der große Staat ist auch ein triftiger Grund.

Eine große Struktur, die mit jedem Prozeduraufruf übergeben wird, kann viel Stapel beanspruchen. Dieser Status kann in einen separaten Prozess gestellt, die Struktur durch eine Prozess-ID ersetzt und dieser Prozess nach Bedarf abgefragt werden.

Man kann sich Datenbanken wie Mnesia so vorstellen, dass sie den Status außerhalb des Abfrageprozesses speichern.