我正在使用Mesos和Marathon来管理应用程序部署，并且在Marathon https://github.com/mesosphere/marathon/issues/3783中遇到了此错误，这就是说部署期间的领导者选举会将实例缩小为0。领导者选举非常频繁（大约发生）每30分钟一次），因此我经常遇到此问题。
我知道每30分钟一次是非常不规律的，因为自从升级到Marathon 1.3.10以来，过去两天都没有选举，但是“正常”的频率有多高？领导者退位/选举是在正常情况下发生的吗？或者除非存在根本问题，否则我应该期望进行0次选举吗？一位同事向我建议，“领导人选举是正常的”，“一定数量的选举是正常的，并且是可以预期的”。我只是不相信，并且想知道。
最佳答案
如果您的马拉松比赛每30分钟重跑一次，这是不正常的。在正常情况下，在进行维护（更新或重新启动）之前，Marathon不应退位或改任新的负责人。尽管如果发生这种情况，可能是由4个主要问题引起的（所有结果均导致超时）：
马拉松表现-马拉松出现表现问题时，症状之一就是失去领导能力。这是因为Marathon在给定的时间间隔内未响应Zookeeper，并且被标记为已消失。
Marathon Zookeeper连接问题-当网络延迟过高（例如，Zookeeper群集位于与Marathon不同的DC中）时，某些更新可能会超时。这将导致领导层松动。
Zookeeper的性能-当Zookeeper要做很多工作时，它将使某些请求超时，从而导致马拉松失去领导能力。
马拉松比赛被DELETE /v2/leader退位
要解决性能问题，请执行以下here中所述的步骤
马拉松。
监控器—启用指标，但请记住进行配置。
更新到1.3.10或更高版本。
最小化Zookeeper通信延迟和对象大小。
调整JVM-添加更多的堆和CPU :)。
不要使用事件总线-如果确实需要，请使用过滤的SSE，并接受它是异步的，并且事件最多只能传递一次。
如果您需要任务生命周期事件，请使用自定义执行程序。
与许多单独的部署相比，批量部署更可取。