对文件的独占\同步访问（排队）答案

【问题标题】：Exclusive\Synchronized access to a file (Queuing)对文件的独占\同步访问（排队）
【发布时间】：2014-05-19 16:39:06
【问题描述】：

我们有一个共享文件夹，其中包含一些需要处理的文件。我们还有 3 台 UNIX 服务器，它们运行一个 shell 脚本，每次获取并处理一个文件。在脚本的末尾，它被移走的文件。 3 UNIX服务器不相互通信，相互不了解。

在您看来，保证每个文件将被处理一次而不引发并发访问问题\错误的最佳方法是什么？

【问题讨论】：

查找文件，将文件重命名为“filename.lock.servername”作为脚本中的第一个操作。忽略文件查找阶段中所有以“.lock.servername”结尾的文件

【解决方案1】：

您需要某种类型的文件锁定机制。一些可能性：

您可以为工作中的每个文件创建一个临时锁定文件。例如，对于文件name.ext，您需要在开始处理之前创建一个name.ext.lock。如果这个文件已经存在 - 同样，创建失败并显示“文件存在”，这意味着有人已经在处理它，因此你不应该对它做任何事情。
其次，您可以使用咨询锁。咨询锁定不适用于每种类型的文件共享，并且它们只有 libc 级别的接口，因此您不能在 shell 脚本中使用它们。我建议深入研究flock libc api 调用的手册。
第三，它是最难的，而且它与 unix 密切相关。这是强制锁定。强制锁定意味着锁定即使对不知道任何信息的进程也是有效的。你可以在这里阅读更多关于它们的信息：Mandatory file lock on linux

如果我可以修改处理的工作方式（例如，如果我可以将它们与脚本挂钩，甚至我正在开发处理脚本），那么我在你的位置上做了第一个。如果没有，您可能需要第三个，尽管它并不总是有效。

【讨论】：

非常感谢 Peter，特别是关于建议 #2 和 #3。我会等待一段时间以听取其他可能的方法，然后我会将您的答案标记为已接受
我觉得如果你使用第一种方法，你应该注意竞态条件问题。当然flock函数会为我们做这个，但它不适合shell脚本。
@zhujs 你能解释一下“竞争条件”的问题吗？
@zhujs 我想我找到了：stackoverflow.com/questions/34510/what-is-a-race-condition
@Duncan_McCloud & zhujs 是的，你是对的。当然，您应该使用 atomic 操作来执行此锁定 only！例如，如果不存在某事.lck；然后创建一些东西.lck;fi 不行！一个非常令人愉快的原子操作是 mkdir，或者可能是原子触摸。我开始了一个关于此案的有趣线程，但我建议在另一个问题中进行。