trop d'IActorRefs dans Akka.net

Question

Disons que j'ai la hiérarchie d'Acteurs suivante :

user
|____A___|---E
|        |---F
|        |---G
|
|____B___I
|____C___J
|____D___K

Disons que l'acteur E a besoin d'avoir les références d'acteur des acteurs I, J, K, passer les références d'acteur dans le constructeur devient compliqué si le système évolue et a besoin de plus d'acteurs, et que l'utilisateur sélectionne les acteurs. utilisation locale déconseillée .

Existe-t-il un moyen approprié et dynamique d'obtenir les ActorRef à mesure que le système évolue ?

J'ai beaucoup réfléchi pour savoir si je devais poser cette question ou non, car elle peut être interprétée comme une question d'opinion, mais j'ai vraiment du mal avec ce problème car j'ai beaucoup cherché et il n'est pas encore clair quelle est la meilleure pratique pour ce problème car le code peut devenir vraiment désordonné et illisible à la longue.

Answer 1

Il suffit de commencer à envoyer des messages, au lieu d'essayer de préconfigurer les acteurs avec (beaucoup) d'autres acteurs. Cela rend l'initialisation compliquée en effet, quand il y a beaucoup de différents Acteurs. De plus, vous ne pouvez pas considérer les handles IActorRef passés à un constructeur comme statiques et éternellement valides : lorsqu'un acteur est hors ligne, vous avez besoin d'un mécanisme pour le détecter et annuler son handle, ou le supprimer. Les autres Acteurs du cluster doivent surveiller les messages de log Akka qui ne sont pas garantis etc

Au lieu de cela, lorsque vous connectez un nouvel acteur au cluster, émettez (poussez) votre identité via un pubsub. Le message de votre nouvel Acteur pourrait être : ActorSytem.Name+IActorRef+RoleString.

https://getakka.net/articles/clustering/distributed-publish-subscribe.html

Le RoleString est un descripteur de la tâche de votre Acteur. Les autres acteurs peuvent décider d'enregistrer votre IActorRef, sur la base du RoleString.

Au cours du processus, d'autres abonnés (acteurs) au pubsub capteront votre identité et la stockeront. Ensuite, ils émettent leur identité de la même manière, via le même pubsub. En conséquence, vous recevrez les identités RoleString dont vous avez besoin en réponse et les autres nœuds de cluster (Acteurs) savent que vous existez.

Lorsque l'acteur doit se déconnecter, il émet d'abord un message pubsub, avant de déconnecter réellement l'acteur du cluster. De cette façon, les autres acteurs savent que l'Acteur s'est déconnecté.

Un écueil avec cette stratégie : éviter les boucles de pubsub sans fin (I/O avalange). Solution que j'utilise : empêcher un Acteur d'envoyer trop de messages en testant le temps écoulé depuis son précédent message pubsub. Mettez par exemple 1 message par minute, sans tenir compte des autres Acteurs cela donnera un battement de cœur, plutôt qu'une avalanche de messages. Et vous serez informé à intervalles réguliers de l'état en ligne de tous les Acteurs. Un message de sortie/hors ligne n'est pas nécessaire dans ce cas.

Answer 2

J'ai donc consulté la documentation et l'ai lue attentivement. J'ai découvert qu'il existe deux façons d'obtenir des IActorRef de manière propre.

La méthode par défaut consiste à utiliser ActorSelection et à attendre une réponse. À partir de cette réponse, vous utilisez la fonction Sender et enregistre le IactorRef . Vous pouvez utiliser le message intégré Identify une fois envoyé à un acteur, le récepteur répondra automatiquement avec ActorIdentity Message contenant IActorRef

Un exemple complet peut être trouvé aquí