管理员指南

本节包含对使用 oslo.concurrency 的服务管理员有用的信息。

锁文件管理

对于使用 oslo.concurrency 的外部锁定功能进行进程间锁定的服务，锁文件将存储在 lock_path 配置选项中 oslo_concurrency 部分指定的目录中。oslo.concurrency 不会自动删除这些锁文件，因为库无法知道服务何时完成使用锁，并且删除服务正在持有的锁文件会导致并发问题。有些服务会在完成使用锁文件后删除它们，但只有服务本身才能在服务运行时删除其锁文件。外部清理方法无法合理地知道何时不再需要锁。

但是，为了防止 lock_path 目录无限增长，偶尔删除其中的所有锁文件是一个好主意。执行此操作的唯一安全时间是在服务未运行时，例如在重新启动后或服务停机维护期间。在后一种情况下，请确保所有相关服务（例如 api、worker、conductor 等）都已关闭。如果仍有任何可能持有锁的进程在运行，则删除锁文件可能会导致服务的不一致性。一种可能的清理方法是将 lock_path 放在 tmpfs 中，以便在重新启动时自动清除。

请注意，通常，剩余的锁文件最多只是一个外观上的小问题。如果您因锁文件数量过多而遇到功能问题，请向 Oslo 团队报告，以便我们研究其他缓解策略。

常见问题解答

锁文件问题历史是什么？

每隔几个月就会出现一次，OpenStack 的部署者注意到他们周围有大量看起来未使用的锁文件。邮件列表中会发起一个讨论，Oslo 的开发者需要解释为什么它按其工作方式运行。本常见问题解答旨在成为对通常给出的临时解释的官方替代。

负责此行为的代码实际上已移动到 fasteners 项目，并且有一个 问题 解决了剩余的锁文件。它涵盖了问题的许多技术历史，以及一些提出的解决方案。

为什么还没有解决这个问题？

据 Oslo 开发者所知，没有人因为剩余的锁文件而遇到功能问题。这使得它成为一个优先级较低的问题，并且由于修复它的复杂性，没有人能够做到。如果发现功能问题，应将其报告为 oslo.concurrency 的错误，以便进行跟踪。与此同时，这可能仍被视为一个外观上的小问题，并相应地确定优先级。

为什么锁释放时锁文件不被删除？

在我们的测试中，当锁文件在另一个进程等待它时被删除时，它会在任何等待被删除文件的进程和任何尝试在删除后锁定文件的进程之间创建了一种“分裂脑”的情况。本质上，两个进程最终可能同时持有相同的锁，这使得这成为一个不可接受的解决方案。

为什么不使用其他进程间锁定方法？

我们尝试过了。Posix 和 SysV IPC 都被探索为替代方案。不幸的是，两者在 Linux 上都有重大问题。如果持有它们的进程崩溃，Posix 锁无法被打破（至少在不重新启动的情况下）。SysV 锁具有有限范围的数字 ID，并且由于 oslo.concurrency 支持基于字符串的锁名称，因此在哈希名称时发生冲突的可能性太高。被认为拥有始终有效的基于文件的锁定机制比引入严重新问题的其他方法更好。

附加问题：为什么 lock_path 不默认设置为临时目录？

因为可能需要持有锁的每个进程都必须使用相同的值 lock_path，否则它将变得无用。如果我们允许 lock_path 未设置，并在启动时创建一个临时目录，则每个进程将创建自己的临时目录，并且它们之间将不会有实际的协调。

虽然这与锁文件问题不直接相关，但它是关于 oslo.concurrency 的另一个常见问题，因此有必要在此处提及。