it-swarm.com.de

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

Ich arbeite jetzt seit 7-8 Monaten täglich mit akka. Als ich anfing, arbeitete ich an Anwendungen und bemerkte, dass Schauspieler grundsätzlich überall im Akteursystem für die Kommunikation zwischen den meisten Objekten verwendet wurden. Also habe ich das Gleiche getan - einen anderen Schauspieler für x/y/z.

Es scheint mir, dass dies zu wahllos ist und Komplexität hinzufügt, wo es nicht benötigt wird - aber ich kann keine Diskussionen darüber finden, wo Schauspieler gegen einfache synchrone oder sogar asynchrone Logik über Futures verwendet werden sollten. Ich begann über meine Haltung nachzudenken, nachdem mein Kollege etwas Ähnliches erwähnt hatte. In jüngerer Zeit habe ich mehrere Fälle erkannt, in denen ich über eine Aufgabe nachgedacht und dann vermieden habe, einen anderen Akteur zu erstellen, weil ich in einer unveränderlichen Implementierung das gleiche Ergebnis sicher erzielen konnte - z. B. so etwas wie das Abrufen von Konfigurationswerten aus einer Datenbank oder Datei, auf die Sie nur sehr selten zugreifen und dies auch tun Warten Sie, bis das Ergebnis der tatsächliche Anwendungsfall ist.

Insbesondere scheint es mir, dass in jedem Fall, in dem Sie mit einem unveränderlichen Zustand spielen, Akteure Komplexität erzeugen und den Durchsatz begrenzen - eine reine Funktion in einem Objekt kann beispielsweise gleichzeitig ohne Risiko mit einem Grad an Parallelität aufgerufen werden Ein Akteur kann jeweils nur eine Nachricht verarbeiten. Die alternative Überlegung ist, dass Sie den Thread parken, wenn Sie auf das Ergebnis warten müssen, es sei denn, Sie verwenden Futures, aber in Fällen, in denen Sie sich keine Gedanken über asynchrone Nachrichten oder Skalierung machen müssen, scheint es möglicherweise übertrieben, einen Schauspieler zu beschäftigen.

Meine Frage ist also: Gibt es einen schlechten Zeitpunkt, um Schauspieler einzusetzen? Ich bin gespannt, wie erlang aussieht und möchte wirklich die Einsichten anderer Leute. Oder wenn es einige Prinzipien bezüglich der Verwendung von Schauspielern gibt.

61
JasonG

Dies ist eine Frage, die mich interessiert und über die ich einige Nachforschungen angestellt habe. Weitere Gesichtspunkte finden Sie in diesem Blog-Beitrag von Noel Walsh oder in dieser Frage . bei Stapelüberlauf. Ich habe einige Meinungen, die ich anbieten möchte:

  • Ich denke, dass Akka, weil es mit Nachrichten funktioniert, eine "Push-Denkweise" fördert. Bei Parallelität würde ich oft argumentieren, dass dies nicht das ist, was Sie wollen. Ziehen ist viel sicherer. Ein gängiges Muster für verteilte Systeme besteht beispielsweise darin, dass eine Gruppe von Mitarbeitern Informationen in einer Warteschlange verarbeitet . Offensichtlich ist dies in Akka möglich , aber es scheint nicht unbedingt der erste Ansatz zu sein, den Menschen versuchen . Akka bietet auch dauerhafte Postfächer an, aber auch hier kommt es darauf an, wie Sie sie verwenden - eine einzelne gemeinsam genutzte Warteschlange ist viel flexibler als Warteschlangen pro Mitarbeiter für das Ausgleichen/Wiederherstellen Arbeit zuweisen.
  • Es ist einfach, sich in die Denkweise zu versetzen, Ihre Klassen durch Schauspieler zu ersetzen. Einige Leute scheinen es sogar zu befürworten, indem sie sagen , dass Schauspieler nur eines tun sollten . Aus logischer Sicht erhöht dies die Codekomplexität, wie Jason beschreibt, denn wenn jede Klasse ein Akteur ist, sind das viele zusätzliche Nachrichten und Empfangs-/Sendeblöcke. Es macht es auch 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 für dieses Problem sind . Auch trotz Akkas legendärer Effizienz vermute ich, dass die Verbreitung von Schauspielern in Bezug auf die Leistung keine gute Idee ist - wenn wir Java] verwenden Fäden, von denen wir wissen, dass sie wertvoll sind, und bewahren sie entsprechend.
  • Es hängt mit dem vorherigen Punkt zusammen, aber ein weiteres Ärgernis ist der Verlust von Typinformationen, die Noel und Pino hervorheben, da wir für viele von uns deshalb Scala] anstelle anderer Sprachen wie Python verwenden. Es gibt einige Möglichkeiten, dies zu umgehen, aber sie sind entweder nicht standardisiert , nicht empfohlen oder experimentell .
  • Schließlich ist die Parallelität schwierig, selbst wenn Sie eine "Let it Crash" - Denkweise haben. Alternative Programmiermodelle können helfen, aber sie lassen die Probleme nicht verschwinden - sie ändern sie - deshalb ist es gut, denke formal über sie nach . Dies ist auch der Grund, warum Joe Average-Entwickler nach fertigen Tools wie RabbitMQ, Storm, Hadoop, Spark, Kafka oder NoSQL-Datenbanken) greifen. Akka verfügt über einige vorgefertigte Tools und Komponenten, was cool ist, aber es ist auch so fühlt sich ziemlich niedrig an, daher würden besser gebaute gemeinsame Elemente verteilter Systeme Entwicklern helfen und sicherstellen, dass Systeme richtig gebaut werden.

Wie Jason bin ich sehr daran interessiert, die Einsichten anderer Leute hier zu hören. Wie kann ich einige der oben genannten Probleme angehen und Akka besser nutzen?

23
Mark Butler

Es lohnt sich zu überlegen, wofür das Schauspielermodell verwendet wird: Das Schauspielermodell ist

  1. ein Parallelitätsmodell
  2. dadurch wird der gleichzeitige Zugriff auf den veränderlichen Status vermieden
  3. verwendung asynchroner Kommunikationsmechanismen zur Bereitstellung von Parallelität.

Dies ist nützlich, da die Verwendung des gemeinsam genutzten Status aus mehreren Threads sehr schwierig wird, insbesondere wenn Beziehungen zwischen verschiedenen Komponenten des gemeinsam genutzten Status bestehen, die synchronisiert werden 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 bietet das Akteurmodell nicht viel (wenn überhaupt) Nutzen.

Ich hoffe, das hilft.

21
Aidan Cully

Ihre Intuition ist richtig, IMHO. Schauspieler überall zu benutzen ist wie den sprichwörtlichen Hammer zu haben und nur Nägel zu sehen.

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, indem Sie sich die modellierte Domäne ansehen und ein wenig gesunden Menschenverstand verwenden. Ich fürchte, ich habe keine bessere Methode als diese, aber ich hoffe, es hilft.

12
Vlad Dumitrescu

In der Reihenfolge Eingabe/Ausgabe Messaging :

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

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

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

0
DHa