在每次迭代时序列化地图[关闭]答案

【问题标题】：Serialize the map on every iteration [closed]在每次迭代时序列化地图[关闭]
【发布时间】：2017-11-28 12:54:24
【问题描述】：

我有一个 ConcurrentHashMap，它存储 ID 和更新此 ID 时的时间戳。此数据将是持久的，因为应用程序重新启动应该知道调用关闭时数据的先前状态。我目前正在将地图序列化为关闭时的文件，并在应用程序重新启动时将其加载回来。

但是我可以预见，当磁盘已满时，关机时的序列化会失败。这意味着数据丢失是不可接受的。我曾想过使用数据库来存储数据，但它会在每次更新时增加网络权重。

我现在唯一想到的就是在每次更新时序列化地图。这将确保大多数数据在磁盘已满的情况下保持不变，即使在意外关闭的情况下也是如此。

我知道这是一项繁重的操作，我愿意接受替代解决方案。

另请注意，此地图可能包含超过 1200K 条目...

提前致谢

【问题讨论】：

拥有一个（本地）DB 似乎比在每次写入时序列化 1200k 条目要好。
最简单的方法是使用（本地）数据库。数据库保留事务日志以确保即使出现问题也不会丢失数据。序列化地图只是试图以糟糕和破碎的方式模仿这种机制。当然，您必须从使用并发映射更改为使用数据库，但这可能只是一种改进。
与其在每次更新时持久化整个地图，不如只持久化更新？
本地数据库绝对是要走的路（事务日志、自动恢复等）。此外，如果您正确调整和监控服务器，则永远不会发生磁盘已满错误 - 例如。例如，当达到 90% 时发出警报
@thomas。这是一个好主意。我会将更新写入一个单独的文件，并在关机时刷新这些更改并删除此文件。如果意外关闭该文件将不会被删除，并且在重新启动时我会找到更新文件。因此，首先将刷新此文件，然后接收更新的更改。

【解决方案1】：

如果您的方案允许一些数据丢失，那么一种解决方案可以是

1.定期保存哈希图的快照，因此在该时间间隔内最多会丢失数据。

2.对于严格的场景，您可以记录您的操作，以便您可以重播并获取原始值。并且由于日志是在末尾添加并且读取较少可能不会影响性能。在类似 zookeper 的 meta 中使用的日志基础技术数据存储。

3.或者您可以通过批量使用队列和进程来异步保存到某种数据库。

【讨论】：

谢谢。 1.我认为的解决方案，但它仍然会导致“一些”数据丢失，这是可以避免的。2。我更喜欢它，并且以这种方式实现它确实很有意义。 3. 严格禁止，因为这会增加我的维护，还会增加 db 不可用的情况...
为什么要严格拒绝 3.?除了异步部分，您可以使用内部数据库引擎（作为 jar 文件作为应用程序的一部分的数据库，并与您的应用程序一起启动和关闭。因此，几乎不需要维护、可恢复状态以及原子操作）。看看 Derby，或者 HSQL（Derby 似乎更好）
我的应用程序已经在使用多个工具。 MySQL、Apache ActiveMQ、Apache Cassandra、Elasticsearch。添加内存数据库肯定会增加我的维护
是否可以简单地序列化更新的地图部分？
我没有完全理解你的问题。你将如何获得零件图。如果它是某个对象，那么你可以编码为某个 json 并放入某个文件