JAVA 使用 Caffeine 本地缓存命中率低？手动预热与权重缓存实现 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Caffeine 本地缓存命中率低？手动预热与权重缓存实现

大家好，今天我们来深入探讨一个在使用 Caffeine 本地缓存时经常遇到的问题：命中率低。我们将分析导致低命中率的常见原因，并探讨如何通过手动预热和权重缓存等技术来优化 Caffeine 的使用，显著提升缓存效率。

命中率低的常见原因分析

Caffeine 作为高性能的本地缓存，在很多场景下都能显著提升应用性能。然而，如果配置不当或使用方式不合理，反而会导致命中率很低，甚至低于预期，反而带来了额外的性能损耗。以下是一些常见的导致 Caffeine 缓存命中率低的原因：

缓存容量不足： 这是最常见的原因。如果缓存容量太小，无法容纳足够多的热点数据，导致频繁的缓存淘汰，自然命中率就会降低。
缓存淘汰策略不适用： Caffeine 提供了多种淘汰策略，如 LRU (Least Recently Used)、LFU (Least Frequently Used) 和 TinyLFU。如果选择的策略不适合当前的应用场景，例如，数据访问模式更符合 LFU，却使用了 LRU，那么缓存效果就会大打折扣。
数据访问模式不稳定： 如果数据访问模式变化频繁，热点数据分布不明确，Caffeine 难以有效学习和缓存热点数据。
缓存 Key 的设计不合理： 如果缓存 Key 的粒度过细，导致大量相似的 Key，或者 Key 的生成逻辑复杂，增加了缓存的查找成本，也会影响命中率。
缓存穿透： 如果大量请求访问不存在的数据，导致缓存中没有相应的 Key，每次请求都会穿透到数据库，造成缓存失效，命中率自然很低。
冷启动问题： 应用刚启动时，缓存是空的，需要一段时间的运行才能积累足够的热点数据，这段时间内命中率会比较低。

手动预热：解决冷启动和提升初始命中率

手动预热是一种在应用启动时，主动将一部分可能被频繁访问的数据加载到缓存中的技术。这可以有效解决冷启动问题，并提升缓存的初始命中率。

实现方式：

启动时加载： 在应用启动过程中，从数据库或其他数据源加载一部分热点数据到 Caffeine 缓存中。
后台线程加载： 使用后台线程定期或不定期地加载数据到缓存中。

代码示例：

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;

import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

public class CachePreloader {

    private final Cache<String, Object> cache;
    private final DataProvider dataProvider;
    private final ExecutorService executor;

    public CachePreloader(DataProvider dataProvider) {
        this.dataProvider = dataProvider;
        this.cache = Caffeine.newBuilder()
                .maximumSize(1000)
                .expireAfterWrite(10, TimeUnit.MINUTES)
                .build();
        this.executor = Executors.newFixedThreadPool(5); // 可以调整线程池大小
    }

    public void preloadCache() {
        // 模拟获取热点数据 Key 列表
        List<String> hotKeys = dataProvider.getHotKeys();

        for (String key : hotKeys) {
            executor.submit(() -> {
                try {
                    Object data = dataProvider.getData(key);
                    if (data != null) {
                        cache.put(key, data);
                        System.out.println("Preloaded key: " + key);
                    }
                } catch (Exception e) {
                    System.err.println("Error preloading key: " + key + ", error: " + e.getMessage());
                }
            });
        }

        executor.shutdown();
        try {
            executor.awaitTermination(60, TimeUnit.SECONDS); // 等待预热完成，可以调整超时时间
        } catch (InterruptedException e) {
            System.err.println("Preload interrupted: " + e.getMessage());
            Thread.currentThread().interrupt();
        }
    }

    public Object getFromCache(String key) {
        return cache.get(key, dataProvider::getData);
    }

    // 模拟数据提供者
    interface DataProvider {
        List<String> getHotKeys();
        Object getData(String key);
    }

    public static void main(String[] args) throws InterruptedException {
        // 模拟 DataProvider 实现
        DataProvider dataProvider = new DataProvider() {
            @Override
            public List<String> getHotKeys() {
                // 模拟返回热点 Key
                return List.of("key1", "key2", "key3");
            }

            @Override
            public Object getData(String key) {
                // 模拟从数据库获取数据
                try {
                    Thread.sleep(100); // 模拟数据库访问延迟
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    return null;
                }
                return "Data for " + key;
            }
        };

        CachePreloader preloader = new CachePreloader(dataProvider);
        System.out.println("Starting cache preload...");
        preloader.preloadCache();
        System.out.println("Cache preload complete.");

        // 模拟后续请求
        System.out.println("Getting data from cache...");
        System.out.println("Data for key1: " + preloader.getFromCache("key1"));
        System.out.println("Data for key4: " + preloader.getFromCache("key4")); // 未预热的 Key

        Thread.sleep(2000);
    }
}

代码解释：

CachePreloader 类负责缓存的预热。
DataProvider 接口定义了获取热点 Key 列表和获取数据的方法，需要根据实际情况进行实现。
preloadCache() 方法使用线程池并发地加载热点数据到 Caffeine 缓存中。
getFromCache() 方法从缓存中获取数据，如果缓存中不存在，则从 DataProvider 获取并加载到缓存中。
main() 方法演示了如何使用 CachePreloader 进行缓存预热和数据访问。

注意事项：

预热的数据量不宜过大，避免占用过多内存，影响应用启动速度。
预热的数据应该是真正的高频访问数据，否则会浪费资源。
预热过程应该异步进行，避免阻塞应用启动。
需要监控预热过程的性能，避免对数据库或其他数据源造成过大的压力。

权重缓存：根据访问频率调整缓存策略

Caffeine 默认的淘汰策略（如 LRU、LFU）是基于统一的标准来选择淘汰对象。但在实际应用中，不同数据的访问频率可能差异很大，简单地使用统一的策略可能无法达到最佳的缓存效果。权重缓存则允许我们根据数据的访问频率或其他因素，为不同的数据设置不同的权重，从而更精细地控制缓存的淘汰行为。

实现方式：

Caffeine 本身并没有直接提供权重设置的 API。但是，我们可以通过自定义淘汰策略来实现类似的效果。一种常见的做法是，维护一个额外的元数据结构，记录每个 Key 的访问频率或其他权重信息，并在 Caffeine 的 RemovalListener 中，根据这些权重信息来调整缓存的淘汰顺序。

代码示例：

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import com.github.benmanes.caffeine.cache.RemovalCause;
import com.github.benmanes.caffeine.cache.RemovalListener;

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.TimeUnit;

public class WeightedCache {

    private final Cache<String, Object> cache;
    private final Map<String, Integer> accessCounts; // 记录每个 Key 的访问次数
    private final int minAccessCountThreshold; // 最小访问次数阈值

    public WeightedCache(int maximumSize, int expireAfterWriteSeconds, int minAccessCountThreshold) {
        this.accessCounts = new ConcurrentHashMap<>();
        this.minAccessCountThreshold = minAccessCountThreshold;

        this.cache = Caffeine.newBuilder()
                .maximumSize(maximumSize)
                .expireAfterWrite(expireAfterWriteSeconds, TimeUnit.SECONDS)
                .removalListener(new CustomRemovalListener())
                .build();
    }

    public Object get(String key, DataProvider dataProvider) {
        // 每次访问增加访问次数
        accessCounts.compute(key, (k, v) -> (v == null) ? 1 : v + 1);
        return cache.get(key, dataProvider::getData);
    }

    public void put(String key, Object value) {
        cache.put(key, value);
    }

    // 自定义 RemovalListener，根据访问次数决定是否允许淘汰
    private class CustomRemovalListener implements RemovalListener<String, Object> {
        @Override
        public void onRemoval(String key, Object value, RemovalCause cause) {
            if (cause == RemovalCause.SIZE) {
                // 因为缓存容量达到上限而被淘汰
                Integer accessCount = accessCounts.get(key);
                if (accessCount != null && accessCount < minAccessCountThreshold) {
                    // 如果访问次数低于阈值，则重新加载到缓存中
                    cache.put(key, value); // 重新放入缓存，延迟淘汰
                    System.out.println("Key " + key + " re-added to cache due to low access count (" + accessCount + ")");
                } else {
                    System.out.println("Key " + key + " removed from cache due to size limit, access count: " + (accessCount == null ? 0 : accessCount));
                    accessCounts.remove(key); // 移除访问计数
                }
            } else {
                System.out.println("Key " + key + " removed from cache due to " + cause);
                accessCounts.remove(key); // 移除访问计数
            }
        }
    }

    // 模拟数据提供者
    interface DataProvider {
        Object getData(String key);
    }

    public static void main(String[] args) throws InterruptedException {
        // 模拟 DataProvider 实现
        DataProvider dataProvider = (key) -> {
            try {
                Thread.sleep(50); // 模拟数据库访问延迟
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                return null;
            }
            return "Data for " + key;
        };

        WeightedCache weightedCache = new WeightedCache(5, 60, 3); // 最大容量 5，过期时间 60 秒，最小访问次数阈值 3

        // 模拟访问
        weightedCache.get("key1", dataProvider); // 访问 1 次
        weightedCache.get("key2", dataProvider); // 访问 1 次
        weightedCache.get("key3", dataProvider); // 访问 1 次
        weightedCache.get("key4", dataProvider); // 访问 1 次
        weightedCache.get("key5", dataProvider); // 访问 1 次

        System.out.println("Initial load complete.");

        weightedCache.get("key1", dataProvider); // 访问 2 次
        weightedCache.get("key1", dataProvider); // 访问 3 次
        weightedCache.get("key2", dataProvider); // 访问 2 次

        System.out.println("Simulating more access...");

        weightedCache.get("key6", dataProvider); // 访问 1 次，触发淘汰

        System.out.println("Cache size after adding key6: " + weightedCache.cache.estimatedSize());

        Thread.sleep(1000); // 留出时间让 RemovalListener 执行

        System.out.println("Cache size after waiting: " + weightedCache.cache.estimatedSize());
    }
}

代码解释：

WeightedCache 类封装了 Caffeine 缓存和访问计数器。
accessCounts 使用 ConcurrentHashMap 记录每个 Key 的访问次数。
minAccessCountThreshold 定义了最小访问次数阈值，只有访问次数超过该阈值的 Key 才允许被淘汰。
CustomRemovalListener 是一个自定义的 RemovalListener，在缓存项被淘汰时，会检查其访问次数。如果访问次数低于阈值，则重新将该项放入缓存，延迟淘汰。
get() 方法在每次访问时增加对应 Key 的访问计数。
main() 方法演示了如何使用 WeightedCache，并模拟了访问过程，观察缓存的淘汰行为。

注意事项：

accessCounts 需要使用线程安全的 ConcurrentHashMap，以避免并发问题。
minAccessCountThreshold 的值需要根据实际情况进行调整，过高可能导致缓存容量利用率低，过低则可能无法有效保护高频访问数据。
这种实现方式会增加代码的复杂性，并可能引入额外的性能损耗，需要权衡收益和成本。
这种方式只是模拟了权重的效果，并不能完全实现真正的权重缓存。Caffeine 本身并没有提供直接设置权重的 API，因此我们只能通过自定义的淘汰策略来间接实现。

其他优化策略

除了手动预热和权重缓存，还有一些其他的策略可以帮助提升 Caffeine 缓存的命中率：

调整缓存容量： 根据应用的实际需求，合理调整缓存的 maximumSize。可以使用一些监控工具来观察缓存的命中率和淘汰率，从而找到最佳的缓存容量。
选择合适的淘汰策略： Caffeine 提供了多种淘汰策略，可以根据数据的访问模式选择最合适的策略。例如，如果数据访问模式符合 LFU，则可以使用 Caffeine.newBuilder().frequencySketch() 来启用 TinyLFU 策略。
优化缓存 Key 的设计： 尽量使用简洁、唯一的 Key，避免使用复杂的 Key 生成逻辑。如果 Key 的粒度过细，可以考虑合并多个 Key，或者使用组合 Key。
防止缓存穿透： 对于不存在的数据，可以在缓存中设置一个空值，避免每次请求都穿透到数据库。可以使用布隆过滤器来快速判断数据是否存在，减少对数据库的访问。
使用异步加载： 对于加载时间较长的数据，可以使用 Caffeine 的异步加载功能，避免阻塞请求线程。可以使用 CacheLoader.asyncReloading() 来实现异步加载。
监控和调优： 使用 Caffeine 提供的 stats() 方法来监控缓存的命中率、加载时间、淘汰次数等指标，并根据这些指标进行调优。

不同策略的对比

策略	优点	缺点	适用场景
手动预热	解决冷启动问题，提升初始命中率	需要提前知道热点数据，预热数据量不宜过大	应用启动时需要加载一部分数据，且热点数据相对固定
权重缓存	可以根据数据的访问频率或其他因素，更精细地控制缓存的淘汰行为	实现复杂，可能引入额外的性能损耗，只能模拟权重效果	不同数据的访问频率差异很大，需要更精细的缓存控制
调整缓存容量	简单易行，可以有效提升缓存命中率	需要根据实际情况进行调整，过大占用内存，过小效果不明显	适用于所有场景，是基本的优化手段
选择淘汰策略	Caffeine提供了多种淘汰策略，针对不同场景选择合适的策略可以大大提高缓存效率	需要对各种策略有一定的理解，选择不当反而会降低效率	适用于数据访问模式较为明确的场景，例如LFU适合访问频率高的场景，LRU适合最近访问的场景
优化 Key 设计	提升缓存查找效率，减少内存占用	需要仔细分析 Key 的结构，避免过度优化	适用于 Key 的设计不合理，导致查找效率低的场景
防止缓存穿透	避免大量请求穿透到数据库，保护数据库	增加了缓存的维护成本，需要及时更新空值	适用于存在大量不存在的数据请求的场景
异步加载	避免阻塞请求线程，提升响应速度	实现复杂，需要处理异步加载的错误	适用于加载时间较长的数据
监控和调优	可以及时发现缓存的问题，并进行优化	需要一定的技术能力和工具	适用于所有场景，是持续优化的关键

缓存优化是一个持续的过程

Caffeine 本地缓存的优化是一个持续的过程，需要根据应用的实际情况不断调整和改进。没有一劳永逸的解决方案，只有不断地学习和实践，才能找到最适合自己的优化策略。希望通过今天的分享，大家能够对 Caffeine 缓存的优化有更深入的理解，并能够应用到实际项目中，提升应用的性能和稳定性。

小结：优化缓存，提升性能

我们探讨了 Caffeine 缓存命中率低的原因，并介绍了手动预热和权重缓存等优化策略。缓存优化需要根据实际情况选择合适的策略，并持续监控和调整。

总结：没有总结，只有继续优化

希望大家通过实践不断优化缓存策略，提升应用的性能和稳定性，没有最好，只有更好。