Redis 核心概念回顾：数据结构、过期策略、持久化机制与主从复制
在契约测试项目中，Redis 常被用作缓存层、分布式锁与计数器存储。理解其核心数据结构、过期策略、持久化机制及主从复制原理，是设计可靠错误码断言与数据同步方案的基础。本节将系统梳理这些关键概念，为后续的契约测试部署提供理论支撑。
1. 核心数据结构与适用场景
Redis 提供了多种数据结构，每种结构对应不同的业务模型。在契约测试中，我们常使用 String 存储序列化的契约文件，Hash 存储契约元数据，List 实现消息队列，Set 进行去重校验。
| 数据结构 | 底层实现 | 典型命令 | 契约测试场景 |
|---|---|---|---|
| String | SDS（动态字符串） | SET / GET / INCR | 存储契约 JSON 内容、计数器（错误码统计） |
| Hash | ziplist / hashtable | HSET / HGET / HGETALL | 存储契约元数据（版本、消费者、提供者） |
| List | quicklist | LPUSH / RPOP / BRPOP | 契约变更事件队列、异步同步管道 |
| Set | intset / hashtable | SADD / SMEMBERS / SISMEMBER | 已校验错误码集合、去重断言 |
| Sorted Set | skiplist + hashtable | ZADD / ZRANGEBYSCORE | 按时间戳排序的契约版本记录 |
实践建议：在契约测试中，优先使用 Hash 存储契约的多个属性字段，避免将整个 JSON 塞入 String 导致频繁序列化/反序列化。对于需要排序的版本历史，使用 Sorted Set 以时间戳作为 score。
2. 过期策略与内存淘汰
Redis 的过期策略直接影响缓存数据的生命周期。契约测试中，临时契约或错误码缓存应设置合理的 TTL，避免脏数据长期驻留。
- 定时删除：为每个 key 设置定时器，到期立即删除。内存友好，但 CPU 开销大。
- 惰性删除：访问 key 时检查是否过期，过期则删除。节省 CPU，但过期 key 可能长期占用内存。
- 定期删除：每隔 100ms 随机抽取一批 key 检查并删除过期 key。是前两者的折中方案。
当内存达到 maxmemory 限制时，Redis 触发淘汰策略：
| 淘汰策略 | 行为描述 | 适用场景 |
|---|---|---|
| noeviction | 不淘汰，写入直接返回错误 | 契约元数据存储，禁止丢失 |
| allkeys-lru | 从所有 key 中淘汰最近最少使用的 | 缓存层，契约文件可重新生成 |
| volatile-ttl | 从设置了 TTL 的 key 中淘汰即将过期的 | 临时错误码断言缓存 |
| allkeys-random | 随机淘汰任意 key | 测试环境，不关心数据一致性 |
注意：在契约测试的生产级部署中，建议将
maxmemory-policy 设置为 volatile-ttl 或 allkeys-lru，并配合合理的 TTL 设计，避免因内存淘汰导致关键契约数据被意外删除。
3. 持久化机制：RDB 与 AOF
Redis 提供两种持久化方式，用于数据恢复与灾难备份。契约测试项目中，持久化策略决定了错误码断言数据的可靠性。
3.1 RDB（快照持久化）
- 原理：在指定时间间隔内，将内存中的数据集快照写入磁盘的 dump.rdb 文件。
- 触发方式：手动
SAVE（阻塞）、BGSAVE（后台 fork 子进程）、自动配置save 900 1。 - 优点：文件紧凑，恢复速度快，适合全量备份。
- 缺点：可能丢失最后一次快照后的数据，fork 子进程时可能影响性能。
3.2 AOF（追加文件持久化）
- 原理：将每次写命令追加到 AOF 文件末尾，恢复时重放命令。
- 刷盘策略：
always（每次写入 fsync）、everysec（每秒 fsync）、no（由 OS 决定）。 - 优点：数据安全性高，最多丢失 1 秒数据；文件可读，便于修复。
- 缺点：文件体积大，恢复速度慢于 RDB。
契约测试推荐组合：同时开启 RDB 和 AOF。RDB 用于快速恢复基础契约数据，AOF 用于保证增量写入（如错误码断言结果）不丢失。设置
appendfsync everysec 平衡性能与安全。
4. 主从复制原理
主从复制是 Redis 高可用架构的基石。在契约测试项目中，主从复制用于实现读写分离与数据冗余，确保错误码断言服务在单点故障时仍可正常读取缓存数据。
4.1 复制流程
- 连接建立：从节点向主节点发送
PSYNC命令，携带 replication ID 和 offset。 - 全量复制：主节点执行
BGSAVE生成 RDB 快照，发送给从节点；同时将新写入命令缓存到 replication buffer。 - 增量复制：从节点加载完 RDB 后，主节点将 buffer 中的增量命令发送给从节点。
- 命令传播：后续主节点每次执行写命令，都会实时推送给所有从节点。
4.2 核心配置参数
| 参数 | 说明 | 契约测试建议值 |
|---|---|---|
replicaof |
指定主节点 IP 和端口 | replicaof 192.168.1.10 6379 |
repl-backlog-size |
复制积压缓冲区大小，用于增量复制 | 64mb（避免网络抖动导致全量复制） |
replica-read-only |
从节点是否只读 | yes（强制从节点只读，防止数据不一致） |
min-replicas-to-write |
主节点写入前至少需要 N 个从节点确认 | 1（保证至少一个从节点同步） |
关键注意：主从复制是异步的，主节点写入成功后立即返回，不等待从节点确认。在契约测试中，如果从节点延迟较大，可能导致错误码断言读取到过期数据。建议配合
WAIT 命令或哨兵机制保证读写一致性。
5. 契约测试中的 Redis 设计要点
- 数据结构选择：契约元数据用 Hash，契约内容用 String，错误码集合用 Set，变更事件用 List。
- 过期策略：临时断言缓存设置 TTL 为 300s，配合 volatile-ttl 淘汰策略。
- 持久化组合：RDB 每小时全量备份 + AOF everysec 增量保护，确保错误码断言数据不丢失。
- 主从架构：至少一主两从，从节点用于读取断言缓存，主节点处理写入；配合哨兵实现自动故障转移。