我正在测试的是以下情况：
启动2个Lighthouses，然后启动作为集群成员的3个服务。它的种子节点配置为先前启动的两个Lighthouses。
现在，这第三个服务的HOCON设置为绑定到端口0，这是它的工作，并且为我提供了随机端口。
现在，当我强制退出此服务以模拟崩溃时，Akka.Net的日志记录输出会变得真实（重要部分）
AssociationError ...试图与无法访问的远程地址相关联 现在，该地址的门控时间为5000ms。由于目标计算机主动拒绝了该连接，因此无法建立连接。
似乎永远持续下去。我认为这可能是无害的，而且看起来像是一个可怕的错误。该消息本身很有意义，服务实际上已经消失了，因此它无法并且永远无法连接。
现在，如果我重新启动服务，因为它已配置为与Akka绑定到0。进行远程处理时，它将获得一个全新的端口，因此其他失败服务的Unreachable状态将永远无法解决
这是预期的行为吗？我还认为这里可能有一个配置设置：
auto-down-unreachable-after
现在，它带有有关以下内容的警告：
使用自动关闭功能意味着在网络分区的情况下将自动形成两个单独的群集。
设置此项不会使消息静音：
auto-down-unreachable-after = 3s
在节点被标记为不可达后，我收到一条新消息：
与具有UID [983892349]的[akka.tcp：// ClusterName @ localhost：58977]的关联无法恢复。现在，UID已被隔离，并且发送到该UID的所有邮件都将被传递为无效字母。必须重新启动远程角色系统才能从这种情况中恢复。
必须重新启动远程actor系统，以从这种情况下恢复。似乎很严重，应该避免。同时，由于服务在随机端口上加入，因此无法恢复。在尝试获取有关UID的更多知识时，似乎在内部分配了该知识。因此，我只能猜测以后与UID不会发生任何冲突，因此这是正确的行为。
这似乎是
之外的唯一选择log-info = off
仅使日志静音
答案 0 :(得分：0)
我认为灯塔服务的日志记录很健谈，对吗？这是Akka八卦协议试图与崩溃节点通信的“正常”行为。发生这种情况时，您必须配置要执行的操作。
解决此问题的方法在每种情况下并不总是相同的。例如，这可能取决于您是否在云微服务平台上运行服务。但是，选择之一的确是“自动下降”。这会将服务标记为“ UNREACHABLE”（如您所见）。这意味着该节点不在群集之外，但是群集在没有崩溃节点的情况下继续运行。这就是同一节点无法加入的原因，因为它仍被标记为“ UNREACHABLE”。
请注意，自动关闭可能会导致群集的“裂脑”，其中群集的两个部分（例如，一个由4个节点组成的群集被分成两个由2个节点组成的群集）。这是您不希望出现的情况，因此这可能不是最佳解决方案！
Akka.NET还可以配置一些其他解决方案来正确处理此问题：“裂脑解析器”。有关如何进行配置的更多信息：https://getakka.net/articles/clustering/split-brain-resolver.html
这些都是防止“裂脑”情况的策略，将涉及牺牲节点以保持群集一致。将这些策略与微服务编排平台结合使用（以使实例在崩溃/退出后重新启动），以创建理想的自我修复Akka群集。