4、常见缓存中间件TTL配置：Redis TTL设置、Memcached过期配置、本地缓存Caffeine配置

在Testing环境下，缓存过期时间（TTL）的配置直接影响测试结果的准确性与回归冒烟的执行效率。不同缓存中间件在TTL语义、设置方式、过期策略上存在显著差异。本章聚焦Redis、Memcached、Caffeine三种主流缓存，从配置命令、过期策略、测试场景三个维度进行对比与实操说明。

4.1 Redis TTL设置

Redis支持精确到毫秒的过期时间控制，过期键采用惰性删除+定期删除混合策略。Testing环境下建议显式设置TTL，避免因内存淘汰导致缓存雪崩。

4.1.1 常用TTL命令

命令	语法	单位	说明
EXPIRE	EXPIRE key seconds	秒	设置key的存活秒数
PEXPIRE	PEXPIRE key milliseconds	毫秒	毫秒级精度设置
EXPIREAT	EXPIREAT key unix-time-seconds	秒	指定绝对时间戳过期
SETEX	SETEX key seconds value	秒	设置值的同时指定TTL
TTL	TTL key	秒	查询剩余存活时间

4.1.2 过期策略对测试的影响

• 惰性删除：key过期后不立即删除，仅在访问时检查并清理。测试中若依赖过期后key立即消失，需主动调用 UNLINK 或等待定期删除周期。
• 定期删除：Redis每100ms随机抽查部分key，删除已过期的key。Testing环境下若TTL设置过短（如1秒），可能因删除延迟导致断言失败。
• 内存淘汰策略：当内存达到 maxmemory 限制时，Redis根据 maxmemory-policy 淘汰key。测试中建议设置为 allkeys-lru 或 volatile-ttl，避免非预期淘汰。

# 设置key过期时间为60秒
SET test:cache:001 "value_001" EX 60

# 查询剩余TTL
TTL test:cache:001

# 取消过期时间
PERSIST test:cache:001

4.2 Memcached过期配置

Memcached的过期时间以秒为单位，最大支持30天（2592000秒）。过期时间超过30天时，Memcached会将其视为绝对时间戳。Memcached采用惰性过期机制，仅在get时检查并删除过期item。

4.2.1 过期时间设置方式

方式	示例	说明
相对时间（秒）	set key 0 3600 value	3600秒后过期
绝对时间戳	set key 0 1893456000 value	Unix时间戳过期
不过期	set key 0 0 value	TTL=0表示永不过期

4.2.2 过期行为与测试策略

• 惰性过期：过期item不会立即释放内存，Memcached在get时发现过期则删除并返回空。测试中若验证过期后key不存在，需主动执行get操作触发删除。
• LRU淘汰：当内存不足时，Memcached优先淘汰最近最少使用的item，即使未过期。Testing环境下建议设置足够大的 -m 参数，避免LRU干扰测试结果。
• 过期时间上限：超过30天的TTL会被解释为绝对时间戳。测试中若设置超大TTL，需确认时间戳转换是否正确。

# 设置item过期时间为120秒
set test:mem:key 0 120 "memcached_value"

# 获取item（触发惰性过期检查）
get test:mem:key

# 设置永不过期
set test:mem:perm 0 0 "permanent_value"

4.3 本地缓存Caffeine配置

Caffeine是Java生态中高性能的本地缓存库，支持基于时间和大小的过期策略。Testing环境下，Caffeine的TTL配置通常通过 Caffeine.newBuilder() 链式API完成。

4.3.1 过期策略类型

策略	API方法	说明
写入后过期	expireAfterWrite(Duration)	从写入时间开始计算TTL
访问后过期	expireAfterAccess(Duration)	从最后一次访问开始计算TTL
自定义过期	expireAfter(Expiry)	实现Expiry接口，动态计算TTL
最大容量	maximumSize(long)	基于条目数量淘汰

4.3.2 Testing环境配置示例

import com.github.benmanes.caffeine.cache.Caffeine;
import java.time.Duration;

// 写入后5秒过期，最大容量1000
Cache<String, String> testCache = Caffeine.newBuilder()
    .expireAfterWrite(Duration.ofSeconds(5))
    .maximumSize(1000)
    .recordStats()  // 开启统计，便于测试断言
    .build();

// 写入缓存
testCache.put("test:key", "caffeine_value");

// 读取缓存
String value = testCache.getIfPresent("test:key");

// 验证过期：等待6秒后读取应为null
Thread.sleep(6000);
assertNull(testCache.getIfPresent("test:key"));

4.4 三种缓存TTL配置对比

维度	Redis	Memcached	Caffeine
TTL精度	毫秒	秒（1秒以上）	纳秒（Duration）
过期策略	惰性+定期删除	惰性过期	异步定期清理
最大TTL	无限制（但受内存限制）	30天（超过视为时间戳）	无限制
原子设置	SETEX / SET EX	set命令直接指定	put时自动应用策略
测试友好性	高（命令丰富）	中（惰性需主动触发）	高（可强制清理）
适用场景	分布式缓存、精确过期	简单键值缓存、高吞吐	本地缓存、低延迟

4.5 Testing环境TTL配置最佳实践

1. 统一TTL基准：在测试配置文件中定义全局TTL常量，避免硬编码。回归冒烟场景建议TTL=5~10秒，兼顾等待时间与测试效率。
2. 时间敏感测试使用虚拟时钟：对于Caffeine等本地缓存，使用 TestClock 或 Mockito 模拟时间推进，避免sleep等待。
3. 清理残留数据：每个测试用例结束后，主动删除或清空测试缓存key，防止TTL未到期导致用例间干扰。
4. 监控过期命中率：在测试中开启缓存统计（如Caffeine的 recordStats()），断言过期命中率是否符合预期。
5. 避免短TTL竞争：TTL小于1秒时，优先使用Redis（毫秒级）或Caffeine（纳秒级），避免Memcached的秒级精度限制。