1. 课程导论：Redis主从同步与故障切换在缓存回归冒烟中的重要性
在微服务与高并发架构中，Redis 作为缓存层承担着抗流量、降延迟的核心职责。一旦缓存层出现数据不一致、同步延迟或主节点宕机，将直接引发缓存击穿、雪崩甚至业务中断。因此，在每次版本迭代或配置变更后，缓存回归冒烟必须覆盖 Redis 主从同步与故障切换两大核心能力，确保缓存层具备生产级韧性。
1.1 为什么缓存回归冒烟必须验证主从同步？
Redis 主从复制是数据冗余与读写分离的基础。回归冒烟中验证主从同步，核心目标有三：
- 数据一致性：主节点写入后，从节点能否在预期延迟内完成全量或增量同步。
- 同步链路健康：复制缓冲区（repl_backlog）、网络抖动、RDB 传输是否正常。
- 版本兼容性：Redis 版本升级或配置变更后，主从间的协议与命令兼容性。
| 验证维度 | 冒烟检查项 | 预期指标 |
|---|---|---|
| 全量同步 | 主节点 RDB 生成与传输 | 从节点完成加载，无超时 |
| 增量同步 | 命令传播延迟 | master_repl_offset 与 slave_repl_offset 差值 < 100 |
| 链路稳定性 | 复制缓冲区溢出检测 | repl_backlog_histlen 未满 |
| 数据一致性 | 主从 key 抽样比对 | 抽样命中率 100% |
实践建议：在回归冒烟脚本中，通过
INFO replication 命令采集 master_repl_offset 与 slave_repl_offset，若差值持续超过阈值（如 1000），应判定为同步异常并触发告警。
1.2 故障切换：缓存高可用的最后一道防线
当 Redis 主节点发生宕机、网络分区或进程崩溃时，自动故障切换（Sentinel 或 Redis Cluster）必须能在秒级完成新主选举与拓扑切换。缓存回归冒烟需要验证以下场景：
- 主观下线与客观下线：Sentinel 集群能否在
down-after-milliseconds内达成共识。 - Leader 选举与 failover：从节点晋升为主节点后，数据完整性是否受损。
- 客户端重连：业务侧连接池能否感知新主节点并恢复读写。
- 原主恢复后的角色转换：旧主节点重新上线后，能否正确降级为从节点并重新同步。
常见陷阱：部分团队在冒烟测试中只验证了正常读写，却忽略了故障切换后的数据一致性校验。例如，主节点宕机前最后一批写入可能因异步复制而丢失，导致切换后缓存数据与数据库不一致。回归冒烟必须包含“切换后数据校验”步骤。
1.3 主从同步与故障切换的协同关系
主从同步是故障切换的数据基础，故障切换是主从同步的高可用保障。两者在回归冒烟中必须串联验证，而非割裂测试。下图展示了缓存回归冒烟中两者的协同流程：
1.4 回归冒烟中的关键验证指标
为了量化验证结果，缓存回归冒烟应围绕以下核心指标建立通过/失败标准：
| 指标类别 | 指标名称 | 冒烟通过标准 |
|---|---|---|
| 同步延迟 | 主从 offset 差值 | ≤ 100（正常网络下） |
| 同步完整性 | 从节点 key 数量 | ≥ 主节点 99.9% |
| 切换时间 | 故障切换总耗时 | ≤ 15 秒（Sentinel 默认配置） |
| 切换后可用性 | 新主节点写入成功率 | 100% |
| 数据一致性 | 切换前后 key 值比对 | 无差异 |
课程目标：通过本课程，你将掌握如何设计一套完整的 Redis 主从同步与故障切换回归冒烟方案，包括测试用例编写、自动化脚本实现、指标采集与结果判定，确保缓存层在每一次变更后依然具备生产级高可用能力。