我希望通过在服务提供者和服务客户端之间放置一个缓存层来减轻每次访问数据库的“查找服务”的压力。我希望这个缓存层是持久的,以适应比RAM允许更多的对象,因此一个vanilla Guava Cache不会这样做。我已经研究了像EhCache和CouchBase这样的东西,但由于各种原因我决定自己动手。
为这个持久性缓存层编写简单的代码非常容易。但是,我对缓存知之甚少,意识到要处理很多并发问题,我很确定我不会在第一次就把它们全部搞定。例如,存在“雷鸣般的群体”问题,其中高速缓存未命中可能导致对支持服务的大量同时请求针对完全相同的对象。让我感到震惊的是,这正是LoadingCache已经处理过的东西。试图让Guava完成处理并发的难题似乎是一个合理的想法,只需插入我自己的子类来进行实际的对象检索和存储?我不确定在子类或覆盖方面的确切界限在哪里,但如果这不仅仅是一个完全被误导的想法,我可以想出来。我还没有看到扩展/自定义Guava缓存的示例,所以如果有任何示例和/或文档要查看,我会对这些感兴趣。
答案 0 :(得分:2)
我最终做的很简单。我做了一个正常的LoadingCache,并在加载和重载方法中执行一些额外的操作。这给了我钩子(即CacheLoader的加载和重载方法)来查看我的本地数据库中的对象,如果我找不到它并调用远程服务并保持它,而不必担心许多线程会尝试由于Guava提供的所有并发保护,得到相同的对象。
我确定它与使用缓存的方式相差甚远,因为我实际上将缓存中的maximumSize设置为0,因此我的load函数总是被调用。 (由于各种原因,我希望每次都从持久存储中提供对象,而不是从RAM中提供。)我没有彻底测试它,但似乎表现得像我想要的那样。整体效果是一个直通的“对象镜像”,充当上游服务的自我更新副本。