我使用的是caffeine v2.8.5，我想创建一个具有基于以下条件的可变过期时间的缓存：
创建/更新价值和
此值的最后一次访问（读取）。
不管先到的是什么，都会触发删除该条目。
缓存将是值的三层解析的一部分：
密钥存在于咖啡因缓存中
使用此值
刷新访问/读取过期
密钥存在于redis数据库中
使用此值
将此值与redis键的剩余ttl（生存时间）一起存储在缓存中
密钥既不在内部缓存中，也不在redis中
从外部RESTAPI请求值
将此值存储在redis数据库中，固定过期时间为30天
将此值存储在咖啡因缓存中，固定过期时间为30天
redis被用作全局缓存，因此多个应用程序/示例可以共享缓存的数据，但是这种解析经常发生，不能用于每个请求，因此需要另一个缓存层。
根据请求的时间，请求的数据具有不同的ttl。因此，当我们请求restapi并且在redis中设置到期时间时，到期时间可能是固定的，但是在caffeine中，到期时间将是动态的，因为到期时间是基于redis密钥的剩余ttl。
案例（2）和（3）已经在我的cacheloader中为caffeine缓存解决了（我在read-through模式下使用缓存）。为了控制过期时间，我已经发现，我必须使用高级过期api，并且我还研究了类似的问题，如（为条目指定过期时间）和（在创建时间之后过期缓存值）。所以我为我的密钥设计了一个 Package 器对象，如下所示：

import lombok.Value;
import org.jetbrains.annotations.NotNull;
import org.jetbrains.annotations.Nullable;

import java.time.Instant;

@Value
public class ExpiringValue<ValueType> {

    @Nullable
    private final ValueType value;
    @NotNull
    private final Instant validUntil;
}

到期日是这样的：

import com.github.benmanes.caffeine.cache.Expiry;
import org.jetbrains.annotations.NotNull;

import java.time.Duration;
import java.time.Instant;

public final class ValueBasedExpiry<KeyType, ValueType extends ExpiringValue<?>> implements Expiry<KeyType, ValueType> {

    @Override
    public long expireAfterCreate(
        @NotNull final KeyType key,
        @NotNull final ValueType value,
        final long currentTime
    ) {
        return Duration.between(Instant.now(), value.getValidUntil()).toNanos();
    }

    @Override
    public long expireAfterUpdate(
        @NotNull final KeyType key,
        @NotNull final ValueType value,
        final long currentTime,
        final long currentDuration
    ) {
        return currentDuration;
    }

    @Override
    public long expireAfterRead(
        @NotNull final KeyType key,
        @NotNull final ValueType value,
        final long currentTime,
        final long currentDuration
    ) {
        return currentDuration;
    }
}

在我的用例中不同的是，我希望有一个基于值的最后一次访问的第二个过期标准。所以，如果一个小时内还没有收到请求，我想早点删除条目。如果它经常被访问，它最终会在ttl为零时被删除。
我将如何实现第二个标准？我不知道如何才能得到最后一次访问条目的时间。接口似乎没有提供这样的值。我也研究了这个问题。基于已排序到的调度程序bucket，将定期调用/重新评估方法是否正确？