Akka et les acteurs singleton

Question

J'ai récemment commencé à jouer avec les acteurs d'akka et les modules http. Cependant, je suis tombé sur une petite bizarrerie plutôt ennuyeuse, à savoir, la création d'acteurs Singelton.

Voici deux exemples:

1)

J'ai un cache en mémoire, mon service est assez petit (son une application plutôt) donc je vraiment comme ça dans le modèle de mémoire. Je peux détenir la plupart des informations pertinentes pour l'utilisateur dans une carte (bien, une carte de listes, mais encore, très facile à raisonner sur la structure) et je ne comprends pas les frais généraux et la complexité d'une redis, geode ou aérospike.

Le seul problème est que ce chage en mémoire peut être modifié, par plusieurs sources et que lesdites modifications doivent être synchrones. Au lieu de synchroniser toutes les 3 méthodes d'accès pour cette structure (par exemple en construisant une file de messages ou en implémentant des verrous), je pensais juste envelopper la structure et ses méthodes d'accès dans un acteur, construire une file d'attente, si les choses évoluent, il sera très facile de remplacer par un acteur DA sur une mémoire dédiée.

2) J'ai une couche "Service" qui devrait être utilisée pour répartir les acteurs pour différents travaux (accéder à la base de données, accéder au cache en mémoire, faire ce calcul avec des données et livrer le résultat à l'utilisateur ... etc).

Il est logique que cette couche Service soit un "singleton", une fermeture sur certaines fonctions, puisqu'elle ne fait rien qui soit bloquant ou CPU/mémoire, elle assigne simplement des tâches plus loin dans la ligne (par exemple, décide combien d'acteurs/fil/nous devrions être créé et où une demande devrait aller)

Cependant, cette chose, il faudrait soit:

a) faire les deux objets acteurs singleton ou

b) faire les deux objets réels "objets" (comme dans la notation d'objet scala qui désigne un seul singleton nommé avec fu b), il y a beaucoup de problèmes avec b), à savoir que la couche de service devra soit lui passer un système d'acteurs (et je ne suis pas sûr que ce soit une bonne pratique). Afin de créer des acteurs, plutôt que de créer ses propres «enfants», il va créer des enfants en utilisant le système des acteurs mondiaux et la logique de messagerie et de suivi sera beaucoup plus maladroite et non intuitive. En outre, que le cache en mémoire n'aura pas l'avantage du message intégré que (je ne dis pas qu'il est difficile d'en implémenter un, mais cela ressemble à l'une de ces situations où l'on va "Oh, jolly, c'est bon que J'ai des acteurs et je n'ai pas à passer du temps à implémenter et tester ce code ")

a) semble avoir le problème d'être généralement mal documenté et non recommandé dans la documentation akka. Je veux dire:

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

Regardez cette merde, la moitié des documents sont mise en garde contre, il était sa propre dépendance et très franchement il est très difficile à lire pour un pauvre bougre comme moi qui n'a pas mettre le pied dans la & programmation simultanée tour d'ivoire.

Alors, ahm. Est-ce que l'un d'entre vous pourrait m'expliquer pourquoi il est mauvais d'utiliser des acteurs singleton? Comment concevez-vous les singletons s'ils ne peuvent pas être des acteurs? Y at-il un moyen de concevoir des acteurs singleton qui ne causeront pas beaucoup de dégâts sur la ligne?Est-ce que tout le modèle de "service" d'avoir des services "globaux" est appelé plutôt que instancié "un akka like"?

Answer 1

Juste pour clarifier la documentation, ils ne mettent pas en garde contre son utilisation. Ils avertissent qu'il y a des circonstances dans lesquelles l'utilisation d'un singleton causera des problèmes, qui sont attendus compte tenu des circonstances. Ils mentionnent les situations suivantes:

• Si le singleton est un goulot d'étranglement des performances. C'est logique. Si tout repose sur un seul objet qui fonctionne lentement, tout sera lent.
• Si l'acteur doit être disponible sans interruption, vous rencontrerez des problèmes si le singleton tombe en panne, car ces messages ne peuvent pas être gérés par une autre instance. Il faudra un certain temps pour redémarrer le singleton avant que son travail puisse être repris.
• Le plus gros problème se produit si la fonction d'extinction automatique est activée. La désactivation automatique est une stratégie par laquelle un nœud inaccessible est supposé être arrêté et supprimé du réseau. Si vous le faites, mais que le nœud n'est pas réellement hors service mais simplement inaccessible en raison d'une partition réseau, les deux côtés de la partition décideront qu'ils sont les nœuds survivants et créeront leurs propres singletons. Alors maintenant vous avez deux singletons. Ce qui, bien sûr, n'est pas ce que vous voulez d'un singleton. Mais vous ne devriez jamais utiliser l'auto-downing en dehors des tests de toute façon. C'est une stratégie de rétablissement terrible qui a été incluse pour l'exhaustivité et la commodité dans les tests.

Donc je ne lis pas cela comme recommandant de ne pas l'utiliser. Juste être clair sur les pièges attendus si vous l'utilisez, en fonction de la nature de la structure.