破解远程/虚拟磁盘上的“真正”Java刷新

Question

我正在寻找一个“技巧”或“黑客”来确定文件是否已经存储在远程磁盘上，通过vmware缓存，NAS缓存等等。

刷新和关闭FileOutputStream是不够的。我认为Channel.force（true）既不是。

我正在考虑这样的事情：

• 写入文件并回读文件
• 写入文件，检查时间戳，重命名文件，检查其他时间戳
• 使用“错误内容”编写文件，使用原始内容覆盖，阅读并检查内容

也许有人遇到同样的问题并找到了解决方案。

我的要求是不要丢失数据。 java应用程序以这种方式工作：

1. 接受来自远程来源的文件
2. 添加数字签名和经过认证的时间戳，以创建新文件。如果此文件丢失，则无法以任何方式重新创建。
3. 将此文件写入存储
4. 将文件标记为在数据库上签名
5. 告诉偏远方一切正常

今晚我们发生了一次崩溃，并且在第5步之后但是在将数据实际刷新到远程存储之前有三次交易失败。所以数据库说一切都很好，远程端被告知相同，但15秒的签名数据丢失了。这不好。

正确的解决方案可能是对远程文件系统进行“同步安装”。但这不会在短时间内发生。即使在这种情况下，鉴于应用程序在VMWare服务器上运行，我也不完全信任这种情况。

所以我希望有一个“尽力而为”的黑客来预防（缓解）像这样的事件。

Answer 1

让我们从一个假设开始：您无法保证对任何单个磁盘进行任何单次写入。在您的写入和磁盘盘片之间存在太多的软件和硬件层。即使您可以保证写入，也无法保证数据可读。磁盘可能会在写入和读取之间崩溃。

仅解决方案是冗余，由框架（例如RDMS）或您的应用程序提供。

当您收到并签署文件时，您需要将其发送到不同物理主机上的多个目的地，并等待他们回复他们保存文件。其中一个可能会崩溃。其中两个可能会崩溃。数据的重要性将决定您需要多少个远程主机。

顺便提一下，冗余也适用于您的数据库。提交事务并不意味着您可以在数据库崩溃后恢复它（尽管DBMS工程师在确保写入方面拥有 lot 更多的经验，所有这些取决于系统管理员谁理解“日志和数据文件必须驻留在不同的物理驱动器上”之类的东西。我强烈建议您（冗余地）存储足够的元数据和文件，以便能够重建数据库条目。