4. 缓存基础：Redis数据结构、Jedis与Lettuce客户端、Spring Cache抽象

在压测与验证数据库缓存异步任务编排之前，必须扎实掌握缓存基础设施。Redis 作为高性能键值存储，其数据结构选型、客户端连接策略以及 Spring 生态的缓存抽象层，直接决定了压测场景的设计边界与性能基线。本章从这三个维度展开，为后续的压测脚本编写和结果分析奠定基础。

4.1 Redis 核心数据结构与压测选型

Redis 提供了多种数据结构，不同结构在读写复杂度、内存占用和并发特性上差异显著。压测时需根据业务场景选择最匹配的数据类型，避免因结构误用导致性能瓶颈。

4.2 Jedis 与 Lettuce 客户端对比

Java 生态中最主流的两个 Redis 客户端是 Jedis 和 Lettuce。它们在连接管理、线程模型和异步支持上存在本质差异，直接影响压测时的并发上限和资源消耗。

4.3 Spring Cache 抽象与集成

Spring Cache 提供了声明式缓存注解，屏蔽了底层客户端差异。在压测验证中，理解其代理机制和缓存穿透/击穿/雪崩的防护策略至关重要。

4.3.1 核心注解与配置

4.3.2 缓存穿透防护配置

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory factory) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofMinutes(30))           // 统一过期时间
            .disableCachingNullValues()                  // 禁止缓存 null，防止穿透
            .computePrefixWith(cacheName -> "cache:" + cacheName + ":");

        return RedisCacheManager.builder(factory)
            .cacheDefaults(config)
            .withInitialCacheConfigurations(customConfigs())
            .build();
    }

    private Map<String, RedisCacheConfiguration> customConfigs() {
        Map<String, RedisCacheConfiguration> configs = new HashMap<>();
        // 任务状态缓存使用更短的 TTL，避免脏数据
        configs.put("taskStatus", RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofSeconds(10)));
        return configs;
    }
}

4.4 数据结构与客户端选型决策流程

以下 SVG 图展示了从业务场景到 Redis 数据结构、客户端及 Spring Cache 配置的完整决策链路，帮助压测工程师快速定位技术选型。

4.5 压测前的配置清单

在进入压测环节前，请逐项确认以下配置项，避免因基础设置不当导致压测结果失真。

1. Redis 最大内存策略：确认 maxmemory-policy 为 allkeys-lru 或 volatile-lru，防止内存写满导致写入失败。
2. 客户端连接池参数：Lettuce 的 maxActive 建议设置为压测并发数的 1.5 倍，maxWait 不超过 200ms。
3. 序列化方式：统一使用 JSON 序列化，并在压测前验证序列化后的 Value 大小与反序列化耗时。
4. 缓存 TTL 分布：避免大量缓存同时过期，在 TTL 基础上增加 ±20% 的随机偏移。
5. Spring Cache 代理方式：确认使用 @EnableCaching 且代理目标类（proxyTargetClass = true），避免内部方法调用不走缓存代理。