不可靠网络和低带宽的 Java ORM 策略

我正在寻找 Hibernate 作为需要在不可靠网络中工作的系统。我们需要对一个中央数据库进行读写访问，但它可以通过一个相当不稳定的 Wi-Fi 网络来访问。此外，可能会出现断电而导致应用程序无法完全关闭的情况，因此任何解决方案都必须具有能够在电源周期后继续存在的持久缓存。最后，这是一个只有适度内存和磁盘空间的嵌入式系统，因此例如对数据库进行全面复制并不是一个可行的策略。

我对 Hibernate 2 级缓存有基本的了解，我想知道是否可以使用 Ehcache 之类的东西来配置它来解决这个问题，但其主要目的似乎是性能而不是可用性，所以我不知道可能存在哪些陷阱。

我也很愿意考虑涉及复制到本地数据库的其他策略。我宁愿自己不必做太多繁重的工作来实现这一点。

寻找一些经验或可能的替代方案。

“此外，可能会出现断电而无法彻底关闭应用程序的情况，因此任何解决方案都必须具有能够在电源循环后继续存在的持久缓存。”

您心中已经有了 Hibernate 2 级缓存的解决方案。但你没有说真正的要求是什么。您的网络不可靠。没关系，你的电源不可靠。那也可以。现在您希望达到什么水平的服务？什么是可以接受的，什么是不可以接受的？

数据丢失是否可以接受？你能接受多少？您接受什么风险？

更明确地说，假设您有数据库的本地副本或至少是数据库的一部分。假设您知道如何对本地进行的修改进行排队/保存。假设您将这些修改存储在硬盘上，以便在断电时保持安全。假设当连接再次可用时，您可以将更改与主数据库合并。

这已经是很多假设了。好的，但是如果一个硬盘在断电后出现故障怎么办？您知道硬盘不喜欢断电，并且很容易在断电时损坏甚至损坏吗？

因此，您建立了 RAID，并添加了不间断电源。那很好。您从操作系统检测电源故障事件。完成当前交易并正确关闭。 RAID 可保护您免受磁盘故障的影响。

好的，但是如果整个计算机停止运行会发生什么？发生火灾时会发生什么？还是水害？所有磁盘都将被管理，数据不可恢复，未与中央数据库同步的数据将丢失。可以接受吗？

即使wifi打开，电源也能正常工作......中央数据库的可靠性到底如何？您有定期备份吗？或者集群解决方案？您确定您的中央数据库可靠吗？

从数据库的角度来看，很容易使用集群或备份并使用事务来保证数据一致性。您仍然可能丢失数据（如果特别不使用集群），但您应该能够恢复到例如上次备份。

但是，如果您想脱机工作（数据库不可用），并且您不是唯一可以修改数据库的人，则会发生冲突。这不再是缓存、休眠或任何技术问题。

这是功能问题。当离线发生多个修改并且必须合并时该怎么办？什么是可以接受的？什么不是。这可能是在重新连接时，应用最新的更改，旧的更改被丢弃。或者检测到潜在的冲突并提示用户处理它们。您可以尝试应用排队更改并应用所有更改...

我倾向于认为您可以提供“离线模式”，但您的用户必须知道他们处于离线状态，并且当更改在中央数据库上永久生效并最终解决冲突时，应该收到通知。但这是我的观点。