Redis高可用架构全解析：从主从复制到集群方案

一、为什么需要高可用？

Redis作为核心数据存储，单点故障可能导致：

1. 数据丢失风险：未持久化的数据将永久丢失
2. 服务不可用：所有依赖Redis的服务将中断
3. 业务损失：电商、金融等场景可能造成重大损失

高可用设计目标：故障自动切换，保障服务连续性。

二、Redis高可用三大核心方案

1. 基础方案：主从复制（Replication）

架构原理：

建立主从连接的三种方式（slave连接master）

方式一：客户端发送命令

slaveof <masterip> <masterport>

方式二：启动服务器参数

redis-server -slaveof <masterip> <masterport>

方式三：服务器配置

vim redis.conf
slaveof <masterip> <masterport>

复制流程：

• 主从复制过程大体可以分为3个阶段
  • 建立连接阶段（即准备阶段）
  • 数据同步阶段
  • 命令传播
    

# 全量同步流程
1. 从服务器发送 PSYNC ? -1 命令
2. 主服务器执行 BGSAVE 生成 RDB 文件
3. 主服务器将 RDB 文件发送给从服务器
4. 从服务器清空数据库并载入 RDB 文件
5. 主服务器将复制积压缓冲区的命令发送给从服务器

# 触发全量同步的情况：
- 首次连接
- 复制ID不匹配
- 偏移量不在积压缓冲区范围内

# 增量同步流程
1. 从服务器发送 PSYNC   命令
2. 主服务器检查复制ID和偏移量
3. 如果偏移量在积压缓冲区范围内，发送 +CONTINUE
4. 主服务器发送积压缓冲区中的命令

# 增量同步的优势：
- 减少网络传输
- 降低主服务器负载
- 缩短同步时间

特点

• 一主多从，读写分离
• 数据冗余备份
• 手动故障切换

优势：

• 简单易实现
• 低成本扩展读性能

局限：

• 故障切换需人工干预
• 写性能无法扩展
• 存在主从延迟

2. 自动故障转移——哨兵模式

为什么要有哨兵模式？

在主从复制的架构中，是依赖主节点进行写操作的，如果主节点挂了，那么将无法执行客户端的写操作请求。要想恢复服务，只能通过人工介入的方式，重启主节点或者换一个主节点，太不人性化了。我们想要的是主节点挂了以后，可以自动切换另一个可用的节点为主节点，哨兵（Sentinel）机制就是解决这个问题的，它的作用是实现主从节点故障转移

架构原理：

核心功能：

• 节点监控
• 自动故障转移（选主）
• 通知

  具体工作流程：

  1. 节点监控：哨兵 每秒会向主从节点发送PING 命令，如果服务器正常，会返回给哨兵一个响应 PING 命令的回复有两种情况：
  2. 有效回复：返回 +PONG、-LOADING、-MASTERDOWN 任何一种；
  3. 无效回复：有效回复之外的回复，或者再指定时间内返回任何回复。
     如果一个哨兵收到了无效回复，就会就其标记为主观下线，如果是主节点被标记了主观下线，会向其他哨兵发起投票，其他哨兵根据回复情况投出赞成或反对票，当投票数达到预设值时，就会标记为客观下线，在主节点被标记后，就需要从正常的从节点选一个为新的主节点

     客观下线只针对于主节点，哨兵的赞同票数的值时通过哨兵配置文件中的 quorum 配置，一般设置为哨兵个数的二分之一加 1

  4. 自动故障转移（选主）：
  5. 通过选举的方式选择领导哨兵，由领导哨兵来执行主从切换
  6. 从服务器中选择新的升级为主服务器
  7. 执行主从切换

     哨兵选举和主服务器选择以及主从切换的详细过程这里就不展开来讲了。感兴趣的同学可以自行学习

  8. 更新配置信息（通知）：通过 pub/sub 机制发布不同事件，让客户端在这里订阅消息

     部署建议：

  • 至少3个Sentinel节点
  • 跨物理机部署

特点

优势：

• 自动故障切换
• 客户端自动发现节点
  局限：
• 写性能瓶颈仍在单主节点
• 扩容复杂度高

3. 分布式方案——Cluster集群

为什么要有Cluster集群？

有了哨兵以后，我们实现了自动检测以及自动故障转移，看起来已经很完美了。但是呢，随着你的数据量越来越大。虽然你部署了好几台服务器，但是所有的服务器的数据都是一样的，实际可以保存的数据量还是一台服务器可以存储的数据。比如服务器的内存时5G，此时你想存15G的数据，即便有三台服务器，还是只能存5G的数据。Cluster集群就是解决这个问题的，他可以将数据分开在服务器上保存
架构原理：
Redis Cluster方案采用哈希槽（Hash Slot），来处理数据和实例之间的映射关系

16384个哈希槽 → 分散到多个主节点
每个主节点对应N个从节点

# 数据分片机制
键名->计算hash值->取模（% 16384）->槽位（Slot 8765）-> 节点

核心特性：

• 数据分片存储
• 自动数据迁移
• 节点间Gossip协议通信

部署命令：

redis-cli --cluster create 192.168.1.101:6379 192.168.1.102:6379 ...

数据路由原理：

slot = CRC16(key) % 16384

优势：

• 真正的分布式架构
• 支持水平扩展
• 自动故障转移

局限：

• 客户端需支持集群协议
• 跨slot操作受限