1. 课程概述
本课程聚焦于一个高可用架构中的经典难题：当 Redis 发生故障转移（Failover）时，正在进行的异步导出任务如何安全、无感地切换到新的数据源。本章作为开篇，首先界定三个核心概念：故障转移场景、异步导出任务背景，以及数据源切换面临的主要挑战。
1.1 Redis 故障转移场景
在 Redis 高可用架构中，故障转移通常由哨兵（Sentinel）或集群（Cluster）机制触发。当主节点（Master）不可用时，系统自动将一个从节点（Replica）提升为新的主节点。这一过程虽然保证了服务的持续可用，但对正在执行的数据导出任务却可能造成严重干扰。
典型故障转移触发条件：
- 主节点宕机或网络分区
- 主节点响应超时（如哨兵配置的
down-after-milliseconds） - 主节点内存或 CPU 资源耗尽
- 主节点主动下线进行维护
故障转移完成后，客户端需要重新发现新的主节点。对于异步导出任务而言，这意味着：
- 原有的连接句柄失效
- 正在进行的扫描游标（Cursor）可能指向旧节点
- 数据一致性窗口可能被破坏
1.2 异步导出任务背景
异步导出任务是指从 Redis 中批量读取数据，经过处理后写入外部存储（如数据库、消息队列、对象存储）的后台作业。这类任务通常具有以下特征：
| 特征维度 | 说明 | 对故障转移的敏感度 |
|---|---|---|
| 扫描方式 | 使用 SCAN 命令分批迭代，维护游标状态 |
高 — 游标在故障转移后可能失效 |
| 数据一致性 | 弱一致性，允许短暂的数据不一致 | 中 — 需要保证最终一致性 |
| 执行时长 | 分钟级到小时级，跨越多个连接生命周期 | 高 — 故障转移可能发生在任务执行中 |
| 断点续传 | 需要记录已导出数据的偏移量或键范围 | 高 — 故障转移后需要恢复断点 |
| 幂等性 | 目标存储应支持重复写入的幂等处理 | 中 — 避免数据重复或丢失 |
典型异步导出任务示例： 从 Redis 缓存中导出用户会话数据到 MySQL 进行离线分析，使用
SCAN 0 MATCH session:* COUNT 1000 分批读取，每批处理后更新断点记录。
1.3 数据源切换的核心挑战
当 Redis 发生故障转移后，异步导出任务需要从旧主节点切换到新主节点。这一过程面临以下核心挑战：
- 连接中断与重建 — 旧连接失效，需要快速发现新主节点并建立新连接，同时避免连接风暴。
- 游标状态丢失 —
SCAN命令的游标是连接级别的，故障转移后游标无法复用，需要重新开始扫描或从断点恢复。 - 数据一致性窗口 — 故障转移期间，旧主节点可能还有未同步到从节点的数据，切换后可能丢失部分数据。
- 任务状态管理 — 导出任务的进度、断点、错误计数等状态需要持久化，不能仅保存在内存中。
- 切换时机与策略 — 是立即切换还是等待当前批次完成？是全部任务一起切换还是逐个切换？
关键认知： 故障转移后的数据源切换不是简单的连接替换，而是一个涉及状态恢复、一致性保证、任务编排的系统工程。本课程后续章节将逐一深入每个挑战的解决方案。
1.4 课程目标与学习路径
通过本课程，你将掌握：
- Redis 故障转移的检测与通知机制
- 异步导出任务的断点设计与持久化方案
- 数据源切换的原子化操作与回滚策略
- 生产环境下的高可用导出架构设计
课程从基础概念出发，逐步深入到代码实现与架构设计，适合有一定 Redis 使用经验的后端工程师、架构师及 SRE 人员。