当前位置：首页 > news >正文

Redis 三种服务架构详解：主从复制、哨兵模式与集群

news 2025/9/22 6:43:50

前言

一、Redis 三种模式概述

二、Redis 主从复制

2.1 原理与作用

2.2 同步流程

2.3 搭建步骤

三、Redis 哨兵模式（Sentinel）

3.1 为什么需要哨兵

3.2 哨兵原理

3.3 核心功能

3.4 故障转移机制简述

3.5 部署步骤

3.6 主节点的选举流程

完整选举流程概述：

四、Redis Cluster 集群模式

4.1 概述

4.2 作用

4.3 哈希槽机制

4.4 部署步骤

五、总结

前言

在生产环境中，单机版 Redis 很难满足高可用、高并发和大容量的需求，因此诞生了多种架构模式。本文将带你系统了解 Redis 的三种常见服务架构：主从复制、哨兵模式和 Cluster 集群，并配合配置示例帮助你快速上手。

一、Redis 三种模式概述

Redis 的高可用方案主要有三类：

主从复制：高可用的基础。实现多机备份、读操作负载均衡、简单故障恢复。缺点是故障恢复需要人工干预、写操作无法负载均衡、存储能力受单机限制。
哨兵模式（Sentinel）：在主从复制基础上，提供主节点自动故障转移。缺点是写操作仍然无法负载均衡、存储能力受单机限制、从节点故障需额外监控。
集群模式（Cluster）：解决了写操作无法负载均衡和单机容量限制，实现分布式存储与更完善的高可用。

下文将分别介绍它们的原理与搭建方法。

二、Redis 主从复制

2.1 原理与作用

主从复制是指一台 Redis 服务器（Master）把数据复制到其他 Redis 服务器（Slave）。数据流向单向：Master → Slave。

作用：

数据冗余：热备份，是持久化之外的一种保障。
故障恢复：Master 宕机时可由 Slave 提供读服务，快速恢复。
读写分离：Master 负责写、Slave 负责读，分担负载，提升并发。
高可用基石：是哨兵与集群模式的基础。

2.2 同步流程

Slave 启动后向 Master 发送 SYNC 命令请求同步。
Master 执行一次 RDB 快照（bgsave），并记录增量写命令。
Master 把快照文件发给 Slave，Slave 保存到磁盘并加载到内存。
Master 持续把后续写操作发送给 Slave；Slave 宕机重连后自动同步。

2.3 搭建步骤

假设：

Master：192.168.114.50
Slave1：192.168.114.251
Slave2：192.168.114.252

关闭防火墙和 SELinux：

systemctl stop firewalld
setenforce 0

安装 Redis：

yum install -y gcc gcc-c++ make
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7 && make && make PREFIX=/usr/local/redis install
cd /opt/redis-5.0.7/utils
./install_server.sh
ln -s /usr/local/redis/bin/* /usr/local/bin/

Master 配置 /etc/redis/6379.conf：

bind 0.0.0.0                        #70行，修改监听地址为0.0.0.0
daemonize yes                       #137行，开启守护进程
logfile /var/log/redis_6379.log     #172行，指定日志文件目录
dir /var/lib/redis/6379             #264行，指定工作目录
appendonly yes                      #700行，开启AOF持久化功能

/etc/init.d/redis_6379 restart

Slave 配置 /etc/redis/6379.conf：

bind 0.0.0.0
daemonize yes
logfile /var/log/redis_6379.log
dir /var/lib/redis/6379
replicaof 192.168.114.50 6379   #288行，指定要同步的Master节点IP和端口
appendonly yes

/etc/init.d/redis_6379 restart

启动服务并验证：

#在Master节点上验证从节点：
redis-cli info replication

三、Redis 哨兵模式（Sentinel）

3.1 为什么需要哨兵

主从复制需要人工切换 Master，容易造成服务中断。哨兵机制的出现解决了这一问题，实现主节点的自动故障转移。

3.2 哨兵原理

哨兵是一个分布式系统，用于监控 Master/Slave。
通过定期心跳检测、投票选举 Leader 哨兵。
当 Master 故障时，Leader 哨兵会自动将某个 Slave 提升为新的 Master，并通知其他节点和客户端。

3.3 核心功能

监控：检查 Master/Slave 健康状态。
自动故障转移：提升 Slave 为新 Master，当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其它从节点改为复制新的主节点。
通知：将变更结果告知客户端。

3.4 故障转移机制简述

每个哨兵每秒向 Master、Slave、其他哨兵发送 ping。
半数以上哨兵判定 Master 下线 → “客观下线”。
选举 Leader 哨兵，由其执行：
- 提升 Slave 为 Master。
- 重新指向其他 Slave。
- 通知客户端。

3.5 部署步骤

环境：

Master：192.168.114.50
Slave1：192.168.114.251
Slave2：192.168.114.252

编辑 /opt/redis-5.0.7/sentinel.conf：

protected-mode no                                   #17行，关闭保护模式
port 26379                                          #21行，Redis哨兵默认的监听端口
daemonize yes                                       #26行，指定sentinel为后台启动
logfile "/var/log/sentinel.log"                     #36行，指定日志存放路径
dir "/var/lib/redis/6379"                           #65行，指定数据库存放路径
sentinel monitor mymaster 192.168.114.50 6379 2     #84行，修改 指定该哨兵节点监控
sentinel down-after-milliseconds mymaster 30000     #113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000           #146行，故障节点的最大超时时间为180000（180秒）

启动哨兵：

#先启master，再启slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

验证：

redis-cli -p 26379 info Sentinel
tail -f /var/log/sentinel.log

可通过 kill -9 杀掉 Master redis-server 测试自动切换。

3.6 主节点的选举流程

当主节点宕机被哨兵判定为“客观下线”后，Leader 哨兵会负责挑选一个从节点升级为新的主节点。选举过程并不是随意的，有一套规则：

过滤掉不健康的从节点
- 哨兵会首先剔除那些已经下线、没有响应 ping、延迟过大的从节点，只考虑健康的从节点。
优先级（replica-priority）最高的优先
- 每个从节点在 redis.conf 中都有 replica-priority（默认100）。值越小优先级越高，值为0表示永不选举。
- 哨兵会优先挑选优先级最高（数值最小）的从节点。
复制偏移量最大（数据最完整）的优先
- 对比各从节点的 offset，偏移量越大表示同步的数据越多，数据越完整，优先选它。
最后按运行 ID（Run ID）最小的优先
- 如果优先级、偏移量都相同，按从节点的运行 ID（即Redis实例唯一标识）最小的那个来决定。

这套机制保证了新主节点尽可能健康且数据最新，从而减少切换带来的不一致风险。

完整选举流程概述：

多个哨兵节点通过 Raft 类似的投票选举出一个 Leader 哨兵；
Leader 哨兵根据上面四条规则选出最合适的 Slave 升级为 Master；
其余 Slave 自动指向新 Master，原 Master 恢复后降为 Slave。

四、Redis Cluster 集群模式

4.1 概述

Redis Cluster 从 3.0 开始引入，支持分布式存储与高可用。节点分为 Master（负责读写、维护集群信息）和 Slave（复制 Master 数据）。

4.2 作用

数据分片：将数据分布在多个节点，突破单机内存限制，提高吞吐。
高可用：支持主从复制+自动故障转移。

4.3 哈希槽机制

集群共 16384 个槽（0–16383）。
每个 Key 通过 CRC16 校验再取模确定槽号。
每个节点负责一部分槽。

示例：

节点A：槽 0–5460
节点B：槽 5461–114922
节点C：槽 114923–16383

可为每个主节点配一个从节点（A1、B1、C1），提升容灾能力。

4.4 部署步骤

创建目录并拷贝配置：

#redis的集群一般需要6个节点，3主3从。方便起见，这里所有节点在同一台服务器上模拟：
#以端口号进行区分：3个主节点端口号：6001/6002/6003，对应的从节点端口号：6004/6005/6006。
mkdir -p /etc/redis/redis-cluster/redis600{1..6}
for i in {1..6};docp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$icp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done

配置示例（redis6001/redis.conf）：

#bind 127.0.0.1                             #69行，注释掉bind 项，默认监听所有网卡
protected-mode no                           #88行，修改，关闭保护模式
port 6001                                   #92行，修改，redis监听端口，
daemonize yes                               #136行，开启守护进程，以独立进程启动
cluster-enabled yes                         #832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf         #840行，取消注释，群集名称文件设置
cluster-node-timeout 15000                  #846行，取消注释群集超时时间设置
appendonly yes                              #700行，修改，开启AOF持久化

其余5个实例端口、配置分别改为6002~6006。

#可改好6001后快速复制文件,随后依次去修改端口
for i in {2..6}; do 
cp /etc/redis/redis-cluster/redis6001/redis.conf /etc/redis/redis-cluster/redis600$i/redis.conf 
done

启动各节点：

for d in {1..6};docd /etc/redis/redis-cluster/redis600$dredis-server redis.conf
done

创建集群：

redis-cli --cluster create \
127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 \
127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 \
--cluster-replicas 1

测试：

redis-cli -p 6001 -c
127.0.0.1:6001> cluster slots           #查看节点的哈希槽编号范围
127.0.0.1:6001> set name zhangsan
127.0.0.1:6001> cluster keyslot name    #查看name键的槽编号