4. Redis 主从复制：主从架构、同步原理、哨兵模式在迁移中的作用
在 Redis 迁移场景中，主从复制是保障数据一致性与高可用的核心机制。理解主从架构、同步原理以及哨兵模式，能够帮助测试人员设计出覆盖数据完整性、故障转移与迁移回滚的冒烟用例。
4.1 主从复制架构
Redis 主从复制采用一主多从的星型拓扑。主节点（Master）负责处理写请求，从节点（Slave）通过复制主节点的数据来提供读能力或作为热备。
架构要点：
- 主节点：唯一可写节点，所有写操作先写入主节点，再异步/同步传播到从节点。
- 从节点：只读节点，可水平扩展以分担读流量；在迁移中作为数据校验的基准源。
- 复制方向：单向，从主到从；从节点之间不互相复制。
4.2 同步原理与迁移影响
Redis 主从同步分为全量同步和增量同步两个阶段。迁移过程中，理解同步机制有助于判断数据一致性的风险窗口。
| 同步阶段 | 触发条件 | 迁移影响 |
|---|---|---|
| 全量同步 | 从节点首次连接、主从偏移量差距过大、复制积压缓冲区溢出 | 主节点执行 BGSAVE 生成 RDB，传输到从节点；期间主节点 CPU/IO 升高，迁移时需避免触发全量同步 |
| 增量同步 | 从节点正常连接，主从偏移量在复制积压缓冲区范围内 | 主节点将写命令写入复制积压缓冲区，异步发送给从节点；迁移时增量同步延迟是数据一致性的关键指标 |
冒烟测试关注点：迁移前检查主从复制偏移量（
master_repl_offset 与 slave_repl_offset），确保两者差值小于阈值（如 1000）；迁移过程中持续监控复制延迟，避免因网络抖动导致全量同步。
4.3 哨兵模式在迁移中的作用
哨兵（Sentinel）模式为主从架构提供高可用保障。在迁移场景中，哨兵负责监控主节点状态，并在主节点故障时自动执行故障转移，选举新的主节点。
哨兵核心职责：
- 监控：定期向主从节点发送
PING，检测节点存活状态。 - 通知：当被监控节点出现故障时，哨兵通过 API 通知管理员或其他客户端。
- 自动故障转移：当主节点不可达时，哨兵集群选举一个从节点升级为新的主节点，并更新其他从节点的复制目标。
- 配置提供：客户端通过哨兵获取当前主节点的地址，实现透明切换。
4.4 迁移中的主从复制冒烟测试用例
基于上述原理，设计以下冒烟测试用例，覆盖迁移前、迁移中、迁移后的主从复制场景。
| 用例编号 | 测试场景 | 操作步骤 | 预期结果 |
|---|---|---|---|
| TC-RPL-01 | 迁移前主从复制状态检查 | 执行 INFO replication 检查主从角色、偏移量、连接状态 |
主从角色正确，master_link_status:up，偏移量差值 < 1000 |
| TC-RPL-02 | 迁移过程中增量同步延迟 | 迁移工具持续写入，每 5 秒检查从节点偏移量 | 从节点偏移量持续增长，延迟 < 2 秒 |
| TC-RPL-03 | 迁移过程中主节点故障转移 | 手动停止主节点进程，观察哨兵是否选举新主节点 | 哨兵在 30 秒内完成故障转移，新主节点可写，从节点重新指向新主节点 |
| TC-RPL-04 | 迁移完成后主从数据一致性 | 对比主节点与从节点的 key 数量、指定 key 的 value 值 | 主从节点数据完全一致，无丢失或错乱 |
| TC-RPL-05 | 迁移回滚后主从复制恢复 | 回滚至旧集群，检查主从复制链路是否自动重建 | 旧主节点恢复写入，从节点重新同步，复制状态正常 |
避坑提示：
- 迁移前务必确认哨兵集群的
quorum配置，避免因哨兵节点不足导致故障转移失败。 - 迁移过程中不要同时触发全量同步（如重启从节点），否则会大幅增加主节点负载，影响迁移性能。
- 迁移完成后，及时更新客户端或迁移工具的哨兵配置，指向新集群的主节点地址。