2. Redis 基础架构回顾：主从复制、哨兵模式、集群模式的核心原理
在分析故障转移对模板引擎渲染流程的影响之前，必须首先厘清 Redis 的三种基础架构模式。每种模式在数据一致性、可用性和故障转移能力上存在本质差异，这些差异直接决定了上游模板引擎在缓存失效或连接中断时的行为。
2.1 主从复制模式
主从复制是 Redis 高可用的基石。一个主节点（Master）负责处理写请求，多个从节点（Slave）通过异步复制同步数据，主要承担读流量和热备角色。
核心特征： 主节点故障后，不会自动进行故障转移。需要人工介入或借助外部工具（如 Sentinel）提升从节点为主节点。
复制流程关键步骤
- 连接建立： 从节点向主节点发送
PSYNC命令，携带运行 ID 和复制偏移量。 - 全量同步（RDB）： 主节点执行
BGSAVE生成 RDB 快照，发送给从节点；从节点清空旧数据并加载 RDB。 - 增量同步（积压缓冲区）： 主节点将同步期间的写命令存入
repl_backlog_buffer，从节点加载完 RDB 后继续接收增量命令。 - 命令传播： 进入正常复制阶段，主节点每秒向从节点发送
REPLCONF ACK确认偏移量。
| 特性 | 说明 |
|---|---|
| 数据一致性 | 最终一致性，异步复制存在秒级延迟 |
| 故障转移 | 手动切换，需运维介入 |
| 写能力 | 单点写入，主节点瓶颈 |
| 读扩展 | 支持水平扩展从节点 |
模板引擎影响： 在主从模式下，若主节点宕机，模板引擎的缓存写入会立即失败。从节点只读，无法接管写入，导致渲染流程中所有依赖 Redis 写入的操作（如缓存预热、会话存储）中断，直到人工恢复。
2.2 哨兵模式
哨兵模式在主从复制基础上增加了自动故障转移能力。哨兵（Sentinel）是一个独立进程，负责监控、通知和自动切换。
哨兵核心职责
- 监控： 每秒向所有节点发送
PING，检测主观下线（SDOWN）和客观下线（ODOWN）。 - 选举： 当主节点被判定为客观下线，哨兵集群通过 Raft 算法 选举 Leader 执行故障转移。
- 切换： 从从节点中选出优先级最高、数据最完整的一个提升为新主节点，并通知其他从节点切换复制目标。
- 通知： 通过发布/订阅向客户端推送新主节点地址。
注意： 哨兵模式仍然存在 写丢失 风险。由于主从复制是异步的，主节点宕机时最后一批写入命令可能尚未同步到从节点，切换后这些数据永久丢失。
| 参数 | 默认值 | 说明 |
|---|---|---|
sentinel monitor |
— | 指定监控的主节点名称、IP、端口和法定人数 |
down-after-milliseconds |
30000 | 主观下线判定时间（毫秒） |
failover-timeout |
180000 | 故障转移超时时间（毫秒） |
parallel-syncs |
1 | 故障转移后同时同步的新从节点数量 |
模板引擎影响： 哨兵模式将故障转移时间从人工小时级缩短到 10~30 秒。在这段时间内，模板引擎的缓存读取可能返回
nil 或连接异常。若模板渲染依赖缓存数据，需在应用层实现 降级策略（如直接查询数据库或返回静态默认值）。
2.3 集群模式
Redis Cluster 是真正的分布式方案，数据自动分片到 16384 个哈希槽，每个节点负责一部分槽位。集群模式内置了故障转移能力，无需额外组件。
核心设计要点
- 无中心架构： 所有节点通过
Gossip协议交换状态信息，客户端可连接任意节点。 - 数据分片： 使用
CRC16(key) % 16384计算槽位，每个节点维护槽位映射表。 - 主从冗余： 每个主节点至少挂载一个从节点；主节点故障时，从节点自动提升。
- 故障检测： 集群中超过半数主节点认为某节点不可达，则标记为
FAIL，触发从节点选举。
关键差异： 集群模式下，故障转移是 分片级别 的。只有故障主节点负责的槽位会短暂不可用，其他分片继续服务。模板引擎的缓存请求如果命中正常分片，不受影响。
| 对比维度 | 主从复制 | 哨兵模式 | 集群模式 |
|---|---|---|---|
| 自动故障转移 | 否 | 是（哨兵驱动） | 是（内置） |
| 数据分片 | 否 | 否 | 是（16384 槽） |
| 写能力 | 单点 | 单点 | 多点并行 |
| 故障影响范围 | 全局写中断 | 全局写中断（10~30s） | 仅故障分片 |
| 客户端复杂度 | 低 | 中（需支持哨兵） | 高（需支持集群协议） |
模板引擎适配注意： 集群模式下，模板引擎使用的 Redis 客户端必须支持
MOVED 和 ASK 重定向。若客户端不支持集群协议，会导致大量请求错误，渲染流程可能因缓存查询失败而回退到数据库，引发 缓存雪崩。
2.4 三种模式对比总结
下表从模板引擎渲染流程最关心的维度进行横向对比，帮助架构师根据业务场景选择合适的基础架构。
| 评估维度 | 主从复制 | 哨兵模式 | 集群模式 |
|---|---|---|---|
| 故障转移时间 | 人工（分钟~小时） | 10~30 秒 | 2~10 秒（分片级） |
| 缓存写入可用性 | 故障期间不可写 | 切换期间不可写 | 仅故障分片不可写 |
| 缓存读取可用性 | 从节点可读（可能读到旧数据） | 从节点可读 | 正常分片完全可用 |
| 数据一致性风险 | 异步复制丢数据 | 异步复制丢数据 | 异步复制丢数据（分片内） |
| 模板引擎适配成本 | 低 | 中（需哨兵客户端） | 高（需集群客户端 + 重定向处理） |
| 推荐场景 | 开发/测试环境 | 中小规模生产（< 50GB 缓存） | 大规模生产（> 50GB 缓存，高并发写） |
架构选择建议： 对于模板引擎渲染场景，如果缓存数据量小且允许秒级中断，哨兵模式性价比最高。如果缓存数据量大、并发高，且要求故障转移对渲染流程影响最小化，集群模式是唯一选择。无论哪种模式，都必须在应用层实现 缓存降级 + 熔断 机制，避免故障转移期间数据库被打垮。