scalacache记忆化异步刷新 [英] scalacache memoization asynchronous refresh

问题描述

我想在scala中使用主动刷新来进行基于TTL的备忘录.

I'd like to do a TTL based memoization with active refresh asynchronously in scala.

ScalaCache示例允许基于TTL的备注如下:

ScalaCache example in the documentation allows for TTL based memoization as follows:

import scalacache._
import memoization._

implicit val scalaCache = ScalaCache(new MyCache())

def getUser(id: Int): User = memoize(60 seconds) {
  // Do DB lookup here...
  User(id, s"user${id}")
}

好奇是否在TTL过期后为现有值触发数据库查找，是否在下一次getUser调用期间同步地和惰性地触发数据库查找，或者是否主动或异步地刷新(甚至在下一次getUser调用之前)刷新数据库.

Curious whether the DB lookup gets triggered after TTL expires for existing value, synchronously and lazily during the next getUser invocation, or if the refresh happens aggressively and asynchronously - even before the next getUser call.

如果ScalaCache实现是同步的，是否有一个备用库提供主动和异步刷新缓存的功能?

If the ScalaCache implementation is synchronous, is there an alternate library that provides ability to refresh cache actively and asynchronously ?

推荐答案

到期和刷新密切相关，但机制不同.过期的条目被认为是陈旧的，无法使用，因此必须将其丢弃并重新获取.符合刷新条件的条目表示内容仍然可以使用，但应重新提取数据，因为它可能已过时. Guava以expireAfterWrite和refreshAfterWrite的名称提供这些TTL策略，如果刷新时间小于到期时间，则可以将它们一起使用.

Expiration and refresh are closely related but different mechanisms. An expired entry is considered stale and cannot be used, so it must be discarded and refetched. An entry eligible for being refreshed means that the content is still valid to use, but the data should be refetched as it may be out of date. Guava provides these TTL policies under the names expireAfterWrite and refreshAfterWrite, which may be used together if the refresh time is smaller than the expiration time.

大多数缓存的设计都倾向于丢弃未使用的内容.主动刷新将需要一个专用线程来重新加载条目，而不管它们是否已被使用.因此，大多数缓存库本身都不提供主动刷新，但是使应用程序可以轻松地在顶部添加该自定义项.

The design of most caches prefer discarding unused content. An active refresh would require a dedicated thread that reloads entries regardless of whether they have been used. Therefore most caching libraries do not provide active refresh themselves, but make it easy for applications to add that customization on top.

当番石榴中的读物检测到该条目符合刷新条件时，该调用者将执行该操作.刷新过程中进行的所有后续读取都将获取当前值.这意味着刷新是在触发它的用户线程上同步执行的，而不是与读取该值的其他线程异步执行的.如果CacheLoader.reload被重写以在执行程序上执行工作，则刷新可能是完全异步的.

When a read in Guava detects that the entry is eligible for refresh, that caller will perform the operation. All subsequent reads while the refresh is in progress will obtain the current value. This means that to the refresh is performed synchronously on the user's thread that triggered it, and asynchronously to other threads reading that value. A refresh may be fully asynchronous if CacheLoader.reload is overridden to perform the work on an executor.

咖啡因是对Guava缓存的重写，并且由于始终以异步方式执行刷新而略有不同.用户线程.缓存将操作委派给执行程序，默认情况下为ForkJoinPool.commonPool，它是JVM范围内的执行程序. Policy api提供了检查缓存的运行时状态(例如条目的年龄)的方法，以添加特定于应用程序的自定义行为.

Caffeine is a rewrite of Guava's cache and differs slightly by always performing the refresh asynchronously to a user's thread. The cache delegates the operation to an executor, by default ForkJoinPool.commonPool which is a JVM-wide executor. The Policy api provides means of inspecting the runtime state of the cache, such as the age of an entry, for adding application-specific custom behavior.

对于其他ScalaCache后端支持是混合的. Ehcache具有一个RefreshAheadCache装饰器，该装饰器使用其自己的线程池延迟刷新. Redis和memcached不会刷新，因为它们不知道记录系统. LruMap具有到期支持，没有任何刷新功能.

For other ScalaCache backends support is mixed. Ehcache has a RefreshAheadCache decorator that refreshes lazily using its own threadpool. Redis and memcached do not refresh as they are not aware of the system of record. LruMap has expiration support grafted on and does not have any refresh capabilities.

这篇关于scalacache记忆化异步刷新的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！