Akka.net中的IActorRefs过多

如何解决Akka.net中的IActorRefs过多

让我说我具有以下Actor层次：

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

可以说，如果系统扩展并需要更多Actor以及用户ActorSelection not advised to use locally，则Actor E需要具有Actor I，J，K的IActorRef，在构造函数中传递Actor Ref会变得混乱。

在系统扩展时是否有适当且动态的方式获取ActorRef？

我已经考虑了很多问题，因为我可以问这个问题，因为它可以解释为基于意见的问题，但是我确实在努力地解决这个问题，因为我进行了很多搜索，目前尚不清楚什么是最佳实践之所以会遇到这个问题，是因为该代码可能会变得非常混乱且无法及时读取。

解决方法

只需开始发送消息，而不是尝试与（许多）其他Actor预先配置Actor。当有许多不同的参与者时，这确实使初始化变得复杂。另外：您不能将传递给构造函数的IActorRef句柄视为静态且永远有效：当Actor脱机时，您需要一种机制来检测该句柄并使该句柄为null或将其删除。群集中的其他Actor需要观看Akka日志消息..这些消息无法保证..等等。

相反：将新的Actor连接到群集时，请通过pubsub发出（推送）您的Identity。您的新Actor消息可能是：ActorSytem.Name + IActorRef + RoleString。

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

RoleString是Actor任务的描述符。其他角色可以根据RoleString决定注册您的IActorRef。

在此过程中，pubsub的其他订阅者（演员）将获取您的身份并存储您的身份。然后，它们通过相同的发布订阅者以相同的方式发出其身份。结果，您将在响应中收到所需的RoleString身份。其他群集节点（Actor）知道您存在。

当Actor需要断开连接时，请先发出pubsub消息，然后再实际断开Actor与群集的连接。这样，其他演员知道该演员下线了。

此策略的一个陷阱：防止无限的pubsub循环（I / O雪崩）。我使用的解决方案：通过测试自上一个pubsub消息以来的时间来防止Actor发送太多消息。放例如每分钟1条消息，而与其他Actor无关。这将导致心跳，而不是出现大量消息。并且会定期向您通知所有Actor的在线状态。在这种情况下，不需要退出/离线消息。

,

所以我查阅了文档并仔细阅读，发现有两种方法可以以干净的方式获取IActorRef。

默认方法是使用ActorSelection并等待回复，从该回复中使用Sender属性并存储IactorRef。您可以使用内置消息Identify，一旦发送给actor，接收方将自动以ActorIdentity条包含IActorRef的消息进行回复

可以找到完整的示例here