4. 常见缓存中间件：Redis核心数据结构与过期策略、Memcached特点、本地缓存Caffeine
在集成测试中验证缓存数据一致性，首先需要理解不同缓存中间件的底层机制。Redis、Memcached 和 Caffeine 分别代表了远程缓存、纯内存缓存和本地缓存三种典型架构，它们在数据结构、过期策略和一致性保障上存在本质差异。
4.1 Redis 核心数据结构与过期策略
Redis 是当前最主流的远程缓存中间件，支持丰富的数据结构，其过期策略直接影响缓存一致性的验证设计。
4.1.1 核心数据结构
| 数据结构 | 底层编码 | 典型应用场景 | 一致性关注点 |
|---|---|---|---|
| String | int / embstr / raw | 计数器、Session、对象序列化 | 原子操作（INCR/DECR）与事务隔离 |
| Hash | ziplist / hashtable | 对象字段缓存、用户属性 | 字段级更新与全量覆盖的差异 |
| List | quicklist | 消息队列、最新列表 | LPUSH/RPOP 与数据库顺序一致性 |
| Set | intset / hashtable | 标签系统、去重集合 | SADD/SREM 与数据库集合同步 |
| Sorted Set | ziplist / skiplist | 排行榜、延时队列 | Score 更新与数据库排序字段一致 |
测试提示： 在验证缓存一致性时，String 类型最容易通过 SET/GET 对比验证，但 Hash 和 Sorted Set 的局部更新往往隐藏着字段级不一致的风险，需要设计针对性的原子性校验用例。
4.1.2 过期策略与淘汰机制
Redis 的过期策略分为 被动过期 和 主动过期 两种，淘汰策略则决定了内存满载时的行为。
- 被动过期： 当客户端访问一个 key 时，检查其 TTL，若已过期则立即删除并返回 nil。
- 主动过期： Redis 每秒执行 10 次定时任务，随机抽取 20 个设置了过期时间的 key，删除其中已过期的 key；若过期比例超过 25%，则重复该过程。
- 惰性删除： 结合被动与主动，确保过期 key 不会长期占用内存。
淘汰策略（maxmemory-policy）包括：
| 策略 | 行为 | 一致性影响 |
|---|---|---|
| noeviction | 不淘汰，写入直接报错 | 缓存写入失败，数据库可能过载 |
| allkeys-lru | 对所有 key 执行 LRU 淘汰 | 热数据可能被意外淘汰，导致缓存击穿 |
| volatile-lru | 仅对设置了 TTL 的 key 执行 LRU | 未设置 TTL 的 key 永久驻留，可能引发陈旧数据 |
| allkeys-random | 随机淘汰任意 key | 不可预测性高，一致性验证难度大 |
| volatile-ttl | 淘汰 TTL 最小的 key | 即将过期的 key 被提前删除，与数据库同步窗口缩短 |
验证要点： 在集成测试中，必须验证 Redis 过期后缓存是否立即失效，以及淘汰策略是否在内存压力下正确触发。建议构造内存满载场景，观察缓存与数据库之间的数据一致性是否被破坏。
4.2 Memcached 特点
Memcached 是经典的纯内存缓存系统，设计哲学是“简单、快速、分布式”。与 Redis 相比，它在数据结构支持和持久化方面做了大量减法，但在某些场景下性能更优。
4.2.1 核心特点
- 纯内存缓存： 不支持持久化，重启后数据全部丢失，一致性验证需关注缓存预热与冷启动。
- 简单数据结构： 仅支持 key-value 字符串存储，value 最大 1MB，不支持列表、集合等复杂结构。
- 分布式架构： 客户端通过一致性哈希算法分片，服务端无节点通信，无主从复制。
- LRU 淘汰： 内存满时自动淘汰最近最少使用的 key，不支持自定义淘汰策略。
- 过期时间： 支持 TTL 设置，最大 30 天，过期后被动删除。
- 无事务支持： 不提供事务、Lua 脚本或回滚机制，并发更新需应用层保证原子性。
4.2.2 与 Redis 的关键对比
| 维度 | Memcached | Redis |
|---|---|---|
| 数据结构 | 仅 String | String / Hash / List / Set / Sorted Set 等 |
| 持久化 | 不支持 | RDB / AOF 持久化 |
| 过期精度 | 秒级 | 毫秒级 |
| 淘汰策略 | 仅 LRU | 8 种策略可选 |
| 原子操作 | incr/decr | incr/decr + Lua + 事务 |
| 内存分配 | Slab Allocator（固定块） | jemalloc（动态分配） |
| 一致性验证难度 | 较低（数据结构简单） | 较高（复杂结构 + 持久化状态） |
测试陷阱： Memcached 的 Slab Allocator 可能导致内存碎片，当存储的 value 大小分布不均时，部分 slab 类别的内存可能耗尽而其他类别仍有空闲。在一致性测试中，需要关注内存分配不均导致的提前淘汰行为。
4.3 本地缓存 Caffeine
Caffeine 是 Java 生态中性能最高的本地缓存库，基于 Google Guava Cache 改进而来，被 Spring Cache 默认集成。在集成测试中，本地缓存与远程缓存共存时，一致性验证的复杂度显著增加。
4.3.1 核心特性
- 基于 Window TinyLFU 淘汰算法： 结合频率与时效性，比传统 LRU 命中率更高。
- 异步加载与刷新： 支持 CacheLoader 自动加载，刷新时返回旧值，避免缓存击穿。
- 软引用/弱引用： 支持 key 和 value 的引用类型，配合 GC 自动回收。
- 统计与监听： 内置命中率、加载时间等指标，便于测试验证。
- 过期策略： 支持基于大小、时间（写入后/访问后）、引用的多种过期组合。
4.3.2 过期策略对比
| 策略 | 触发条件 | 一致性验证场景 |
|---|---|---|
| expireAfterWrite | 写入后固定时长 | 验证写入后缓存与数据库的同步窗口 |
| expireAfterAccess | 最后一次访问后固定时长 | 验证热数据持续访问时是否保持一致性 |
| maximumSize | 缓存条目数超过阈值 | 验证淘汰后是否触发数据库回查 |
| weakKeys / softValues | GC 回收 | 验证 GC 后缓存自动失效的正确性 |
4.3.3 多级缓存一致性挑战
当应用同时使用 Caffeine（L1）和 Redis（L2）时，一致性验证需要覆盖以下场景：
- L1 命中，L2 未命中： 验证 L1 数据是否与数据库一致，是否存在 L2 已更新但 L1 未失效的情况。
- L1 未命中，L2 命中： 验证 L2 数据加载到 L1 后，是否与数据库一致。
- L1 与 L2 同时过期： 验证缓存雪崩防护机制（如互斥锁、布隆过滤器）是否生效。
- L1 淘汰，L2 未淘汰： 验证 L2 是否仍返回陈旧数据，以及应用层如何处理。
测试策略： 建议在集成测试中构造“L1 淘汰 + L2 陈旧 + 数据库更新”的三角不一致场景，验证应用层最终是否能读取到最新数据。这是多级缓存一致性验证的核心难点。
4.4 三种缓存中间件的一致性验证要点总结
| 中间件 | 核心验证点 | 典型测试工具 | 常见不一致场景 |
|---|---|---|---|
| Redis | 过期删除、淘汰策略、事务原子性、持久化恢复 | redis-cli、RedisInsight、Jedis 测试客户端 | 过期 key 未及时删除、淘汰导致热数据丢失、AOF 重写期间数据不一致 |
| Memcached | LRU 淘汰、Slab 内存分配、无持久化重启 | telnet、memcached-tool、Java Memcached 客户端 | Slab 内存耗尽导致提前淘汰、重启后缓存雪崩 |
| Caffeine | Window TinyLFU 淘汰、异步刷新、引用回收 | JUnit + Caffeine 统计 API、Spring Cache 测试 | 软引用被 GC 提前回收、异步刷新返回旧值 |
最佳实践： 在集成测试中，建议为每种缓存中间件编写独立的“一致性契约测试”，覆盖过期、淘汰、并发更新和重启恢复四个维度。然后再编写多级缓存组合测试，验证 L1-L2-DB 三层之间的最终一致性。