c# - Akka.net 中的 IActorRefs 太多

Question

假设我有以下 Actor 层次结构:

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

假设 Actor E 需要拥有 Actor I、J、K 的 IActorRef，如果系统扩展并需要更多 Actor ，并且用户 ActorSelection not advised to use locally，则在构造函数中传递 Actor Ref 会变得困惑。 .
随着系统的扩展，是否有一种适当且动态的方式来获取 ActorRef ？
我想了很多关于我是否应该问这个问题，因为它可以解释为基于意见的问题，但我真的很纠结这个问题，因为我已经搜索了很多，目前还不清楚这个问题的最佳实践是什么因为代码可能会变得非常困惑和不可读。

Answer 1

只需开始发送消息，而不是尝试使用(许多)其他 Actor 预先配置 Actor。当有许多不同的 Actor 时，它确实使初始化变得复杂。另外:您不能将传递给构造函数的 IActorRef 句柄视为静态且永远有效:当 Actor 脱机时，您需要一种机制来检测它并将其句柄置空，或将其删除。集群中的其他 Actors 需要查看 Akka 日志消息.. 不能保证.. 等..
相反:当您将新 Actor 连接到集群时，通过发布订阅发布(推送)您的身份。您的新 Actor 消息可以是:ActorSytem.Name+IActorRef+RoleString。
https://getakka.net/articles/clustering/distributed-publish-subscribe.html
RoleString 是 Actor 任务的描述符。其他参与者可以根据 RoleString 决定注册您的 IActorRef。
在此过程中，pubsub 的其他订阅者( Actor )将获取您的身份并存储您的身份。然后，他们通过相同的 pubsub 以相同的方式发出他们的身份。结果，您将在响应中收到您需要的 RoleString 身份……并且其他集群节点(Actor)知道您存在。
当 Actor 需要断开连接时，在实际断开 Actor 与集群的连接之前，首先发出 pubsub 消息。这样做，其他 Actor 知道 Actor 下线。
这种策略的一个陷阱:防止无休止的 pubsub 循环(I/O avalange)。我使用的解决方案:通过测试自上次发布订阅消息以来的时间来防止 Actor 发送过多消息。把例如每分钟 1 条消息，与其他 Actor 无关。这将导致心跳，而不是大量消息。并且您会定期收到所有 Actor 的在线状态的通知。在这种情况下不需要退出/离线消息。