我正在使用 Mesos 和 Marathon 来管理应用程序部署，并在 Marathon https://github.com/mesosphere/marathon/issues/3783 中遇到了此错误，也就是说，部署期间的领导者选举会将实例数量缩减至 0。领导者选举发生得非常频繁(大约每 30 分钟一次)，因此我经常遇到这个问题。
我知道每 30 分钟一次是非常不规律的，因为我已经升级到 Marathon 1.3.10 并且过去 2 天没有选举，但是“正常”的频率是多少？正常情况下是否会发生领导人退位/选举，或者除非存在根本问题，否则我应该预期 0 次选举？一位同事向我建议，“领导人选举是正常的”，“一定数量的选举是正常的，是可以预料的”。我只是不相信这一点，并且想确切地知道。
请您参考如下方法:
如果您的 Marathon 每 30 分钟重新选举一次，这是不正常的。在正常情况下，Marathon 不应在维护发生(更新或重新启动)之前放弃或重新选举新的领导者。尽管如果发生这种情况，可能是由 4 个主要问题引起的(所有问题都会导致超时):
- 马拉松表现——当马拉松出现表现问题时，症状之一就是失去领导力。这是因为 Marathon 在给定的时间间隔内没有响应 Zookeeper，并被标记为消失。
- Marathon Zookeeper 连接问题 - 当网络延迟太高时(例如，Zookeeper 集群与 Marathon 位于不同的 DC)，某些更新可能会超时。这将导致失去领导地位。
- Zookeeper 性能 - 当 Zookeeper 有太多工作要做时，某些请求会超时，从而导致 Marathon 失去领导地位。
- 马拉松因
DELETE/v2/leader被迫放弃
要修复性能问题，请按照以下描述的步骤 here
- Shard your marathon.
- Monitor — enable metrics but remember to configure them.
- Update to 1.3.10 or later.
- Minimize Zookeeper communication latency and object size.
- Tune JVM — add more heap and CPUs :).
- Do not use the event bus — if you really need to, use filtered SSE, and accept it is asynchronous and events are delivered at most once.
- If you need task life cycle events, use a custom executor.
- Prefer batch deployments to many individual ones.
