“此外,可能存在无法彻底关闭应用程序的电源损耗,因此任何解决方案都必须具有能够在电源循环后继续存在的持久缓存。”
您已经有了使用 Hibernate 2 级缓存的解决方案。但是你没有说真正的要求是什么。你有一个不可靠的网络。没关系,你的电源不可靠。那也没关系。现在你想达到什么水平的服务?什么是可以接受的?
数据丢失是否可以接受?你能接受多少?你接受什么风险?
更明确地说,假设您有数据库的本地副本或至少有一部分。假设您知道如何排队/保存本地所做的修改。假设您将这些修改存储在硬盘驱动器上,以防断电。假设您可以在连接再次可用时将更改与主数据库合并。
这已经是很多假设了。好的,但是如果一个硬盘驱动器在电源故障后发生故障怎么办?您知道硬盘不喜欢断电,而且往往会在断电时损坏甚至损坏吗?
所以你装上一个RAID,并添加一个不间断电源。那很好。您从操作系统检测电源故障事件。完成您当前的交易并正确关闭。您的 RAID 保护您免受磁盘故障的影响。
好的,但是如果整个计算机停止运行会发生什么?万一发生火灾怎么办?还是水害?所有磁盘都将被管理,数据不可恢复,与中央数据库不同步的数据将丢失。是否可以接受?
即使打开wifi,电源也能正常工作……中央数据库的可靠性到底是多少?你有定期备份吗?还是集群解决方案?你确定你的中央数据库是可靠的吗?
从数据库的角度来看,很容易使用集群或备份并使用事务来确保数据一致性。您仍然可以丢失数据(如果不特别使用集群),但您应该能够恢复到上次备份,例如。
但是如果你想离线工作(数据库不可用),并且你不是唯一可以修改数据库的人,就会发生冲突。这不再是缓存、休眠或任何技术问题。
这是功能问题。当离线发生多次修改并且您必须合并时该怎么办?什么是可以接受的?什么不是。这可能是在重新连接时,应用最新的更改,旧的更改被丢弃。或者检测到潜在的冲突并提示用户处理它们。您可以尝试应用排队更改并应用所有更改...
我倾向于认为您可以提供“离线模式”,但您的用户必须知道他们处于离线状态,并且应该在中央数据库上永久更改并最终解决冲突时收到通知。但这是我的观点。