将 Java 应用程序数据冗余存储在文件中的最佳方法是什么？
如果我有基于实时数据的系统，如何确保所有当前信息都冗余存储在文件中？这样，当程序再次启动时，它会使用此信息将自身初始化回关闭时的位置。
我知道 xstream 和 HSQLDB。但不确定这是否是需要逐字复制的数据的最佳选择。
If I have systems that are based on realtime data, how can I ensure that all the information that is current is redundantly stored in a file? So that when the program starts again, it uses this information to initialize itself back to where it was when it closed.
I know of xstream and HSQLDB. but wasn't sure if this was the best option for data that needs to be a literal carbon copy.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这实际上完全取决于您存储的应用程序数据类型。如果您需要完全按照原来的方式重新创建 java 对象（即变量和状态相同），您可以序列化您需要的对象。序列化机制有很多，例如你提到的xstream。如果您直接存储对象，那么使用其中一种机制就可以了。
但是，很多时候，您想要存储应用程序的状态，这不一定直接对应于直接序列化对象。如果是这样的话，您可以只写出您需要的相关数据。您使用的存储类型取决于您的需求。如果您有大量数据，请考虑数据库。在平面文件中，较小的数量可能效果更好。
另一件事是，将数据冗余地存储在单个文件中似乎不太有用。如果文件损坏，您将丢失两个副本，因此如果担心冗余，请将其存储在不同的位置（即主数据库和备份数据库）。
没有一种正确的方法可以做到这一点，但希望这些想法可以帮助您入门。
It really all depends what type of app data you're storing. If you need to recreate java objects exactly how they were (i.e. variables and state the same), you can serialize the objects you need. There are many serialization mechanisms, for example, xstream as you mentioned. If you're storing objects directly, using one of those mechanisms would work.
But, a lot of times, you want to store the state of your application, which doesn't necessarily correspond directly to serializing objects directly. If that's the case, you can write out only the relevant data you need. The type of storage you use depends on your needs. If you have a large amount of data, consider a database. A smaller amount might work better in a flat file.
One other thing is that storing data redundantly in a single file doesn't seem too useful. If the file gets corrupted, you'll lose both copies, so if redundancy is a concern, store it in different places (i.e. a primary and backup database).
There's no one right way to do it, but hopefully these ideas get you started.
创建大量内存数据的文字副本（即快照）是昂贵的。每次更新内存数据时重复该过程可能会非常昂贵。您需要重新考虑您的应用程序架构。
一种方法是将实时数据提交到数据库，然后显示数据库中的数据以保持一致性。
第二种方法是提交到数据库并维护一个用于显示的并行内存数据结构。您还需要实现代码以在应用程序重新启动时从数据库重建内存中的数据结构。这是更多的代码，并且有更多的机会出现故障，用户在由于某些错误而重新启动后会看到不同的内容。
第三种方法是完全从内存数据结构工作并按如下方式处理数据持久性：
定期暂停处理更新并使用 xstream、java 序列化或其他方式拍摄整个内存数据结构的快照.
每个更新都需要以可重播的形式可靠地记录（带有时间戳）到一个或多个文件。
当应用程序重新启动时，您从上一个快照重新加载，然后重播自该快照以来到达的所有更新。
当应用程序重新
最后一种方法存在的问题是只有一个最新的稳定数据副本。如果由于硬盘或操作系统故障而丢失，那么您就完蛋了。在其他方法中，可以使用热备用数据库来解决此问题，该数据库是使用 RDBMS 对此类事物的现成支持实现的。
Creating a literal copy (i.e. a snapshot) of a large body of in-memory data is expensive. Repeating the process each time you get an update to the in-memory data is probably prohibitively expensive. You need to re-think your application architecture.
One approach is to commit your realtime data to a database as it comes in, and then display the data either from the database for coherency.
A second approach is to commit to a database and maintain a parallel in-memory data structure which you display from. You also need to implement code to rebuild the in-memory data structure from the database on application restart. This is more code, and there is more opportunity for glitches where the user sees different stuff after a restart due to some bug.
A third approach is to work entirely from an in-memory data structure and deal with data persistence as follows:
periodically, you suspend processing updates and take a snapshot of the entire in-memory data structure using xstream, java serialization or whatever.
every update needs to be reliably logged (with a timestamp) to a file or files in a form that can be replayed.
when the application restarts, you reload from the last snapshot and then replay all updates that arrived since the snapshot.
The last approach has the problem that there is only one up-to-date stable copy of the data. If that is lost due to a hard disc or OS failure, then you are toast. In the other approaches, this issue can be address using a hot standby database implemented using the RDBMS's off-the-shelf support for such things.