使用Guava cache作为我自己的持久缓存的“助手”可行吗？

Question

我希望通过在服务提供者和服务客户端之间放置一个缓存层来减轻每次命中数据库的“查找服务”的压力。我希望这个缓存层是持久的，并且能够容纳比RAM所允许的更多的对象，所以一个普通的Guava Cache是做不到的。我研究过像EhCache和CouchBase这样的东西，但出于各种原因，我决定推出我自己的。

为这个持久缓存层编写简单的代码非常容易。然而，我对缓存有足够的了解，意识到有很多并发问题需要处理，而且我非常确定我不会在第一次就把所有问题都解决好。例如，存在“雷鸣的羊群”问题，其中缓存未命中可能导致对完全相同的对象的支持服务的大量同时请求。我突然意识到，这正是LoadingCache已经可以处理的事情。尝试让Guava来做处理并发的困难工作，并插入我自己的子类来进行实际的对象检索和存储，这看起来是合理的想法吗？我不确定我将子类或覆盖的确切界限在哪里，但如果这不是一个完全被误导的想法，我可以弄清楚。我还没有看到扩展/定制Guava缓存的示例，所以如果有任何示例和/或文档可供查看，我会对它们感兴趣的。

Answer 1

我最终做的事情非常简单。我创建了一个普通的LoadingCache，并在load和reload方法中执行了一些额外的操作。这给了我在本地数据库中查找对象的钩子(即CacheLoader的load和reload方法)，如果我找不到对象并持久化它，就调用远程服务，而不必担心由于Guava提供的所有并发保护，许多线程会试图获取相同的对象。

我确信这与缓存的使用方式相去甚远，因为我实际上将缓存上的maximumSize设置为0，以便始终调用我的加载函数。(由于各种原因，我希望每次都从持久存储中提供对象，而不是从RAM中)。我还没有彻底地测试它，但它似乎表现得像我想要的那样。总体效果是一个拉通的“对象镜像”，充当上游服务的自我更新副本。