但是，Consul不能在非常可扩展的环境中快速（无法访问节点）（大约需要72个小时？），这意味着Consul服务器列表会随着时间的推移不断增长，它们中的大多数都是“无法访问的”，到那时，集群将失去其仲裁。 / hashicorp / consul / issues / 454＃issuecomment-125767550
这些问题中的大多数是由于我们默认的行为而造成的，即
尝试宽限假。我们的思维模式是服务器寿命长，并且除了意外断电或进行正常维护外，不会由于任何原因关闭服务器，在这种情况下，您需要离开集群。回想起来，这是一个糟糕的默认设置。只需杀死-9个Consul服务器，就可以模拟仿真电源中断。
几乎可以避免所有这些情况。寿命长的节点。请记住，我们绝不会从自动缩放组中删除N / 2 + 1个实例。 EC2群集能够在任何时间到达大多数节点，并且应该能够投票决定是否应从Consul（或其他工具）群集中删除节点。
#1 楼
我将leave_on_terminate选项设置为true。根据文档leave_on_terminate如果启用，则当代理接收到TERM信号时，它将向离开的群集的其余部分发送“离开”消息，并且
离开。此功能的默认行为取决于
代理是作为客户端还是作为服务器运行（在Consul
0.7之前，默认值无条件设置为false）。在客户端模式下的代理上，此默认值为true，对于服务器模式下的代理，此
默认值为false。在关闭之前将SIGTERM发送给所有进程，在领事代理上使用此设置将离开集群，因此它将不被视为可以重启并在几个小时后返回集群的节点默认情况下。）
评论
启用此功能后，死去的客户领事会立即被收割还是会有延迟？我已经在客户端模式Consul上测试了此选项，并且在运行shutdown -h之后，仍然显示死节点...
–凯斯
19年11月20日在1:05
@Casper有多种可能无法按预期方式工作的方式，我想这取决于您的守护程序系统是否让足够的时间给consul-client正常停止（假设您未使用守护程序管理器启动客户端，而不是作为命令启动） ）
–滕西拜
19年11月20日在6:16
感谢您的答复，这已经有一段时间了：)因此，我的目标是使死节点的收获时间缩短，默认72小时太长，似乎无法自定义客户端节点的收获时间
–凯斯
19年11月20日在18:24
@Casper正如我上面所说，我们需要更多详细信息以提供建议，在systemd设置中，可以对停止部分进行调整，以使领事客户端在继续关闭过程之前能够正确停止，以便它可以自行删除，或者某处存在错误，但是根据当前信息，我们只能猜测，并且SE站点无法很好地适应这种调试
–滕西拜
19年11月20日在22:18
评论
我想如果没有更多数据就不可能找到有意义的答案，例如：您的实例人口有多少（数量）？您是否尝试调试底层的法定/共识机制，以查看导致非活动成员获得延迟的原因？实例删除的时间是什么时候，您是否跟踪过领事实例是否确实有时间将其消亡消息（是否优雅）发送给ASG的其余部分？您是以“服务器模式”还是“客户端模式”启动它们的？ Leave_on_terminate文档说“客户端模式”将默认为true。在我看来，以“服务器模式”启动的领事代理应该比您描述的更长寿
谢谢你们。 Tensibai的答案就是我们想要的。