NFS 共享文件访问问题答案

【问题标题】：NFS Share File Access IssueNFS 共享文件访问问题
【发布时间】：2017-01-20 18:17:30
【问题描述】：

我们在 AWS 上运行我们的测试环境，并在所有服务器上使用 NFS（EBS 文件系统）挂载来访问我们的文件。多个 java 进程访问此文件系统上的文件。应用程序服务器使用在其他系统上运行的不同消费者来处理文件。一个这样的消费者将文件转换为图像，但问题是应用程序服务器无法访问这些文件（file.exist() 为假）。现在奇怪的是它不能访问文件页面的第一个图像（有几个页面的文件），但它可以访问第二个页面等等。很多时候我观察到，奇数页图像无法访问，但我可以看到图像存在于那里。所以，我认为图像转换过程仍在访问图像，而应用程序服务器尝试访问它，但同样的问题不会出现在偶数页图像上。这些图像位于嵌套文件夹中，因此转换过程还会创建文件夹结构，然后将它们写入这些文件夹。知道这里可能是什么问题吗？有人在 AWS 上遇到 NFS 共享问题吗？

【问题讨论】：

标签： java linux amazon-web-services nfs

【解决方案1】：

这取决于您的应用程序的预期行为

NFS 非常适用于只读系统或对及时更新数据要求不高的程序

更多详情请查看此问题Alternative to File.exists() in Java

您可能想考虑 NFS 的替代品，例如 AWS EFS 或开源 Gluster

【讨论】：

CIFS 挂载是否也存在此问题，因为我将挂载更改为 CIFS，所以问题仍然存在。我想知道 EBS 是否是这里的根本原因。顺便说一句，使用“ls”命令问题消失了，我们终于可以获取所有图像文件，但是当我在访问 cifs 挂载中的文件之前删除“ls”时，它又回来了。
我怀疑它与EBS有关
好的，但我没有得到任何关于“CIFS”中“缓存”相关问题的参考。 CIFS 也有吗？
所有网络文件系统都使用某种缓存！您没有准确描述您的系统是如何工作的，但很容易想象共享文件系统的更新速度可能比试图在不同系统上协调操作的程序慢。这就是使用队列的系统如此受欢迎的原因
我们的系统使用队列（RabbitMQ），所以应用服务器只有在我们的消费者处理转换并且应用服务器从它那里得到回复后才会尝试访问图像。