需要一些有关 Auto Downing 和 WeaklyUp Members 的说明。
我们将数据从代理发送到集群节点。在发送到实体 Actor 之前，我们通过调用 Actor Selection 来检查该 Actor 是否处于活动状态。
首先，我们使用无法访问时自动关闭来关闭无法访问的节点。 但它有时会破坏集群。所以我们把它关掉了。
当所有节点都向上时，Actor 选择非常快（<10 ms) & we can send the data from Proxy to Cluster very fast.
如果任何节点重新启动，它就会作为 WeaklyUp 加入，因为分配了新端口。
如果集群中有任何weaklyUp成员可用，则Actor选择将花费超过20秒以上。所以发送数据到集群太慢了。
这里的行为是什么？
我们怎样才能避免这种情况呢？
为什么 WeaklyUp 成员使集群变慢。？
我们将数据从代理发送到集群节点。
我不太明白你的意思。我也不明白你所说的“集群节点”和“节点代理”节点是什么意思。我认为你的意思是你使用节点角色只有两个节点参与实体分片（而其他三个节点只有代理）。由于您的集群很小，这对我来说似乎不是一个好的设计，但我认为这与您的问题没有直接关系。
在发送到实体 Actor 之前，我们通过调用 Actor Selection 来检查该 Actor 是否处于活动状态。
您是否单独查询每个可能的节点？ （因为参与者选择将包括节点。）出于多种原因，这似乎是一个非常糟糕的主意。
首先，我们使用无法访问时自动关闭来关闭无法访问的节点。但它有时会破坏集群。所以我们把它关掉了。
根据其他问题的其他评论，我相信你的意思是
down-all-when-unstable我绝不会建议在关闭此设置的情况下运行集群，例如：
A) 它的存在是为了确保安全。如果您将其关闭，则会导致不一致。
B) 如果它触发了您的网络中存在大量问题，需要需要解决。
如果任何节点重新启动，它将作为 WeaklyUp 加入，因为分配了新端口。
我不确定你的意思“因为分配了新端口”。根据定义，当新节点重新加入时，它已经有了一个新端口，因为它必须在加入过程中与该端口进行通信。
无论如何，WeaklyUp 并不是由此类原因引起的。这是当领导者已经认可了一个新节点但尚未达成共识时引起的。对于一个巨大的集群，随着新节点信息的传播，这可能有点正常。但是对于像您这样的小型集群，如果这种状态持续超过几毫秒，则表明您遇到了大规模网络问题，导致节点无法一致地共享八卦。
如果我尝试对您的系统进行故障排除，我需要所有集群日志。但是，从提供的信息来看，所有迹象似乎都表明操作系统级别的网络存在问题，而 Akka 只是在面对底层网络不稳定的情况下努力保持一致。