我们将数据从代理发送到集群节点。
我真的不明白你的意思。我也不明白你说的“集群节点”和“节点代理”节点是什么意思。我认为你的意思是你使用节点角色，只有两个节点参与实体分片（其他三个节点只有代理）。由于集群太小，我觉得这不是一个好的设计，但我认为这与您的问题没有直接关系。
在发送给实体Actor之前，我们通过调用Actor Selection来检查Actor是否是活动的。
您是否正在单独查询每个可能的节点？（因为参与者选择将包括节点。）出于多种原因，这似乎是一个非常糟糕的主意。
首先，我们使用Auto-down when unreachable来关闭一个无法访问的节点。但总有一天它会摧毁星团。所以我们把它关掉了。
根据其他问题的评论，我相信你指的是down-all-when-unstable。这表明您的网络稳定性非常、非常、非常差。这个设置是集群中的一个故障保护，基本上是说“如果网络非常不可靠，没有安全的方式继续，请关闭集群”。
我永远不会建议在此设置下运行群集，因为：
（1）是为了确保安全。如果你把它关掉，你就是在邀请不一致。
B）如果它触发了，那么你的网络中有大量的问题需要解决。
如果任何节点重新启动，它将作为WeaklyUp加入，因为分配了新端口。
我不知道你的意思是“因为新的端口被分配”。根据定义，当新节点重新加入时，它已经有了一个新端口，因为它必须将该端口作为加入的一部分进行通信。
但不管怎样，虚弱不是由这样的事情引起的。当领导者已经认识到一个新的节点，但还没有建立共识时，就会出现这种情况。对于一个巨大的集群，这可能是正常的，因为新的节点信息是传播的。但是对于像你这样的小集群，如果这种状态持续超过几毫秒，这是另一个迹象，表明你有大规模的网络问题，导致节点无法一致地分享八卦。
如果我想对你的系统进行故障排除，我需要所有的集群日志。但是，从给出的信息来看，所有迹象似乎都指向操作系统层面的网络问题，而Akka只是在面对潜在的网络不稳定性时努力保持一致。

• 所有节点是否都在同一子网中？
• 是否所有节点都具有低延迟？我不认为有任何硬性的指导方针，但我会寻找<10毫秒。运行扩展的ping测试以查看延迟和丢弃率。
• 有防火墙吗？
• Akka日志中显示了哪些集群和网络警告/错误？