5

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

刷新和关闭 FileOutputStream 是不够的。我认为 Channel.force(true) 两者都不是。

我正在考虑这样的事情：

  • 写入文件并读回文件
  • 写入文件，检查时间戳，重命名文件，检查不同的时间戳
  • 用“错误的内容”写入文件，用原始内容覆盖，读回并检查内容

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

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

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

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

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

所以我想有一个“尽力而为”来防止（减轻）像这样的事件。

4

1 回答 1

2

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

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

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

顺便说一句，冗余也适用于您的数据库。事务已提交这一事实并不意味着您能够在数据库崩溃后恢复它（尽管 DBMS 工程师在确保写入方面比您或我有更多的经验，但所有这一切都取决于了解事物的系统管理员比如“日志和数据文件必须驻留在不同的物理驱动器上）。我强烈建议您（冗余地）将足够的元数据与文件一起存储，以便能够重建数据库条目。

于 2012-10-02T16:28:55.880 回答