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 findStudentsByIds(Set ids) {
System.out.println("从数据库查询学生信息，IDs: " + ids);
return studentRepository.findByIdIn(ids);
}
} 在这种情况下，如果 findStudentsByIds 方法的缓存键（由 ids 参数生成）在缓存中，那么即使 ids 集合中的部分学生数据已过期或更新，整个方法也不会被执行，导致返回旧数据。反之，如果缓存键不存在，则整个 ids 集合都会被用于数据库查询，无法利用缓存中已有的部分数据。
2.2 不匹配的缓存键设计
默认情况下，Spring Cache Abstraction 使用方法的所有参数来生成缓存键。对于 findStudentsByIds(Set
缓存键 (Set) | 缓存值 (List ) ----------------------|----------------------- {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 手动管理缓存与数据库交互
核心思路是：
- 首先尝试从缓存中获取所有请求ID对应的数据。
- 识别出在缓存中未找到的ID（即缺失的ID）。
- 只针对这些缺失的ID发起数据库查询。
- 将数据库查询结果存入缓存。
- 合并缓存和数据库查询的结果，返回完整的数据集。
以下是实现此逻辑的代码示例：
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 findStudentsWithPartialCache(Set studentIds) {
List result = new ArrayList<>();
Set 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 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
import com.hazelcast.map.IMap;
// ... 其他导入
@Service
public class OptimizedStudentService {
// ... 构造函数不变
public List findStudentsWithPartialCacheOptimized(Set studentIds) {
List result = new ArrayList<>();
Set idsToQueryDb = new HashSet<>(studentIds);
// 尝试获取原生缓存对象
Object nativeCache = studentsCache.getNativeCache();
if (nativeCache instanceof IMap) { // 如果是Hazelcast IMap
IMap hazelcastMap = (IMap) nativeCache;
// 批量从Hazelcast缓存获取数据
Map cachedStudentsMap = hazelcastMap.getAll(studentIds);
for (Map.Entry 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 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）并不能直接满足。
为了实现这种优化策略，我们需要：
- 放弃 @Cacheable 的自动行为： 转而直接通过 CacheManager 获取 Cache 实例，并手动进行缓存的存取管理。
- 手动实现缓存命中判断与数据库查询逻辑： 核心在于识别出缓存中已有的数据和需要从数据库获取的缺失数据。
- 考虑性能优化： 在数据量大、性能要求高的场景下，应尝试利用 Cache.getNativeCache() 访问底层缓存提供商的批量操作API，以减少网络往返和提高效率，但需权衡由此带来的耦合性。
最终选择哪种实现方式，应根据应用程序的具体性能要求、缓存提供商的选择以及对代码耦合度的容忍程度来决定。在许多情况下，手动管理缓存的复杂性是值得的，因为它能带来显著的性能提升和资源节约。
