Akka- und Singleton-Darsteller

Question

Ich habe kürzlich angefangen, mit Akkas Schauspielern und http-Modulen herumzualbern. Ich bin jedoch auf eine ziemlich nervige kleine Eigenart gestoßen, nämlich Singleton-Schauspieler zu erschaffen.

Hier sind zwei Beispiele:

1)

Ich habe einen In-Memory-Cache, mein Dienst recht klein ist (seine eine App eher), damit ich mag diese in Speichermodell. Ich kann die meisten Informationen halten, die für den Benutzer in einer Map relevant sind (naja, eine Liste von Listen, aber immer noch recht einfach über die Struktur zu begründen) und ich bekomme nicht den Overhead und die Komplexität einer Redis, Geode oder Aerospike.

Das einzige Problem ist, dass diese In-Memory-Chache geändert werden kann, durch mehrere Quellen und diese Änderungen müssen synchron sein. Anstatt alle 3 Zugriffsmethoden für diese Struktur zu synchronisieren (zB durch Erstellen einer Nachrichtenwarteschlange oder das Implementieren von Sperren), dachte ich, ich würde die Struktur und ihre Zugriffsmethoden einfach in einen Akteur einfügen, Nachrichtenwarteschlange erstellen, einfache Empfangs-> Sendelogik und Wenn Dinge größer werden, wird es sehr einfach sein, sie mit einem DA-Darsteller über einen dedizierten in db zu ersetzen.

2) Ich habe eine "Service" Schicht, die verwendet werden soll, um Akteure für verschiedene Jobs zu versenden (Zugriff auf die Datenbank, Zugriff auf den In-Memory-Cache, diese Berechnung mit Daten und das Ergebnis an den Benutzer liefern ...) etc).

Es macht Sinn, dass diese Service-Schicht ein "Singleton" ist, eine Schließung über einige Funktionen, da sie nichts blockiert oder CPU-/Speicherintensiv in irgendeiner Weise ist, sie weist einfach Aufgaben weiter unten zu (zB entscheidet, wie viele Akteure/Thread/wir geschaffen werden sollte, und wenn ein Antrag gehen sollte)

dies würde jedoch Sache entweder erfordern:

a) machen beide Objekt Singleton Schauspieler oder

b) Herstellung beide Objekte tatsächliche "Objekte" (wie in der Scala-Objektnotation, die einen einzelnen benannten Singleton mit fu bezeichnet Diese Probleme haben viele Probleme mit b), nämlich dass die Serviceebene entweder ein Darstellersystem "durchlaufen" muss (und ich bin mir nicht sicher, ob das eine Best Practice ist)) Um Akteure zu schaffen, anstatt eigene "Kinder" zu schaffen, wird es Kinder schaffen, die das globale Akteurs-System verwenden, und die Nachrichten- und Überwachungslogik wird viel unbeholfener und nicht intuitiver sein. Auch, dass der In-Memory-Cache nicht den Vorteil der eingebauten Message-Queue hat (ich sage nicht, dass es schwer ist, einen zu implementieren, aber dies scheint eine der Situationen zu sein, in der man "Oh, lustig, das ist gut Ich habe Schauspieler und ich muss keine Zeit damit verbringen, diesen Code zu implementieren und zu testen ")

a) scheint das Problem zu haben, in der akka-Dokumentation allgemein schlecht dokumentiert und unangemessen zu sein. Ich meine:

http://doc.akka.io/docs/akka/2.4/scala/cluster-singleton.html

Schauen Sie sich diese Scheiße, die Hälfte der Dokumente gegen die Verwendung sie warnen, war es seine eigene Abhängigkeit und ganz seiner offen sehr hart für eine arme Sau wie mich zu lesen, das nicht Setzen Sie den Fuß in die funktionale & gleichzeitige Programmierung Elfenbeinturm.

Also, ahm. Kann jemand von euch mir erklären, warum es schlecht ist, Singleton-Darsteller zu benutzen? Wie entwirfst du Singletons, wenn sie keine Schauspieler sein können? Gibt es eine Möglichkeit Singleton Actors zu entwickeln, die keinen großen Schaden anrichten?Ist das ganze "Service" -Modell, "globale" Services zu haben, eher "instantated instanziiert" als "un akka like"?

Answer 1

Nur um die Dokumentation zu verdeutlichen, warnen sie nicht vor der Verwendung. Sie warnen davor, dass es Umstände gibt, in denen die Verwendung eines Singletons Probleme verursacht, die unter den gegebenen Umständen erwartet werden. Sie erwähnen die folgenden Situationen:

• Wenn das Singleton ein Leistungsengpass ist. Das macht Sinn. Wenn alles auf ein einzelnes Objekt angewiesen ist, das langsam arbeitet, wird alles langsam sein.
• Wenn der Actor non-stop verfügbar sein muss, treten Probleme auf, wenn das Singleton jemals untergeht, da diese Nachrichten nicht einfach von einer anderen Instanz verarbeitet werden können. Es wird einige Zeit brauchen, um den Singleton neu zu starten, bevor seine Arbeit wieder aufgenommen werden kann.
• Das größte Problem tritt auf, wenn Sie Auto-Down aktiviert haben. Auto-Downing ist eine Richtlinie, bei der davon ausgegangen wird, dass ein nicht erreichbarer Knoten inaktiv ist und aus dem Netzwerk entfernt wird. Wenn Sie dies tun, aber der Knoten nicht wirklich down ist, aber aufgrund einer Netzwerkpartition nur unerreichbar ist, werden beide Seiten der Partition entscheiden, dass sie die überlebenden Knoten sind und ihre eigenen Singletons erstellen. So, jetzt hast du zwei Singletons. Das ist natürlich nicht das, was du von einem Singleton willst. Aber Sie sollten das automatische Herunterfahren nie außerhalb des Tests verwenden. Es ist eine schreckliche Wiederherstellungsstrategie, die aus Gründen der Vollständigkeit und Bequemlichkeit beim Testen enthalten war.

So lese ich das nicht als Empfehlung gegen die Verwendung. Nur über die erwarteten Fallstricke klar sein, wenn Sie es verwenden, basierend auf der Art der Struktur.