我正在设计一个必须使用来自多个来源的实时数据并定期报告的应用程序。使用的数据将添加到 Ehcache 缓存中，报告将查询它。一旦使用了实时数据，就需要将其持久化以仅用于恢复目的。如果应用程序重新启动，它将在连接到实时数据源(将新数据排队)之前使用数据库中的历史数据填充缓存。
我倾向于将其实现为具有 JDBC 缓存的缓存:
1.从源头接收数据
2.持久化到DB
3.加入缓存
4.确认收货来源
2-4 包装在 JTA 事务中。
我还研究了将 Ehcache 作为二级缓存的 Hibernate，但这似乎不合适。
我是 Ehcache 的新手，所以想得到一些关于正确设计的建议。
最佳答案
为了持久化，而不是做一个“cache-aside”，您可能希望将您的缓存配置为使用 read-through 和一些缓存写入器(write-through 或 write-behind)。您可以在这里阅读这些内容:http://ehcache.org/documentation/user-guide/concepts#cache-as-sor 现在我会避免使用 JTA，因为我担心开销可能会过大(除非您确实需要 XA 事务恢复)，而是选择容错方法。如果您选择异步持久化(后写)，使用 Terracotta 集群缓存(WriteBehind 队列将自动持久化、可恢复，如果有多个节点可用，甚至是 HA)是确保每个元素都写到底层的一种方法SoR ...我想这完全取决于您的需求。
Ehcache 让您从单一节点、非集群方法开始，只需使用读写缓存，您可以扩展和微调以满足您的 SLA。随着数据的增长，您将能够转移到集群缓存和异步写入器(如果写入成为问题)或增加缓存大小(如果读取仍然是问题)。显然，您应该衡量(或者至少知道您预见到的瓶颈是什么)并做出相应的选择。但是将缓存放在 RDBMS 前面是一种常见且易于理解的模式，可以扩展对这些“较慢”存储的读取(和写入)访问...
关于java - Ehcache 与 DB 持久化设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9335286/