2013-05-07 7 views
1

Je veux connaître l'applicabilité du modèle Acteur Akka.akka acteur modèle vs utilisation java dans le scénario suivant

Je sais que c'est utile dans le cas où un grand nombre d'instances Actor sont créées et détruites. par exemple. un serveur d'appel, où chaque appel entrant crée une instance d'acteur et communique avec quelques autres acteurs et se fait tuer après la fin de l'appel.

Est-il également utile dans le scénario suivant:

Un serveur a quelques éléments de traitement (10 ~ 50) mis en œuvre sur les acteurs. La durée de vie de ces éléments de traitement est infinie. certains d'entre eux ne maintiennent pas l'état et quelques-uns maintiennent l'état. Les éléments de traitement traitent le message et transmettent le message à d'autres acteurs de manière fixe. Le système reçoit un grand nombre de messages provenant de l'extérieur et est passé à travers les éléments de traitement et sort du système. Mon intuition est que nous ne pouvons pas obtenir un avantage en utilisant le modèle Akka Actor et même en implémentant ce serveur dans Scala. Parce que le cas d'utilisation pour lequel Akka est conçu, n'est pas applicable ici. Si la mise à l'échelle impliquait une augmentation dynamique des éléments de traitement, elle serait applicable.

Pour les topologies fixes, je pense que si je l'implémente en Java, cela va être plus bénéfique en termes de performances brutes. La fonctionnalité "immuabilité" de Scala conduit à plus de copies et réduit ainsi les performances. Donc, je crois que je préfère m'en tenir à Java.

Est-ce que je comprends bien? J'ai une coquille de noix je veux savoir pourquoi je devrais quitter Java et utiliser Scala/Akka pour le scénario d'application ci-dessus. et ma cible est de traiter 1 million de messages par seconde.

+0

Je pense que c'est un excellent cas d'utilisation pour Akka. Unités de traitement, certains étatful, tous les messages d'échange. Pourquoi ne l'utiliseriez-vous pas? Il n'y a pas de raison qu'Akka ne fonctionne pas bien pour les topologies d'acteurs fixes. –

+0

Identique à ci-dessus. Le fait que les acteurs aient une vie illimitée n'a rien à voir avec l'applicabilité d'Akka ici. En fait, la plupart des tâches de traitement de style pipeline - dont votre cas ressemble - sont une excellente combinaison. –

+0

Merci pour vos commentaires. Je l'ai manqué dans ma question, mais ce que je veux dire, c'est que pour les topologies fixes, quel est l'avantage du modèle Akka par rapport à la même chose implémentée en Java. Enfin, Scala utilise des structures de données Java en file d'attente etc. Je pense donc que Java me donnera des performances plus brutes. Si tel est le cas, alors pourquoi devrait-on considérer Scala comme une performance brute? – weima

Répondre

2

Si cette question est toujours d'actualité ...

  1. Scala vs Java

    • Scala donne la productivité aux développeurs.
    • L'immunité diminue le débogage à un niveau presque nul.
    • GC s'adapte parfaitement aux déchets immuables.
  2. Acteurs Akka contre d'autres moyens

    • a Akka répartiteur qui distribue les tâches à travers la piscine fil fixe. Cela permet de consommer uniformément les ressources disponibles. Cette approche est bien meilleure que les threads de travail fixe - les ressources de traitement sont fournies aux tâches et non aux nœuds DataFlow.
  3. DataFlow mise en œuvre

    • Il y a une bibliothèque SynapseGrid qui est construit sur des acteurs et permet la construction Akka facile des systèmes DataFlow répartis sur les acteurs immortels fixes. Il peut même dessiner le diagramme DataFlow (dans .dot format) de l'ensemble du système. (La bibliothèque est plus pratique à utiliser avec Scala.
Questions connexes