Guter Anwendungsfall für Akka [geschlossen]

605

Ich habe viel über das Akka- Framework (Java / Scala-Serviceplattform) schwärmen hören , aber bisher nicht viele Beispiele für Anwendungsfälle gesehen, für die es gut wäre. Ich würde mich also interessieren, was Entwickler erfolgreich damit gemacht haben.

Nur eine Einschränkung: Bitte schließen Sie den Fall des Schreibens eines Chat-Servers nicht ein. (warum? da dies als Beispiel für viele ähnliche Dinge überstrapaziert wurde)

StaxMan
quelle
10
Ist es nicht einfacher, mit dem Problem zu beginnen und eine Lösung dafür zu finden, als eine Lösung zu haben und ein Problem zu suchen, auf das es angewendet werden kann? Ich vermute, dass Akka und seine Schauspieler stattdessen mit RMI viel einfacher / einfacher Code schreiben können.
Kennet
67
Ja, wenn ich ein bestimmtes Problem zu lösen hätte. Ich suche keineswegs nach einer "Ausrede, um Akka zu benutzen", aber ich bin daran interessiert, etwas mehr zu lernen. Dies kann auch zur Lösung zukünftiger Probleme beitragen, ist jedoch hauptsächlich für den laufenden Lernprozess gedacht.
StaxMan
Es gibt verwandte Fragen, aber über die Anwendung von AKKA für bestehende Anwendungen + einige Anwendungsfälle: stackoverflow.com/questions/16595685/…
ses
2
Akka ist eine bessere Lösung als JMS oder ein verteiltes Message-Warteschlangensystem im MQ-Stil. Das ist der beste Weg, es für mich selbst zu verstehen, der kürzlich genau die gleiche Frage gestellt hat: "Ich verstehe, wie man es benutzt und sehe, wo ich es benutzen kann, aber ich kann nicht sehen, wo dies einen echten Vorteil bringen würde." Die Kernannahmen für das Design hinter Akka sind viel besser als die hinter JMS / MQ, insbesondere in Bezug auf die Prozessisolierung, das Design ohne Sperren und die Behandlung von Wiederholungen / Fehlern. Zweitens ist die API viel eleganter als JMS / MQ-Tools.
user2684301
2
@ user2684301 hmmh. Ich finde diese Antwort etwas unfair, in Form von Äpfeln zu Orangen. MQs sind (logisch) einfache Bausteine, die viel weniger leisten als Akka, und ich würde sie nicht nebeneinander vergleichen. Aber ich denke, wenn ich es als "im Vergleich zu verteilten Systemen, die mit JMS erstellt wurden und deklarativ geschrieben sind" lese, wäre es sinnvoller.
StaxMan

Antworten:

321

Ich habe es bisher in zwei realen Projekten sehr erfolgreich eingesetzt. Beide befinden sich im nahezu Echtzeit-Verkehrsinformationsfeld (Verkehr wie in Autos auf Autobahnen), verteilt auf mehrere Knoten, integrieren Nachrichten zwischen mehreren Parteien und sind zuverlässige Backend-Systeme. Es steht mir noch nicht frei, Angaben zu Kunden zu machen. Wenn ich das OK erhalte, kann es möglicherweise als Referenz hinzugefügt werden.

Akka hat diese Projekte wirklich durchgesetzt, obwohl wir mit Version 0.7 angefangen haben. (Wir benutzen übrigens Scala)

Einer der großen Vorteile ist die Leichtigkeit, mit der Sie ein System aus Akteuren und Nachrichten fast ohne Boilerplating zusammenstellen können. Es lässt sich ohne die Komplexität des handgerollten Threadings sehr gut skalieren und Sie erhalten fast kostenlos asynchrone Nachrichten, die zwischen Objekten übertragen werden.

Es ist sehr gut bei der Modellierung jeder Art von asynchroner Nachrichtenverarbeitung. Ich würde es vorziehen, irgendeine Art von (Web-) Dienstsystem in diesem Stil zu schreiben als jeden anderen Stil. (Haben Sie jemals versucht, einen asynchronen Webdienst (serverseitig) mit JAX-WS zu schreiben? Das ist viel Aufwand.) Ich würde also sagen, dass jedes System, das nicht an einer seiner Komponenten hängen möchte, weil alles implizit mit synchronen Methoden aufgerufen wird und dass eine Komponente etwas blockiert. Es ist sehr stabil und die Let-it-Crash + Supervisor-Lösung für Fehler funktioniert wirklich gut. Alles ist einfach programmgesteuert einzurichten und nicht schwer zu testen.

Dann gibt es die hervorragenden Zusatzmodule. Das Camel-Modul lässt sich gut in Akka integrieren und ermöglicht die einfache Entwicklung von asynchronen Diensten mit konfigurierbaren Endpunkten.

Ich bin sehr zufrieden mit dem Framework und es wird zu einem Defacto-Standard für die verbundenen Systeme, die wir erstellen.

Raymond Roestenburg
quelle
14
Was ist der Vorteil dieses Ansatzes im Vergleich zur Verwendung eines Messaging-Backends (z. B. ActiveMQ) für die Nachrichtenübermittlung Ihrer Meinung nach?
Magiconair
27
MQ-Produkte sind wirklich für einen anderen Anwendungsfall. unterschiedliche Garantien und sehr unterschiedliche Leistung. MQ-Produkte erfordern viel Setup. Sie würden Warteschlangen in einem solchen Produkt nicht so verwenden, wie Sie Objekte verwenden würden. Schauspieler sind in akka erstklassige Bürger. Sie verwenden sie nach Belieben, ähnlich wie Sie Objekte verwenden würden. Daher ist sowohl in Ihrem Programmiermodell als auch im Setup ein weitaus geringerer Aufwand zu verzeichnen. MQ-Produkte würden Sie eher zur Integration in andere externe Systeme verwenden, nicht zum Aufbau der "Interna" eines Systems, für die Sie Akteure verwenden würden.
Raymond Roestenburg
26
Neue URL für die DBP-Fallstudie lautet downloads.typesafe.com/website/casestudies/…
Bas
2
Aufbauend auf @RaymondRoestenburg bezüglich: MQ-Systemen und Alternativen. RabbitMQ basiert beispielsweise auf der schauspielerbasierten Programmiersprache Erlang. Das ist eine Möglichkeit, über die Beziehung (und Unterscheidung) zwischen Schauspieler und MQ nachzudenken. Während Apache Spark weder Worker-and-Queue- noch Actor-basiert ist, kann ABER mit Akka verwendet werden: Typesafe zeigt, wie Spark-Streaming mit Akka verwendet wird .
Driftcatcher
6
@RaymondRoestenburg Sie haben es versäumt zu erwähnen, dass das Actor-Modell im Ist-Zustand eine spaghettiartige Struktur fördert. Das von Ihnen geschriebene Buch "Akka in Action" ist die beste Demonstration für dieses "Feature". Die Codebeispiele befassen sich mit ziemlich einfachen Geschichten. Der Workflow ist jedoch sehr schwer zu verstehen und aus dem Code zu folgen. Ein damit verbundenes Problem ist, dass Akka-Code auf die aufdringlichste Art und Weise, die Sie sich vorstellen können, in Ihrer gesamten Geschäftslogik unwiderruflich ist. Viel mehr als jedes andere Nicht-Akteur-Framework. Es ist einfach unmöglich, einen grundlegenden Workflow zu schreiben, ohne ihn in verschiedene separate Abschnitte zu unterteilen.
Rapt
222

Haftungsausschluss: Ich bin der PO für Akka

Neben dem Angebot eines Parallelitäts-Smorgasbords, das viel einfacher zu überlegen und zu korrigieren ist (Akteure, Agenten, Datenfluss-Parallelität) und mit Parallelitätskontrolle in Form von STM.

Hier sind einige Anwendungsfälle, die Sie in Betracht ziehen könnten:

  1. Transaktionsverarbeitung (Online-Spiele, Finanzen, Statistiken, Wetten, soziale Medien, Telekommunikation, ...)
    • Scale-up, Scale-out, Fehlertoleranz / HA
  2. Service-Backend (jede Branche, jede App)
    • Service REST, SOAP, Cometd etc.
    • fungieren als Message Hub / Integrationsschicht
    • Scale-up, Scale-out, Fehlertoleranz / HA
  3. Snap-In-Parallelität / Parallelität (jede App)
    • Richtig
    • Einfach zu bearbeiten und zu verstehen
    • Fügen Sie die Gläser einfach Ihrem vorhandenen JVM-Projekt hinzu (verwenden Sie Scala, Java, Groovy oder JRuby).
  4. Stapelverarbeitung (jede Branche)
    • Kamelintegration zur Verbindung mit Batch-Datenquellen
    • Akteure teilen und erobern die Batch-Workloads
  5. Kommunikationszentrum (Telekommunikation, Webmedien, mobile Medien)
    • Scale-up, Scale-out, Fehlertoleranz / HA
  6. Spieleserver (Online-Spiele, Wetten)
    • Scale-up, Scale-out, Fehlertoleranz / HA
  7. BI / Datamining / Allzweck-Crunching
    • Scale-up, Scale-out, Fehlertoleranz / HA
  8. Fügen Sie hier weitere nützliche Anwendungsfälle ein
Viktor Klang
quelle
10
Ich verstehe die Vorteile von Futures und STM, finde aber keine guten Anwendungsfälle für Schauspieler. Was ist für ein Spiel oder einen Wett-Server der Vorteil der Verwendung von Actors gegenüber mehreren App-Servern hinter einem Load Balancer?
Martin Konicek
8
@ViktorKlang POs! = Technischer Leiter. Sie arbeiten zusammen, haben aber unterschiedliche Rollen.
Taylorcressy
79

Ein Beispiel für die Verwendung wäre eine Prioritätswarteschlange für Debit- / Kreditkartentransaktionen. Wir haben Millionen davon und der Aufwand der Arbeit hängt vom Typ der Eingabezeichenfolge ab. Wenn die Transaktion vom Typ CHECK ist, haben wir nur sehr wenig Verarbeitung, aber wenn es sich um eine Verkaufsstelle handelt, gibt es viel zu tun, z. B. das Zusammenführen mit Metadaten (Kategorie, Label, Tags usw.) und das Bereitstellen von Diensten (E-Mail- / SMS-Benachrichtigungen, Aufdeckung von Betrug, geringes Guthaben usw.). Basierend auf dem Eingabetyp erstellen wir Klassen mit verschiedenen Merkmalen (Mixins genannt), die für die Bearbeitung des Auftrags erforderlich sind, und führen dann die Arbeit aus. Alle diese Jobs werden im Echtzeitmodus von verschiedenen Finanzinstituten in dieselbe Warteschlange gestellt. Sobald die Daten bereinigt sind, werden sie zur Persistenz, Analyse oder an eine Socket-Verbindung oder an den Lift-Kometenakteur an verschiedene Datenspeicher gesendet. Die arbeitenden Akteure gleichen die Arbeit ständig selbst aus, damit wir die Daten so schnell wie möglich verarbeiten können. Wir können auch zusätzliche Services, Persistenzmodelle und für kritische Entscheidungspunkte.

Die Erlang-Nachricht im OTP-Stil, die an die JVM weitergeleitet wird, ist ein großartiges System für die Entwicklung von Echtzeitsystemen auf den Schultern vorhandener Bibliotheken und Anwendungsserver.

Mit Akka können Sie Nachrichten wie bei einer herkömmlichen Nachricht weitergeben aber mit Geschwindigkeit! Außerdem erhalten Sie Tools im Framework, mit denen Sie die große Anzahl von Akteurpools, Remote-Knoten und Fehlertoleranz verwalten können, die Sie für Ihre Lösung benötigen.

Wade Arnold
quelle
1
Ist es also fair zu sagen, dass es sich um (einige) Anforderungen mit langer Latenz handelt, bei denen ein einzelner Thread pro Anforderung nicht gut skaliert werden kann?
StaxMan
7
Ich denke, der wichtige Teil der Schauspielerprogrammierung im Allgemeinen ist der Nachrichtenfluss. Sobald Sie mit der Konzeption von Datenflüssen beginnen, die keine Nebenwirkungen haben, möchten Sie nur, dass so viele Flüsse wie möglich pro Knoten stattfinden. Dies unterscheidet sich erheblich von High Performance Computing, wenn Sie semi-homogene Jobs haben, die keine Nachrichten senden und deren Verarbeitung lange dauert. Ich denke, eine auf Schauspielern basierende Fibonacci-Implementierung ist ein sehr begrenzendes Beispiel, da sie nicht zeigt, warum Schauspieler verwendet werden sollen, sondern nur, dass Schauspieler Takes lähmen. Denken Sie an eine ereignisgesteuerte Architektur für Anwendungsfälle.
Wade Arnold
4
Ereignisgesteuerte Architektur ist eine andere Art, über Probleme nachzudenken. Es lohnt sich, Erlang OTP in Action von der Besatzung zu lesen, wenn Sie über das Codieren in Akka nachdenken. Viele der Konstrukte in Akka sind von Erlang OTP beeinflusst und das Buch gibt Ihnen die Prinzipien, warum Jonas Boner Akka API so gebaut hat, wie er es getan hat. Akka ist ein großer Berg, auf dem du stehst! Wenn Ihre Schauspieler durch Zustandsänderungen hartnäckig sind, brauchen Sie wirklich 10.000 Schreibvorgänge pro Sekunde
Wade Arnold
8
Wade, wie geht ihr mit Nachrichtengarantien um? Sie erwähnen: (E-Mail- / SMS-Benachrichtigungen, Betrugserkennung, geringes Guthaben usw.), ich gehe davon aus, dass diese möglicherweise an entfernte Akteure gesendet werden? Wie stellen Sie sicher, dass diese Operationen tatsächlich stattgefunden haben? Was passiert, wenn der Knoten während der Verarbeitung einer Betrugswarnung ausgefallen ist? Ist es für immer weg? Haben Sie ein eventuell konsistentes System, das es bereinigt? Vielen Dank!
James
2
Gute Frage James. Es ist offensichtlich, dass es in ein System passt, in dem eine Antwort nicht dringend benötigt wird. Sie können beispielsweise Kreditkartenrechnungen verarbeiten. Berechnung; E-Mail senden usw. Ich frage mich wirklich, wie diese Dinge (Transaktion) behandelt werden, wenn eine Antwort benötigt wird. Am Ende; wenn eine Anfrage von außen gestellt wird (Internetnutzer; ein Vertreter des Call Centers usw.); er oder sie wartet auf eine Antwort. Wie kann ich sicher sein, dass Unteraufgaben (die asynchron ausgeführt werden) ausgeführt werden? in einer xa-Transaktion, damit ich eine Antwort zurückgeben kann?
Kaan Yy
44

Wir verwenden Akka, um REST-Aufrufe asynchron zu verarbeiten. Zusammen mit dem asynchronen Webserver (Netty-basiert) können wir die Anzahl der pro Knoten / Server bedienten Benutzer im Vergleich zum herkömmlichen Thread pro Benutzeranforderungsmodell um das Zehnfache verbessern.

Sagen Sie Ihrem Chef, dass Ihre AWS-Hosting-Rechnung um den Faktor 10 sinken wird und es ein Kinderspiel ist! Shh ... erzähl es aber nicht Amazon ... :)

Piotrga
quelle
3
Und ich habe vergessen zu erwähnen, dass die monadische Natur der Akka-Futures, die zu einem viel saubereren Parallelcode führt, uns Tausende bei der
Codepflege erspart hat
8
Ich gehe davon aus, dass Anrufe eine hohe Latenz und einen geringen Durchsatz haben. Sie möchten gerne andere Server anrufen und auf eine Antwort warten (Proxy)?
StaxMan
38

Wir verwenden Akka in einem großen Telekommunikationsprojekt (leider kann ich nicht viele Details preisgeben). Akka-Akteure werden von einer Webanwendung remote bereitgestellt und abgerufen. Auf diese Weise haben wir ein vereinfachtes RPC-Modell, das auf Google Protobuffer basiert, und wir erreichen Parallelität mit Akka Futures. Bisher hat dieses Modell hervorragend funktioniert. Ein Hinweis: Wir verwenden die Java-API.

Luciano Fiandesio
quelle
Könnten Sie uns bitte etwas mehr erzählen? Afaik-Futures können nicht über das Kabel gesendet werden (serialisiert). Verwenden Sie viele Futures und wenige Schauspieler oder eine Mischung aus beiden oder ...? Sie verwenden Protobuf für alle Serialisierungen und senden als Nachricht an die Schauspieler?
Aktau
Dies scheint ohne Akka genauso einfach zu handhaben gewesen zu sein.
Erik Kaplun
1
TDC ist in Fiaddesios Fall ein Telekommunikationsunternehmen.
Roman Kagan
37

Wenn Sie den Chat-Server eine Ebene höher abstrahieren, erhalten Sie die Antwort.

Akka bietet ein Messaging-System, das Erlangs "Let it Crash" -Mentalität ähnelt.

Beispiele sind also Dinge, die ein unterschiedliches Maß an Haltbarkeit und Zuverlässigkeit von Nachrichten erfordern:

  • Chat-Server
  • Netzwerkschicht für ein MMO
  • Finanzdatenpumpe
  • Benachrichtigungssystem für ein iPhone / Handy / welche App auch immer
  • REST-Server
  • Vielleicht etwas ähnlich wie WebMachine (Vermutung)

Das Schöne an Akka sind die Auswahlmöglichkeiten für die Persistenz, die STM-Implementierung, der REST-Server und die Fehlertoleranz.

Lassen Sie sich nicht vom Beispiel eines Chat-Servers ärgern, sondern betrachten Sie es als Beispiel für eine bestimmte Lösungsklasse.

Bei all ihrer hervorragenden Dokumentation denke ich, dass genau diese Frage, Anwendungsfälle und Beispiele eine Lücke sind. Beachten Sie, dass die Beispiele nicht trivial sind.

(Geschrieben mit nur Erfahrung im Ansehen von Videos und Spielen mit der Quelle, habe ich nichts mit akka implementiert.)

Tylerweir
quelle
2
Danke - ich wollte nicht, dass der Chat-Server unbedingt schlecht ist, nur dass ich ergänzende Beispiele haben möchte; einfacher, eine bessere Vorstellung vom Potenzial zu bekommen.
StaxMan
Neugierig, wie der REST-Server hierher passt? Erwähnen Sie es im Zusammenhang mit dem asynchronen Server im Node.j-Stil? Vielen Dank, dass Sie die Anwendungsbeispiele geteilt haben. Ich fand sie nützlich.
software.wikipedia
24

Wir verwenden Akka in mehreren Projekten bei der Arbeit, von denen das interessanteste mit der Reparatur von Fahrzeugunfällen zusammenhängt. Hauptsächlich in Großbritannien, jetzt aber auch in den USA, Asien, Australasien und Europa. Wir setzen Akteure ein, um sicherzustellen, dass Informationen zur Unfallreparatur in Echtzeit bereitgestellt werden, um die sichere und kostengünstige Reparatur von Fahrzeugen zu ermöglichen.

Die Frage bei Akka ist wirklich mehr: Was kann man mit Akka nicht machen? Die Fähigkeit zur Integration in leistungsstarke Frameworks, die leistungsstarke Abstraktion und alle Aspekte der Fehlertoleranz machen es zu einem sehr umfassenden Toolkit.

Rossputin
quelle
Welchen Aspekt magst du am liebsten, wenn du dich entscheiden musstest? Bestehende Integration für andere Frameworks, automatische Fehlertoleranz oder etwas anderes?
StaxMan
6
Aus persönlicher Sicht ist es die erhöhte Abstraktionsebene, die Akka an den Tisch bringt, die mir am besten gefällt. Aus Unternehmenssicht sind es die Integrationsmöglichkeiten.
Ich muss meinen
Könnten Sie näher erläutern, wie der Nachrichtenfluss ist? Ist der Benutzer die Person in einer Reparaturwerkstatt und gibt Details zum Absturz in ein http-Formular ein und sendet dann die Daten an den Server. Erstellt dies eine Nachricht, die von akka verarbeitet wird? Was tun mit dieser Nachricht? Extrahieren Sie die eingegebenen Informationen, um die Datenbank abzufragen, und stellen Sie die Antwort in die Warteschlange, um sie an das Web-Frontend zurückzusenden.
Surfmuggle
24

Sie können Akka für verschiedene Arten von Dingen verwenden.

Ich habe an einer Website gearbeitet, auf der ich den Technologie-Stack auf Scala und Akka migriert habe. Wir haben es für so ziemlich alles verwendet, was auf der Website passiert ist. Auch wenn Sie vielleicht denken, dass ein Chat-Beispiel schlecht ist, sind alle im Grunde gleich:

  • Live-Updates auf der Website (zB Ansichten, Likes, ...)
  • Live-Benutzerkommentare anzeigen
  • Benachrichtigungsdienste
  • Suche und alle anderen Arten von Dienstleistungen

Besonders die Live-Updates sind einfach, da sie sich auf ein Chat-Beispiel beschränken. Der Serviceteil ist ein weiteres interessantes Thema, da Sie einfach Remote-Akteure verwenden können. Selbst wenn Ihre App nicht geclustert ist, können Sie sie problemlos auf verschiedenen Computern bereitstellen.

Ich verwende Akka auch für eine PCB-Autorouter-Anwendung mit der Idee, von einem Laptop zu einem Rechenzentrum skalieren zu können. Je mehr Kraft Sie geben, desto besser wird das Ergebnis sein. Dies ist äußerst schwierig zu implementieren, wenn Sie versuchen, die übliche Parallelität zu verwenden, da Akka Ihnen auch Standorttransparenz bietet.

Derzeit baue ich als Freizeitprojekt ein Web-Framework, bei dem nur Schauspieler verwendet werden. Die Vorteile sind wiederum die Skalierbarkeit von einer einzelnen Maschine auf einen gesamten Maschinencluster. Durch die Verwendung eines nachrichtengesteuerten Ansatzes ist Ihr Softwaredienst von Anfang an orientiert. Sie haben all diese netten Komponenten, die miteinander sprechen, sich aber nicht unbedingt kennen und auf demselben Computer leben, nicht einmal im selben Rechenzentrum.

Und seit Google Reader heruntergefahren ist, habe ich mit einem RSS-Reader begonnen, natürlich mit Akka. Für mich dreht sich alles um gekapselte Dienste. Fazit: Das Akteurmodell selbst sollte zuerst übernommen werden, und Akka ist ein sehr zuverlässiger Rahmen, der Ihnen bei der Implementierung hilft und viele Vorteile bietet, die Sie auf Ihrem Weg erhalten.

Joa Ebert
quelle
Hallo Joe, kannst du erklären, wie Nachrichten zum Aktualisieren der Site verwendet werden? Haben Sie ein System für den Inhaltsautor? Er erstellt einen neuen Artikel und klickt auf Speichern. Erstellt dies eine Nachricht, die an mehrere Server gesendet wird, die den eingehenden Datenverkehr verarbeiten. Jeder Server verarbeitet die Update-Nachricht so schnell wie möglich. Jede neue Browser-Anfrage erhält dann eine aktualisierte Version der Seite? Vielen Dank
Surfmuggle
18

Wir verwenden akka mit seinem Kamel-Plugin, um unsere Analyse- und Trendverarbeitung für twimpact.com zu verteilen . Wir müssen zwischen 50 und 1000 Nachrichten pro Sekunde verarbeiten. Zusätzlich zur Mehrknotenverarbeitung mit Kamel wird es auch verwendet, um die Arbeit auf einem einzelnen Prozessor für maximale Leistung auf mehrere Arbeiter zu verteilen. Funktioniert recht gut, erfordert jedoch ein gewisses Verständnis für den Umgang mit Überlastungen.

Matthias L. Jugel
quelle
Verwenden Sie auch Akkas Fehlertoleranz?
Erik Kaplun
Wie wäre es mit Spark Streaming, wenn Sie Zugriff auf Spark Cluster haben?
Skjagini
18

Ich habe Akka (Java API) ausprobiert. Ich habe versucht, Akkas schauspielerbasiertes Parallelitätsmodell mit dem des einfachen Java-Parallelitätsmodells (java.util.concurrent-Klassen) zu vergleichen.

Der Anwendungsfall war eine einfache kanonische Karte, die die Implementierung der Zeichenanzahl reduzierte. Der Datensatz bestand aus einer Sammlung zufällig generierter Zeichenfolgen (400 Zeichen lang) und berechnete die Anzahl der darin enthaltenen Vokale.

Für Akka habe ich einen BalancedDispatcher (zum Lastausgleich zwischen Threads) und RoundRobinRouter (um meine Funktionsakteure einzuschränken) verwendet. Für Java habe ich eine einfache Fork-Join-Technik verwendet (implementiert ohne einen Algorithmus zum Stehlen von Arbeit), mit der die Ausführungen gegabelt / reduziert und die Ergebnisse verknüpft werden. Zwischenergebnisse wurden in Blockierungswarteschlangen gespeichert, um selbst die Verbindung so parallel wie möglich zu gestalten. Wenn ich mich nicht irre, würde das wahrscheinlich das "Mailbox" -Konzept der Akka-Schauspieler nachahmen, bei denen sie Nachrichten empfangen.

Beobachtung: Bis zu mittleren Lasten (~ 50000 String-Eingabe) waren die Ergebnisse vergleichbar und variierten geringfügig in verschiedenen Iterationen. Wenn ich jedoch meine Last auf ~ 100000 erhöhte, blieb die Java-Lösung hängen. Ich habe die Java-Lösung unter dieser Bedingung mit 20 bis 30 Threads konfiguriert und sie ist in allen Iterationen fehlgeschlagen.

Das Erhöhen der Last auf 1000000 war auch für Akka fatal. Ich kann den Code mit allen Interessierten teilen, um eine Gegenprüfung durchzuführen.

Für mich scheint Akka besser zu skalieren als herkömmliche Java-Multithread-Lösungen. Und wahrscheinlich ist der Grund die Magie von Scala unter der Haube.

Wenn ich eine Problemdomäne als ereignisgesteuerte Nachricht modellieren kann, die eine übergibt, ist Akka meiner Meinung nach eine gute Wahl für die JVM.

Test durchgeführt auf: Java Version: 1.6 IDE: Eclipse 3.7 Windows Vista 32 Bit. 3 GB RAM. Intel Core i5 Prozessor, Taktrate 2,5 GHz

Bitte beachten Sie, dass die für den Test verwendete Problemdomäne diskutiert werden kann und ich versucht habe, so fair zu sein, wie es meine Java-Kenntnisse zulassen :-)

Sutanu Dalui
quelle
3
"Ich kann den Code mit allen teilen, die an einer Gegenprüfung interessiert sind." Ich würde gerne, wenn es Ihnen nichts ausmacht.
n1r3
3
Ich möchte auch den Code, können Sie einen Github-Link posten?
Gautam
Danke für dein Interesse. Leider habe ich einige Probleme beim Einrichten eines Github-Repos. Wenn Sie mir Ihre E-Mails geben können, kann ich über den Quellcode mailen. Und bedauere eine späte Antwort!
Sutanu Dalui
@sutanudalui Haben Sie bitte noch den Code, wenn ja, kann ich meine E-Mail teilen?
Jay
16

Wir verwenden Akka in gesprochenen Dialogsystemen ( Primetalk ). Sowohl intern als auch extern. Um viele Telefoniekanäle gleichzeitig auf einem einzelnen Clusterknoten ausführen zu können, ist offensichtlich ein Multithreading-Framework erforderlich. Akka funktioniert einfach perfekt. Wir haben einen früheren Albtraum mit der Java-Parallelität. Und mit Akka ist es wie eine Schaukel - es funktioniert einfach. Robust und zuverlässig. 24 * 7, ohne Unterbrechung.

Innerhalb eines Kanals haben wir einen Echtzeitstrom von Ereignissen, die parallel verarbeitet werden. Insbesondere: - langwierige automatische Spracherkennung - erfolgt mit einem Schauspieler; - Audioausgabeproduzent, der einige Audioquellen (einschließlich synthetisierter Sprache) mischt; - Die Umwandlung von Text in Sprache ist eine separate Gruppe von Akteuren, die von den Kanälen gemeinsam genutzt werden. - Semantik und Wissensverarbeitung.

Um Verbindungen komplexer Signalverarbeitung herzustellen, verwenden wir SynapseGrid . Es hat den Vorteil, dass der DataFlow in den komplexen Akteursystemen zur Kompilierungszeit überprüft wird.

Arseniy Zhizhelev
quelle
14

Ich habe kürzlich das kanonische Beispiel zur Kartenreduzierung in Akka implementiert : Word count. Es ist also ein Anwendungsfall von Akka: bessere Leistung. Es war mehr ein Experiment der Schauspieler von JRuby und Akka als alles andere, aber es zeigt auch, dass Akka nicht nur Scala oder Java ist: Es funktioniert in allen Sprachen zusätzlich zu JVM.

Daniel Ribeiro
quelle
Wissen Sie, was für eine bessere Leistung verantwortlich ist (und auch im Vergleich zu welcher Alternative)? Liegt das an der Verwendung von JRuby in JVM (im Vergleich zu nativem Ruby), an der Skalierbarkeit aufgrund nicht blockierender E / A oder an etwas anderem?
StaxMan
2
Der Vergleich, den ich schrieb, war: Jruby sequentiell VS Jruby mit Schauspielern. Das einzige, was für eine schnellere Ausführung verantwortlich sein kann, ist die Beteiligung der Akteure. An den Experimenten hat keine E / A teilgenommen (eine Datei wird von der Festplatte geladen, dies erfolgt jedoch vor dem Einstellen des Benchmark-Timers).
Daniel Ribeiro
Ich habe kürzlich auch ein Beispiel zur Kartenreduzierung implementiert, aber es ist einfach Vanille Java Github.com/chaostheory/jibenakka
Chaostheory