问题描述
我们正在 Kubernetes 中运行我们的 mongock 脚本。我们的服务 pod 有副本，所以在初始化时第一个副本获取 mongock 锁，而第二个（和第三个）副本等待轮到他们。 mongock 锁按预期工作——一次只运行一个脚本——但是在释放锁和下一次执行获取它之间存在时间间隔。在我的测试中，这个差距大约是 3 分钟。我们有多达 30 个副本，因此这会显着增加 Pod 的启动时间。
这个差距是“死时间”——即我们的脚本在此期间没有做任何工作。我已经在我们的日志中验证了第一个脚本执行在下一个副本获取锁之前 3 分钟（左右）释放了锁。
驱动文档中有一个 maxWaitingForLockMinutes 设置：
https://www.mongock.io/spring#building-time-driver
如果我将其设置为较低的数字（例如 1 分钟），是否会减少第二次执行等待获取锁的时间？
我们已经使用 Spring 注解配置了 mongock。我已将这些属性添加到我们的 Spring application.properties 文件中（来自 mongock 在线文档的示例），但 mongock 似乎并未读取它们：
mongock:
change-log-repository-name: myChangeLogCollectionName
max-waiting-for-lock-minutes: 1
Spring application.properties 是这些的正确位置吗？
解决方法
实际上 max-waiting-for-lock-minutes 有另外的含义。我会试着解释一下：
如果为另一个进程获取了 300 秒的锁，则等待锁的 mongock 将仅等待那 300 秒（加上半秒的余量）。如果 max-waiting-for-lock-minutes 更大，它不会使用它，因为它知道它会更早发布，所以它被忽略。
但是，如果 max-waiting-for-lock-minutes 较小，则会引发异常，因为 Mongock 明白您不希望该服务等待那么长时间来尝试。
因此建议的配置始终是 max-waiting-for-lock-minutes 略大于 Lock-acquired-for-minutes，允许的最小值为 2 分钟。
正如在一个单独的主题中所讨论的，已经确定了这方面的改进，并将在 6 月左右发布的第 5 版中提供。不过，我们将很快提供具有此改进的 BETA 版本。