Redis-缓存-雪崩-持久化、集群、灾备

一、来因宫

1.1、原因

大量缓存数据同时过期失效，或者缓存服务器因故障、网络问题等原因突然不可用，导致原本应该由缓存处理的大量请求瞬间全部涌向数据库（或后端存储系统），造成数据库压力骤增，甚至引发数据库宕机，进而导致整个应用服务不可用的连锁反应

大批量的key失效或者redis服务器死掉了，造成的数据库压力
回顾一下和穿透、击穿的区别：
1、穿透是有人故意为之，可能本来就没有对应的数据
2、击穿是某个热点key失效，导致的问题
3、雪崩是大批量key失效，或者是服务器故障

1.2、 问题分析

大批量key失效的场景：
1、周期性定时更新key，定义时效周期一致
2、redis重启，key值全部失效
3、批量热点数据存在先删除后添加的逻辑，出现空档

思路过程：1、失效周期一致的key进行自定义加减时间，让失效时间错开2、对于宕机重启问题，开启 RDB+AOF、集群化避免单节点、灾备策略等等3、调整key更新逻辑，直接更新参数

二、技术方案

2.1、设置不同缓存时间

1、针对大批量的key同时过期，将他们设置成不同的过期时间

# 1小时~1.5小时随机过期
expire_time = 3600 + random.randint(0, 1800)  
redis.set(key, value, ex=expire_time)

2.2、RDB+AOF

是两种核心的持久化机制，用于将内存中的数据持久化到磁盘，防止 Redis 重启后数据丢失。

1、RDB 是 Redis 默认的持久化方式，通过生成内存数据的快照（二进制文件） 来保存数据。
触发方式 ：
自动触发：通过redis.conf配置触发条件（如save 900 1表示 900 秒内有 1 次写入则触发快照），多个条件满足其一即执行。【每个系统安装方式不同配置路径有差异，自行查找】
手动触发：执行SAVE（阻塞 Redis，直到快照完成，不建议生产环境使用）或BGSAVE（后台异步执行，通过 fork 子进程生成快照，不阻塞主进程）命令。

2、AOF 通过记录所有写命令（如 SET、HSET） 来持久化数据，Redis 重启时通过重放命令恢复数据。
触发方式：
所有写命令会追加到 AOF 缓冲区，再根据配置的同步策略写入磁盘（默认文件名为appendonly.aof）。
同步策略（appendfsync配置）：
always：每个命令立即同步到磁盘（安全性最高，性能最差）。
everysec：每秒同步一次（默认值，平衡安全性和性能，最多丢失 1 秒数据）。
no：由操作系统决定何时同步（性能最好，安全性最低）。

2.3、集群化避免单节点

集群可以将单机性能问题、单点故障问题解决，将数据存储在多个节点上，实现高可用

Redis 集群是为了解决单机 Redis 的性能瓶颈（如内存、QPS 上限）和单点故障问题而设计的分布式方案，主要通过分片存储和主从复制实现高可用与水平扩展。目前主流的 Redis 集群方案有两种：Redis 官方集群（Redis Cluster） 和主从 + 哨兵（Sentinel）架构，以下是详细介绍：

一、Redis 官方集群（Redis Cluster）

Redis 3.0 及以上版本内置的集群方案，是大规模 Redis 部署的首选，核心特点是数据分片和去中心化。

1. 核心原理

• 哈希槽（Hash Slot）分片：
  集群将数据划分为 16384 个哈希槽，每个主节点负责一部分槽位（如 3 主节点可分别负责 0-5460、5461-10922、10923-16383 槽）。
  数据存储时，通过 CRC16(key) % 16384 计算 key 所属槽位，仅存储在负责该槽的主节点上，实现数据分片。

• 主从复制与高可用：
  每个主节点可配置多个从节点（建议至少 1 个），从节点实时复制主节点数据。当主节点故障时，从节点会通过选举自动成为新主节点，保证服务不中断。

• 去中心化通信：
  集群中所有节点平等，通过 Gossip 协议交换信息（如节点状态、槽位分配），客户端可连接任意节点获取集群全局信息。

2. 部署要求

• 至少需要 3 个主节点（每个主节点建议配 1 个从节点，共 6 个节点），确保高可用和槽位均匀分配。
• 所有节点需开启集群模式（cluster-enabled yes），并配置集群配置文件路径（cluster-config-file nodes.conf）。

3. 关键操作

• 创建集群（Redis 5.0+ 用 redis-cli --cluster）：

  redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1  # 每个主节点配 1 个从节点
  

• 查看集群状态：
  连接任意节点后执行 cluster info（查看集群整体状态）或 cluster nodes（查看节点列表及槽位分配）。
• 添加节点与迁移槽位：
  新增节点后，通过 redis-cli --cluster add-node 加入集群，再用 redis-cli --cluster reshard 迁移槽位实现负载均衡。

4. 适用场景

• 数据量超过单机内存上限（如 TB 级数据），需要分片存储。
• 高并发读写场景（单节点 QPS 不足，多节点分担压力）。
• 希望简化运维（自动故障转移、动态扩缩容）。

二、主从 + 哨兵（Sentinel）架构

基于“主从复制”和“哨兵监控”的集群方案，核心是高可用保障和读写分离，适用于数据量不大但需高可用的场景。

1. 核心组件

• 主节点（Master）：处理所有写请求和部分读请求，是数据的“权威源”。
• 从节点（Slave）：通过 slaveof 命令复制主节点数据，仅处理读请求（分担主节点压力）。
• 哨兵节点（Sentinel）：监控主从节点健康状态，当主节点故障时，自动将从节点升级为新主节点，并通知客户端更新连接地址。

2. 核心原理

• 主从复制：从节点通过 PSYNC 命令与主节点同步数据（全量复制 + 增量复制），保证数据一致性。
• 哨兵机制：
  • 多个哨兵节点（建议至少 3 个）通过投票判断主节点是否“客观下线”（超过半数哨兵同意）。
  • 下线后，哨兵从从节点中选举新主节点（优先选择数据最新、网络状况好的从节点），并通过 slaveof no one 使其成为主节点，其他从节点改为复制新主节点。

3. 部署配置

• 主从配置（从节点 redis.conf）：

  slaveof 127.0.0.1 6379  # 指向主节点 IP:端口
  replica-read-only yes  # 从节点只读（Redis 5.0+ 用 replicaof 替代 slaveof）
  

• 哨兵配置（sentinel.conf）：

  sentinel monitor mymaster 127.0.0.1 6379 2  # 监控名为 mymaster 的主节点，2 个哨兵认为其下线则触发故障转移
  sentinel down-after-milliseconds mymaster 30000  # 30 秒未响应视为下线
  sentinel failover-timeout mymaster 180000  # 故障转移超时时间 180 秒
  

• 启动哨兵：

  redis-sentinel sentinel.conf  # 启动哨兵进程（需启动至少 3 个）
  

4. 适用场景

• 数据量在单机内存范围内（无需分片），但需高可用（不允许单点故障）。
• 读多写少场景（可通过增加从节点扩展读吞吐量，如电商商品详情页缓存）。
• 需要兼容旧版本 Redis（Redis Cluster 需 3.0+，哨兵支持更早版本）。

三、两种集群方案对比

特性	Redis Cluster	主从 + 哨兵
数据分布	分片存储（16384 个槽）	全量复制（所有节点数据相同）
扩展能力	水平扩展（增加节点分担槽位）	读扩展（增加从节点），写能力受限
高可用机制	自动故障转移（主从 + 槽迁移）	哨兵选举新主节点
适用数据量	大（超过单机内存）	中/小（单机可容纳）
客户端接入	需支持集群协议（如 JedisCluster）	普通客户端（通过哨兵获取主节点地址）
运维复杂度	较高（槽位管理、扩缩容）	较低（主从 + 哨兵配置）

四、集群部署关键注意事项

1. 数据一致性：
   Redis 集群默认采用异步复制，主节点故障可能丢失少量数据。对强一致性要求高的场景（如金融交易），需结合业务逻辑补偿（如数据库双写）。

2. 网络与硬件：

   • 节点建议部署在同一机房，避免跨机房网络延迟导致数据同步超时。
   • 主从节点配置需一致（CPU、内存、磁盘），避免从节点因性能不足拖慢同步。

3. 监控与备份：

   • 监控集群状态：如节点存活、槽位分配、内存使用率（推荐工具：Prometheus + Grafana）。
   • 定期备份数据：结合 RDB + AOF 持久化，避免集群整体故障导致数据丢失。

4. 故障演练：
   定期手动触发主节点故障（如 kill 主节点进程），验证哨兵或集群的自动故障转移功能是否正常。

2.4、异地灾备

Redis 异地灾备（跨地域机房/地域的数据备份与故障切换）是保障核心业务在极端情况下（如机房断电、自然灾害）不丢失数据且能快速恢复的关键方案。其核心目标是：跨地域数据同步 + 故障时快速切换，以下是具体实现方案和关键设计。

一、异地灾备的核心需求

1. 数据一致性：异地备份数据需与主集群保持同步（至少最终一致），避免数据丢失。
2. 低延迟：同步延迟尽可能小（如秒级），减少故障时的数据丢失量。
3. 快速切换：主集群故障时，异地灾备集群能快速接管业务，降低 downtime。
4. 可靠性：灾备链路本身需高可用（如多线路备份），避免同步中断。

二、主流异地灾备方案

1. 基于主从复制的异地灾备（适合中小规模）

利用 Redis 原生的主从复制机制，将异地集群作为主集群的“远程从节点”，实现数据同步。

架构：

[主集群]  本地机房（如北京）├── 主节点 M1 + 从节点 S1（本地）└── 主节点 M2 + 从节点 S2（本地）↓（异步复制）
[灾备集群]  异地机房（如上海）├── 从节点 DR1（复制 M1）└── 从节点 DR2（复制 M2）

实现步骤：

• 异地灾备节点通过 replicaof 主集群主节点IP 端口 配置，作为远程从节点同步数据。
• 灾备集群内部可再配置从节点（如 DR1 配从节点 DR1-1），避免灾备节点单点故障。
• 主集群正常时，灾备节点仅作为备份（不提供服务）；主集群故障时，手动/自动将灾备节点切换为“主节点”，业务连接切换到异地集群。

优缺点：

• 优点：实现简单（利用原生复制）、低侵入性。
• 缺点：同步延迟较高（跨地域网络延迟）、主集群故障后需手动干预切换（无自动故障转移）。

2. 基于 Redis Cluster + 异地从节点（适合大规模集群）

对 Redis 官方集群（Redis Cluster），为每个主节点配置异地从节点，并在异地部署独立的哨兵或集群管理节点，实现跨地域灾备。

架构：

[主集群]  北京集群（3主3从）├── 主 M1 → 本地从 S1├── 主 M2 → 本地从 S2└── 主 M3 → 本地从 S3↓（异步复制）
[灾备集群]  上海集群（3个异地从节点 + 哨兵）├── 异地从 DR1（复制 M1）├── 异地从 DR2（复制 M2）├── 异地从 DR3（复制 M3）└── 哨兵集群（监控主集群，判断故障）

关键设计：

• 异地从节点仅同步数据，不参与主集群的槽位分配（避免影响主集群性能）。
• 部署异地哨兵集群，同时监控主集群和异地从节点：
  • 主集群正常时，哨兵仅记录状态；
  • 主集群故障（如北京机房下线），哨兵触发异地从节点“升主”，并重新分配槽位（形成新的上海集群）。
• 业务端通过“命名服务”（如 DNS、注册中心）切换连接地址（从北京集群 → 上海集群）。

优缺点：

• 优点：支持大规模集群、可结合哨兵实现半自动化切换。
• 缺点：需解决跨地域网络延迟对复制的影响（如调大 repl-timeout）、槽位重新分配耗时可能较长。

3. 基于第三方工具的双向同步（适合双活/多活场景）

通过工具（如 RedisShake、DMQ）实现两地集群的双向数据同步，支持“主-主”模式（两地集群均可读写），属于更高阶的灾备方案（双活/多活）。

架构：

[北京集群] ←→ [同步工具] ←→ [上海集群]（可读写）        （可读写）

实现原理：

• 同步工具通过解析主集群的 RDB/AOF 文件或监听 SYNC 命令，获取数据变更日志（如写命令）。
• 将变更日志异步同步到异地集群，并重放命令，实现两地数据一致。
• 解决“双写冲突”：通过业务层设计（如按 Key 分片写、时间戳冲突解决）避免两地同时修改同一 Key。

常用工具：

• RedisShake（阿里云开源）：支持 RDB 全量同步 + AOF 增量同步，跨版本兼容，适合大规模数据同步。
• DMQ（Data Migration Queue）：基于消息队列的同步工具，支持断点续传，适合高可用同步链路。

优缺点：

• 优点：支持双向读写（双活）、同步延迟低（毫秒级）、可自定义冲突解决策略。
• 缺点：实现复杂（需处理冲突、网络中断）、对业务侵入性较高（需适配双活逻辑）。

三、灾备切换流程设计

无论采用哪种方案，均需明确故障时的切换流程，确保快速恢复：

1. 故障检测：

   • 监控指标：主集群节点存活状态、网络连通性、数据同步延迟（如 INFO replication 中的 master_repl_offset 差距）。
   • 工具：Prometheus + AlertManager 监控，结合机房级监控（如 Ping 不通、电源告警）。

2. 手动切换（适合核心业务）：

   • 确认主集群故障无法恢复（避免误切换）。
   • 停止主集群与灾备集群的同步链路（防止数据回传）。
   • 将灾备集群切换为“主模式”（如执行 replicaof no one 升主、重新分配槽位）。
   • 业务端修改连接地址（如 DNS 切换、配置中心更新），指向灾备集群。
   • 验证数据完整性（对比关键 Key 的数量和值）。

3. 自动切换（适合非核心业务）：

   • 通过哨兵或自定义脚本自动执行切换流程（需严格控制触发条件）。
   • 关键：设置“脑裂”防护（如确认主集群多数节点下线才触发切换）。

四、关键注意事项

1. 网络优化：

   • 异地同步优先使用专线（如 MPLS VPN），降低延迟和丢包率。
   • 调整 Redis 复制参数：repl-backlog-size 调大（避免网络波动导致全量复制）、repl-diskless-sync yes（无盘复制，减少 IO 开销）。

2. 数据校验：

   • 定期校验灾备数据完整性（如通过 redis-cli --bigkeys 对比 Key 数量、抽样检查值）。
   • 关键业务建议保留多版本备份（如每日 RDB 快照 + 实时 AOF 同步）。

3. 演练：

   • 每季度至少一次灾备演练，模拟主集群故障，验证切换流程和数据恢复能力。
   • 记录演练耗时，持续优化（目标：核心业务切换时间 < 10 分钟）。

4. 成本平衡：

   • 非核心业务可采用“定时快照备份”（如每小时同步一次 RDB），降低专线成本。
   • 核心业务必须实时同步（如双向同步），容忍更高的网络和设备成本。