Question

如果启用了overflowToDisk并且配置了Disk path，那么如果在内存中找不到数据，它是否会自动从diskpath进行搜索？

参考上述配置

When overFlowToDisk gets activated in EHCACHE?

我的案例

1）在应用程序启动之前从DB缓存预热

2）使用加载程序实现从DB加载数据

3）最初DB有2000个数据。所以我们在DISK中有1000个内存（ABC_007），其余1000个。

这是对的吗？

 <cache name="ABC_007"
           maxElementsInMemory="1000"
           maxElementsOnDisk="10000"
           overflowToDisk="true"
           timeToIdleSeconds="..."
           timeToLiveSeconds="...">
    </cache>

如果我搜索的数据不在ABC_007中，它将从DISKPATH中检索。我是对的吗？

现在，如果我实现缓存读取功能，如果数据在缓存（包括磁盘路径）中不可用，我应该在数据库中搜索。

现在我找到了数据。它是否重新填充缓存？

如果ABC_007仍包含1000个元素。它将被存储在哪里？ ABC_007或磁盘？

请纠正我的理解。

例如，请参阅示例代码

Cache cache = manager.getCache("ABC_007");

Element element = null;

String key = null;

for (int i=0 ; i<2000 ; i++) {

key =  "keyInCache" + i ;

element = new Element (key , "value1");
cache.put(element);

}

现在当我跨越1000然后根据配置，1001到2000个元素将存储在磁盘中。

 <cache name="ABC_007"
           maxElementsInMemory="1000"
           maxElementsOnDisk="10000"
           overflowToDisk="true"
           timeToIdleSeconds="..."
           timeToLiveSeconds="...">

我是对的吗？

现在我想要

的价值

Key = keyInCache1700

element = cache.get(key);

从哪里获得价值？

我的理解 - 如ABC_007 cache has maxElementsInMemory="1000"，这意味着它可以在内存中输入高达1000的键值，并且将从磁盘中检索键keyInCache1700的值...

AM我纠正？

Answer 1

答案取决于您的Ehcache版本。

从Ehcache 2.6开始，存储模型不再是溢出模型，而是分层存储模型。在分层存储模型中，所有数据始终存在于最低层中。项目将根据 hotness 出现在更高层中。

开源Ehcache的可能层是：

JVM堆上的堆上
磁盘是最低的

根据定义，高层的延迟较低，但容量较低层低。

因此，对于配置了overflowToDisk的缓存，所有数据将始终位于磁盘层内。它会将密钥存储在内存中，将数据存储在磁盘上。

在缓存中查找条目时，将从最高到最低考虑这些层。在您的示例中，将按如下方式检索数据：

在内存中搜索
- 如果找到，请将其退回
在磁盘上搜索
- 如果找到，请添加到内存层（热数据）并返回它。这可能导致另一个条目被从内存驱逐
使用缓存加载程序从数据库中检索它
- 找到后，将其添加到缓存中并将其返回

Answer 2

我将概述/总结我对EHCache如何运作的粗略概念：

它本质上是一个HashMap。
它始终将密钥的HashMap保存在内存中。
项目的实际内容可以存储在内存中，或者（当有足够的项目时）溢出到磁盘。

结论：我的理解是EHCache知道它缓存了哪些密钥，以及当前存储项目的位置。这是缓存快速检索项目的基本必要条件。

如果EHCache不知道某个项目，我不会指望它会在磁盘上查找它。

你应该在使用缓存时实现“read-thru to DB”逻辑。显然，必须从数据库中读取缓存中未找到的项目。当时将它们添加到缓存中会将它们放在内存中，因为它们目前很热（最近使用过）。

从文件系统或磁盘路径读取缓存数据

我是对的吗？

2 个答案: