Quand n'est-il pas bon d'utiliser des acteurs dans akka / erlang?

Je travaille avec Akka depuis 7 ou 8 mois maintenant. Lorsque j'ai commencé, je travaillais sur des applications et je remarquais que les acteurs étaient utilisés pratiquement n'importe où une fois dans le système d'acteurs pour communiquer entre la plupart des objets. Alors j'ai fait la même chose - actionner un autre acteur pour x / y / z.

Il me semble que c'est peut-être trop aveugle, ce qui ajoute à la complexité là où ce n'est pas nécessaire - mais je ne trouve aucune discussion sur le point de savoir où les acteurs par rapport à la logique synchrone ou même asynchrone via des futurs devraient être utilisés. J'ai commencé à réfléchir à ma position après que mon collègue ait mentionné quelque chose de similaire. J'ai récemment réalisé plusieurs cas dans lesquels j'avais réfléchi à une tâche, puis évité de créer un autre acteur, car je pouvais obtenir le même résultat en toute sécurité dans une implémentation immuable - par exemple, obtenir des valeurs de configuration à partir d'une base de données ou d'un fichier où vous accédez très rarement et restez accessible. attendre le résultat est le cas d'utilisation réel.

En particulier, il me semble que dans tous les cas où vous jouez avec un état immuable, les acteurs créent de la complexité et limitent le débit - une fonction pure dans un objet, par exemple, peut être appelée simultanément sans risque, quel que soit le niveau de simultanéité. un acteur ne peut traiter qu'un message à la fois. L'autre considération à prendre en compte est de laisser filer le fil si vous devez attendre le résultat, sauf si vous commencez à utiliser des futures, mais dans les cas où vous n'avez pas à vous soucier de la messagerie asynchrone ou de l'échelle, il semble exagéré d'employer un acteur.

Ma question est donc la suivante: y at-il un mauvais moment pour utiliser des acteurs? Je suis curieux de voir à quoi ressemble Erlang et aimerais vraiment la perspicacité des autres. Ou s'il y a des principes autour de l'utilisation par les acteurs.

C'est une question qui m'intéresse et sur laquelle j'ai effectué des recherches. Pour d'autres points de vue, consultez ce billet de blog de Noel Walsh ou cette question sur Stack Overflow. J'ai quelques opinions que j'aimerais offrir:

• Je pense qu'Akka, parce que cela fonctionne avec les messages, encourage un "état d'esprit poussé". Souvent, pour la concurrence, je dirais que ce n’est pas ce que vous voulez. Tirer est beaucoup plus sûr. Par exemple, un modèle courant pour les systèmes distribués consiste à avoir un ensemble de travailleurs traitant des informations dans une file d'attente . Cela est évidemment possible à Akka, mais cela ne semble pas nécessairement être la première approche que les gens essaient . Akka propose également des boîtes aux lettres durables, mais là encore, cela dépend de la façon dont vous les utilisez: une seule file d'attente partagée est beaucoup plus flexible que les files d'attente par utilisateur pour équilibrer / réaffecter le travail.
• Il est facile d'entrer dans la mentalité de remplacer vos classes par des acteurs. En fait, certaines personnes semblent même le préconiser en disant que les acteurs ne devraient faire qu'une chose . Comme le décrit Jason, la complexité du code augmente la complexité du code, car si chaque classe est un acteur, il y a beaucoup de messages supplémentaires et de blocs de réception / envoi. Cela rend également plus difficile la compréhension et le test du code car vous perdez la formalité des interfaces - et je ne suis pas convaincu que les commentaires constituent une solution à ce problème . En outre, malgré l'efficacité légendaire d'Akka , je soupçonne que la prolifération d'acteurs n'est pas une bonne idée en termes de performances: lorsque nous utilisons des threads Java, nous savons qu'ils sont précieux et les conservons en conséquence.
• C'est lié au point précédent, mais un autre inconvénient est la perte d'informations de type que Noel et Pino soulignent, comme c'est le cas pour beaucoup d'entre nous, c'est pourquoi nous utilisons Scala plutôt que d'autres langages tels que Python. Il y a quelques moyens de contourner ce problème, mais ils sont non standard , non recommandés ou expérimentaux .
• Enfin, la concurrence, même si vous avez un état d'esprit "laissez-le planter" , est difficile. Les modèles de programmation alternatifs peuvent aider, mais ils ne font pas disparaître les problèmes - ils les modifient - c'est pourquoi il est bon de penser officiellement à eux . C'est également la raison pour laquelle les développeurs de Joe Average recherchent des outils prêts à l'emploi tels que les bases de données RabbitMQ, Storm, Hadoop, Spark, Kafka ou NoSQL. Akka possède des outils et des composants prédéfinis, ce qui est cool, mais le niveau de sécurité est également assez bas. Par conséquent, des éléments communs mieux préparés des systèmes distribués aideraient les développeurs et garantiraient que les systèmes sont correctement construits.

Comme Jason, je suis impatient d'entendre les idées des autres ici. Comment puis-je résoudre certains des problèmes ci-dessus et utiliser Akka mieux?

Cela vaut la peine d’examiner à quoi sert le modèle d’acteur: le modèle d’acteur est

1. un modèle de concurrence
2. qui évite l'accès simultané à l'état mutable
3. utilisant des mécanismes de communication asynchrones pour assurer la simultanéité.

Cela est utile car l'utilisation de l'état partagé à partir de plusieurs threads devient très difficile, en particulier lorsqu'il existe des relations entre différents composants de l'état partagé qui doivent être maintenues synchronisées. Cependant, si vous avez des composants de domaine dans lesquels:

• Vous n'autorisez pas la concurrence, OU
• Vous n'autorisez pas l'état mutable (comme dans la programmation fonctionnelle), OU
• Vous devez compter sur un mécanisme de communication synchrone,

alors le modèle d'acteur ne fournira pas beaucoup (le cas échéant) d'avantages.

J'espère que ça t'as aidé.

Votre intuition est correcte, à mon humble avis. Utiliser des acteurs partout, c'est comme avoir le marteau proverbial et ne voir que des clous.

La meilleure pratique d'Erlang consiste à utiliser des processus / acteurs pour toutes les activités qui se déroulent simultanément. C'est comme dans la vraie vie. Il est parfois difficile de trouver la granularité appropriée, mais la plupart du temps, il suffit de regarder le domaine modélisé et d’utiliser un peu de bon sens. J'ai bien peur de ne pas avoir de meilleure méthode que celle-là, mais j'espère que cela aidera.

Dans l'ordre, la messagerie d'entrée / de sortie:

J'ai récemment rencontré une application basée sur Akka dans laquelle le modèle d'acteur posait des problèmes de concurrence, un modèle plus simple aurait suffi mieux sous charge.

Le problème était que les messages entrants se déplaçaient dans des «voies» différentes (via des chemins d'acteurs différents), mais le code supposait que les messages arriveraient à leur destination finale dans le même ordre. Tant que les données arrivaient avec des intervalles suffisamment grands, cela fonctionnait, car il n'y aurait qu'un seul message contradictoire à destination de la destination. Lorsque les intervalles ont diminué, ils ont commencé à arriver en panne et à provoquer un comportement étrange.

Le problème aurait pu être résolu correctement avec un peu moins d'acteurs, mais c'est une erreur facile à commettre lorsque vous en abusez.

À mon avis, il existe deux cas d'utilisation pour les acteurs. Ressources partagées telles que les ports, etc., et grands états. Le premier a été bien couvert par la discussion jusqu'à présent, mais un grand État est également une raison valable.

Une grande structure passée avec chaque appel de procédure peut utiliser beaucoup de pile. Cet état peut être placé dans un processus séparé, la structure remplacée par un identifiant de processus et ce processus interrogé au besoin.

Les bases de données telles que mnesia peuvent être considérées comme un état de stockage externe au processus d'interrogation.