SpringBoot缓存优化：批量查询协同解析

在Spring Boot应用中，针对批量数据查询的缓存优化至关重要。本文深入解析了Spring Cache Abstraction在处理批量查询时的局限性，特别是其默认的“全有或全无”缓存策略，无法有效利用部分缓存命中。为了解决这一问题，文章提出了一种手动管理缓存与数据库交互的协同机制。该方案的核心在于优先从缓存中获取已存在的数据，然后仅针对缓存未命中的数据发起数据库查询，并将查询结果更新回缓存。通过这种“部分缓存，部分数据库”的策略，显著提升数据检索效率，降低数据库负载，实现更精细化的缓存控制。本文还探讨了利用底层缓存提供商原生API进行性能优化的方法，为开发者提供更高效的缓存解决方案。

1. 批量数据查询中的缓存需求场景

在许多业务场景中，我们经常需要根据一组ID查询批量数据。例如，查询一批学生信息：

public class Student {
    private int id;
    private String name;

    // Getters and Setters
    public int getId() { return id; }
    public void setId(int id) { this.id = id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }

    @Override
    public String toString() {
        return "Student{" + "id=" + id + ", name='" + name + '\'' + '}';
    }
}

对应的数据库查询通常是：

SELECT name FROM Student WHERE id IN (:ids);

我们期望的理想缓存行为是： 当请求一组学生ID（例如 [2, 3, 4, 5, 6]）时，系统首先检查缓存。如果 [2, 4, 6] 的数据已在缓存中，则直接从缓存获取；对于 [3, 5] 这些缓存中不存在的ID，则只针对它们发起数据库查询。查询到 [3, 5] 的数据后，将其存入缓存，并将所有数据合并返回。这种“部分缓存命中，部分数据库查询”的策略可以显著提高数据检索效率，减少数据库负载。

2. Spring Cache Abstraction的默认行为及其局限性

Spring Framework 提供的缓存抽象（Spring Cache Abstraction）通过 @Cacheable 等注解，简化了缓存逻辑的集成。然而，对于上述批量查询的特定需求，其默认行为存在一些局限性。

2.1 “全有或全无”的缓存策略

Spring 的 @Cacheable 注解通常应用于方法级别，其工作机制类似于 Map.computeIfAbsent(KEY, Function)。这意味着：

• 如果缓存键存在： 整个被注解的方法将不会被执行，直接返回缓存中的值。
• 如果缓存键不存在： 方法会被执行，其返回值会被存入缓存，然后返回。

例如，一个使用 @Cacheable 的服务方法可能如下：

import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
import java.util.List;
import java.util.Set;

@Service
public class StudentService {

    // 假设这是与数据库交互的Repository
    private StudentRepository studentRepository;

    public StudentService(StudentRepository studentRepository) {
        this.studentRepository = studentRepository;
    }

    @Cacheable(value = "students")
    public List<Student> findStudentsByIds(Set<Integer> ids) {
        System.out.println("从数据库查询学生信息，IDs: " + ids);
        return studentRepository.findByIdIn(ids);
    }
}

在这种情况下，如果 findStudentsByIds 方法的缓存键（由 ids 参数生成）在缓存中，那么即使 ids 集合中的部分学生数据已过期或更新，整个方法也不会被执行，导致返回旧数据。反之，如果缓存键不存在，则整个 ids 集合都会被用于数据库查询，无法利用缓存中已有的部分数据。

2.2 不匹配的缓存键设计

默认情况下，Spring Cache Abstraction 使用方法的所有参数来生成缓存键。对于 findStudentsByIds(Set ids) 方法，缓存键将是整个 Set 对象，而缓存值是 List。

缓存键 (Set<Integer>)  |  缓存值 (List<Student>)
----------------------|-----------------------
{1, 2, 3}             |  [Student(id=1), Student(id=2), Student(id=3)]
{4, 5}                |  [Student(id=4), Student(id=5)]

这与我们期望的“按单个学生ID缓存”的粒度不符。我们通常希望每个 Student 对象都以其 id 作为键单独缓存：

缓存键 (Integer) | 缓存值 (Student)
-----------------|-----------------
1                | Student(id=1, name='Jon Doe')
2                | Student(id=2, name='Jane Doe')
3                | Student(id=3, name='Pie Doe')

虽然可以通过自定义键生成策略来改变缓存键，但这并不能直接解决“部分缓存命中”的问题，因为 @Cacheable 仍然是针对整个方法调用进行缓存判断。

2.3 单键访问的性能限制

Spring 的 org.springframework.cache.Cache 接口提供了 get(Object key) 方法来获取单个缓存项。如果我们需要手动检查一组ID是否在缓存中，就需要对每个ID调用一次 get() 方法。当请求的ID数量很大时（例如1000个ID），频繁的单键访问可能会带来显著的性能开销，尤其是在分布式缓存环境中。

3. 实现“部分缓存，部分数据库”策略的方案

鉴于 Spring Cache Abstraction 的默认局限性，我们需要通过手动管理缓存和数据库交互来实现所需的策略。以下是一个详细的实现方案：

3.1 手动管理缓存与数据库交互

核心思路是：

1. 首先尝试从缓存中获取所有请求ID对应的数据。
2. 识别出在缓存中未找到的ID（即缺失的ID）。
3. 只针对这些缺失的ID发起数据库查询。
4. 将数据库查询结果存入缓存。
5. 合并缓存和数据库查询的结果，返回完整的数据集。

以下是实现此逻辑的代码示例：

import org.springframework.cache.Cache;
import org.springframework.cache.CacheManager;
import org.springframework.stereotype.Service;
import java.util.*;
import java.util.stream.Collectors;

@Service
public class OptimizedStudentService {

    private final StudentRepository studentRepository;
    private final Cache studentsCache; // 直接引用Cache实例

    public OptimizedStudentService(StudentRepository studentRepository, CacheManager cacheManager) {
        this.studentRepository = studentRepository;
        // 获取名为 "students" 的缓存实例
        this.studentsCache = cacheManager.getCache("students");
        if (this.studentsCache == null) {
            throw new IllegalStateException("Cache 'students' not found. Please configure it.");
        }
    }

    /**
     * 根据一组ID查询学生信息，优先从缓存获取，缺失部分从数据库查询。
     *
     * @param studentIds 需要查询的学生ID集合
     * @return 匹配的学生列表
     */
    public List<Student> findStudentsWithPartialCache(Set<Integer> studentIds) {
        List<Student> result = new ArrayList<>();
        Set<Integer> idsToQueryDb = new HashSet<>(studentIds); // 初始所有ID都需要查询

        // 步骤 1: 尝试从缓存中获取数据
        // 注意：这里是单键循环访问缓存，可能存在性能瓶颈，见后续优化章节
        for (Integer id : studentIds) {
            Cache.ValueWrapper valueWrapper = studentsCache.get(id);
            if (valueWrapper != null) {
                Object cachedObject = valueWrapper.get();
                if (cachedObject instanceof Student) {
                    Student student = (Student) cachedObject;
                    result.add(student);
                    idsToQueryDb.remove(id); // 从待查询数据库的ID集合中移除已缓存的ID
                }
            }
        }

        // 步骤 2: 识别出需要从数据库查询的缺失ID
        // idsToQueryDb 现在包含了所有缓存中未找到的ID

        // 步骤 3: 针对缺失的ID发起数据库查询
        if (!idsToQueryDb.isEmpty()) {
            System.out.println("从数据库查询缺失学生信息，IDs: " + idsToQueryDb);
            List<Student> dbStudents = studentRepository.findByIdIn(idsToQueryDb);

            // 步骤 4: 将数据库查询结果存入缓存
            for (Student student : dbStudents) {
                studentsCache.put(student.getId(), student);
                result.add(student); // 将新查询到的数据也添加到结果集
            }
        }

        // 步骤 5: 合并并返回所有数据
        // 确保返回的列表是去重且包含所有请求ID的数据（如果存在）
        // 实际场景可能需要根据业务逻辑对结果进行排序或进一步处理
        return result.stream()
                     .distinct() // 去重，以防万一
                     .collect(Collectors.toList());
    }
}

注意事项：

• 此方案直接操作 Cache 接口，绕过了 @Cacheable 的AOP机制。
• 需要确保 CacheManager 已正确配置，并且名为 "students" 的缓存已定义。
• studentRepository.findByIdIn(idsToQueryDb) 模拟了从数据库批量查询的操作。

3.2 性能优化考量：多键访问与原生缓存接口

上述手动方案中，通过循环调用 studentsCache.get(id) 来检查每个ID的缓存状态，这在ID数量巨大时可能效率低下。理想情况下，缓存提供商通常支持批量获取（multi-get）操作。

Spring 的 Cache 接口本身没有提供批量获取的方法，但它提供了一个 getNativeCache() 方法，允许我们访问底层缓存提供商（如 Ehcache, Caffeine, Hazelcast, Redis 等）的原生缓存对象。如果底层缓存支持批量获取，我们可以利用 getNativeCache() 进行优化。

例如，如果使用 Hazelcast 作为缓存提供商，其 IMap 接口提供了 getAll(Set keys) 方法：

import com.hazelcast.map.IMap;
// ... 其他导入

@Service
public class OptimizedStudentService {
    // ... 构造函数不变

    public List<Student> findStudentsWithPartialCacheOptimized(Set<Integer> studentIds) {
        List<Student> result = new ArrayList<>();
        Set<Integer> idsToQueryDb = new HashSet<>(studentIds);

        // 尝试获取原生缓存对象
        Object nativeCache = studentsCache.getNativeCache();

        if (nativeCache instanceof IMap) { // 如果是Hazelcast IMap
            IMap<Integer, Student> hazelcastMap = (IMap<Integer, Student>) nativeCache;
            // 批量从Hazelcast缓存获取数据
            Map<Integer, Student> cachedStudentsMap = hazelcastMap.getAll(studentIds);

            for (Map.Entry<Integer, Student> entry : cachedStudentsMap.entrySet()) {
                result.add(entry.getValue());
                idsToQueryDb.remove(entry.getKey()); // 移除已缓存的ID
            }
        } else {
            // 如果不是IMap，或者不确定原生缓存类型，退回到单键循环访问
            for (Integer id : studentIds) {
                Cache.ValueWrapper valueWrapper = studentsCache.get(id);
                if (valueWrapper != null && valueWrapper.get() instanceof Student) {
                    Student student = (Student) valueWrapper.get();
                    result.add(student);
                    idsToQueryDb.remove(id);
                }
            }
        }

        // ... 后续数据库查询和缓存更新逻辑与之前相同
        if (!idsToQueryDb.isEmpty()) {
            System.out.println("从数据库查询缺失学生信息 (优化版)，IDs: " + idsToQueryDb);
            List<Student> dbStudents = studentRepository.findByIdIn(idsToQueryDb);
            for (Student student : dbStudents) {
                studentsCache.put(student.getId(), student);
                result.add(student);
            }
        }

        return result.stream().distinct().collect(Collectors.toList());
    }
}

使用 getNativeCache() 的权衡：

• 优点： 能够利用底层缓存提供商的高级特性，如批量操作，从而提升性能。
• 缺点： 引入了对特定缓存提供商API的依赖。如果未来更换缓存提供商，可能需要修改这部分代码。在追求高性能的场景下，这种耦合可能是可以接受的。

4. 总结与建议

Spring Cache Abstraction 旨在提供一个通用的缓存接口，以简化常见缓存模式的实现。然而，对于“批量查询中部分缓存命中，部分数据库查询”这种高级且精细的控制需求，其默认的声明式缓存机制（如 @Cacheable）并不能直接满足。

为了实现这种优化策略，我们需要：

1. 放弃 @Cacheable 的自动行为： 转而直接通过 CacheManager 获取 Cache 实例，并手动进行缓存的存取管理。
2. 手动实现缓存命中判断与数据库查询逻辑： 核心在于识别出缓存中已有的数据和需要从数据库获取的缺失数据。
3. 考虑性能优化： 在数据量大、性能要求高的场景下，应尝试利用 Cache.getNativeCache() 访问底层缓存提供商的批量操作API，以减少网络往返和提高效率，但需权衡由此带来的耦合性。

最终选择哪种实现方式，应根据应用程序的具体性能要求、缓存提供商的选择以及对代码耦合度的容忍程度来决定。在许多情况下，手动管理缓存的复杂性是值得的，因为它能带来显著的性能提升和资源节约。

今天关于《SpringBoot缓存优化：批量查询协同解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！