Redis 三种集群模式

Redis 三种集群模式详解（主从复制/哨兵/Cluster）

Redis 作为高性能的键值数据库，单机部署存在可用性低、存储容量有限、读写压力集中等问题。为解决这些问题，Redis 提供了三种核心集群模式，分别针对不同场景需求。本文将从模式定位、核心功能、工作原理、搭建步骤、验证与故障模拟五个维度，系统梳理三种模式的技术细节。

一、Redis 集群模式总览

三种模式的核心差异在于解决的问题侧重不同，且存在技术演进关系（主从复制是基础，哨兵和 Cluster 在此之上扩展），具体定位如下：

模式	核心解决问题	架构特点	适用场景
主从复制	数据冗余、读负载均衡、基础故障恢复（手动）	1主N从，数据单向同步	读多写少、需数据热备份的场景
哨兵模式	主节点自动故障转移，解决主从复制的手动切换问题	主从架构 + 哨兵集群（≥3个）	需高可用、自动故障恢复的场景
Cluster 集群	写负载均衡、存储容量扩展（数据分片）	3主3从（推荐），哈希槽分片	大规模数据、高并发读写的生产场景

二、模式一：主从复制（Master-Replica Replication）

主从复制是 Redis 高可用的基础，通过“1个主节点（Master）+ N个从节点（Replica/Slave）”实现数据单向同步（Master→Replica），核心是“数据备份”和“读负载分担”。

2.1 核心概念与作用

1. 角色定义

• Master 主节点：唯一可写入节点，负责接收写请求、生成数据变更日志（repl_backlog），并同步数据到从节点。
• Replica 从节点：只读节点，通过 replicaof 配置指定主节点，从主节点同步数据，分担读请求（如查询、统计）。

2. 核心作用

• 数据冗余：从节点是主节点的热备份，避免单机数据丢失风险（补充持久化的不足）。
• 故障恢复：主节点故障时，可手动将从节点切换为主节点（需人工干预）。
• 负载均衡：写请求走主节点，读请求分散到多个从节点，提升整体并发能力（适用于读多写少场景）。
• 高可用基石：哨兵模式和 Cluster 集群均依赖主从复制实现数据同步和故障转移。

2.2 主从复制流程

1. 从节点初始化同步：
   • 从节点启动后，发送 SYNC 命令（Redis 2.8+ 用 PSYNC 增量同步）请求与主节点同步。
   • 主节点收到请求后，暂停处理写请求，启动后台进程（bgsave）生成 RDB 快照文件，并将快照生成期间的写命令缓存到“复制缓冲区”。
2. 全量数据同步：
   • 主节点将 RDB 文件发送给从节点，从节点接收后写入本地磁盘，再加载到内存。
3. 增量数据同步：
   • 主节点将缓存的写命令（复制缓冲区）发送给从节点，从节点执行命令，确保数据与主节点一致。
4. 持续同步：
   • 后续主节点每产生一条写命令，都会通过“复制积压缓冲区”实时同步给从节点；从节点定期向主节点发送 REPLCONF ACK 确认同步进度。

2.3 搭建步骤（1主2从）

环境准备（所有节点）

# 关闭防火墙和SELinux（生产环境建议配置白名单，而非直接关闭）
systemctl stop firewalld
setenforce 0# 安装依赖（编译Redis需要GCC）
yum install -y gcc gcc-c++ make# 下载并解压Redis（以5.0.7版本为例）
wget http://download.redis.io/releases/redis-5.0.7.tar.gz -P /opt/
tar zxvf /opt/redis-5.0.7.tar.gz -C /opt/# 编译安装Redis
cd /opt/redis-5.0.7/
make && make PREFIX=/usr/local/redis install# 配置环境变量（方便全局调用Redis命令）
ln -s /usr/local/redis/bin/* /usr/local/bin/# 初始化Redis服务（生成默认配置文件和启动脚本）
cd /opt/redis-5.0.7/utils/
./install_server.sh  # 全程按提示回车，最后指定Redis可执行路径为 /usr/local/redis/bin/redis-server

1. 配置 Master 主节点（IP：192.168.100.129）

修改 Redis 主配置文件 /etc/redis/6379.conf：

bind 0.0.0.0                # 70行：监听所有网卡（允许跨机器访问）
daemonize yes               # 137行：开启守护进程（后台运行）
logfile /var/log/redis_6379.log  # 172行：指定日志文件路径
dir /var/lib/redis/6379     # 264行：指定数据存储目录
appendonly yes              # 700行：开启AOF持久化（避免RDB快照丢失数据）

启动主节点：

/etc/init.d/redis_6379 restart  # 重启服务（确保配置生效）

2. 配置 Replica 从节点（IP：192.168.100.140、192.168.100.150）

两个从节点配置相同，修改 /etc/redis/6379.conf：

bind 0.0.0.0                # 同主节点，监听所有网卡
daemonize yes
logfile /var/log/redis_6379.log
dir /var/lib/redis/6379
appendonly yes
replicaof 192.168.100.129 6379  # 288行：指定主节点IP和端口（Redis 5.0前用slaveof）

启动从节点：

/etc/init.d/redis_6379 restart

2.4 验证主从效果

1. 查看主节点复制状态：

# 在Master节点执行
redis-cli info replication# 预期输出（关键字段）
# Replication
role:master                # 角色为master
connected_slaves:2         # 已连接2个从节点
slave0:ip=192.168.100.140,port=6379,state=online,offset=xxx,lag=0  # 从节点1
slave1:ip=192.168.100.150,port=6379,state=online,offset=xxx,lag=0  # 从节点2

2. 验证数据同步：

# 在Master节点写入数据
redis-cli set username "zhangsan"# 在任一Replica节点读取数据（从节点默认只读，无法写入）
redis-cli get username  # 预期输出 "zhangsan"，说明数据同步成功

三、模式二：哨兵模式（Sentinel）

主从复制的缺陷是“主节点故障需手动切换”，哨兵模式通过哨兵集群（≥3个节点） 实现主节点的自动故障检测与转移，本质是“主从架构 + 哨兵监控”。

3.1 核心概念与作用

1. 角色定义

• 哨兵节点（Sentinel）：特殊的 Redis 节点（不存储数据），负责监控主从节点、发起故障转移、通知客户端新主节点地址。
• 数据节点：即原主从复制中的 Master 和 Replica 节点，负责存储数据。

2. 核心作用

• 监控：哨兵每秒向主从节点、其他哨兵发送 PING 命令，检测节点存活状态。
• 自动故障转移：主节点故障时，哨兵集群协商选举新主节点，并将所有从节点切换为新主节点的从节点。
• 通知：故障转移完成后，哨兵通过“发布-订阅”机制（如 __sentinel__:hello 频道）通知客户端新主节点地址。

3.2 工作原理（故障转移流程）

1. 节点健康检测与下线判定

• 主观下线（SDOWN）：单个哨兵连续 down-after-milliseconds 时间（默认30秒）未收到主节点 PONG 响应，判定主节点“主观下线”（仅自身认为下线）。
• 客观下线（ODOWN）：当超过 quorum 个哨兵（如3个哨兵配置 quorum=2）均判定主节点“主观下线”，则标记主节点“客观下线”（集群共识，触发故障转移）。

2. 哨兵 leader 选举（Raft 算法）

• 客观下线后，哨兵集群通过 Raft 算法选举1个“leader 哨兵”，由其负责执行故障转移（避免多哨兵重复操作）。
• 选举规则：哨兵向其他节点发送 LEADER 投票请求，获得超过半数投票的哨兵成为 leader。

3. 故障转移执行（leader 哨兵负责）

1. 筛选候选从节点：排除“主观下线”、“复制偏移量过低（数据不完整）”、“优先级过低（replica-priority=0）”的从节点。
2. 选举新主节点：按优先级排序（replica-priority 数值越小优先级越高）→ 复制偏移量（越大越完整）→ 运行 ID（随机），选最优从节点升级为新主节点。
3. 切换从节点：向其他从节点发送 replicaof 新主节点IP:端口 命令，让其同步新主节点数据。
4. 原主节点处理：若原主节点恢复，哨兵将其设置为新主节点的从节点（避免原主节点抢占主角色）。

3.3 搭建步骤（1主2从+3哨兵）

环境前提

已完成“主从复制”搭建（Master：192.168.100.129；Replica：192.168.100.140、192.168.100.150），3个哨兵节点分别部署在主从节点机器上（或独立机器，此处复用主从机器）。

1. 配置所有哨兵节点（3个节点配置相同）

修改哨兵配置文件 /opt/redis-5.0.7/sentinel.conf（需先复制到所有节点）：

protected-mode no               # 17行：关闭保护模式（允许跨机器访问）
port 26379                      # 21行：哨兵默认监听端口（固定26379）
daemonize yes                   # 26行：开启守护进程
logfile "/var/log/sentinel.log" # 36行：指定哨兵日志路径
dir "/var/lib/redis/6379"       # 65行：指定哨兵工作目录
# 84行：监控主节点（mymaster为主节点名称，quorum=2表示需2个哨兵确认下线）
sentinel monitor mymaster 192.168.100.129 6379 2
# 113行：判定主节点下线的超时时间（30秒）
sentinel down-after-milliseconds mymaster 30000
# 146行：故障转移超时时间（180秒，超时则重新发起转移）
sentinel failover-timeout mymaster 180000

2. 启动哨兵集群（先启主从，再启哨兵）

# 在3个哨兵节点分别执行（后台启动哨兵）
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

3.4 验证与故障模拟

1. 查看哨兵状态

# 连接任一哨兵节点（端口26379）
redis-cli -p 26379 info Sentinel# 预期输出（关键字段）
# Sentinel
sentinel_masters:1
master0:name=mymaster,status=ok,address=192.168.100.129:6379,slaves=2,sentinels=3  # 3个哨兵正常监控

2. 故障模拟（手动杀死主节点）

# 在Master节点（192.168.100.129）杀死Redis进程
ps -ef | grep redis-server  # 查找主节点Redis进程ID（如57031）
kill -9 57031# 查看哨兵日志，确认故障转移过程
tail -f /var/log/sentinel.log# 关键日志（说明转移成功）
# +sdown master mymaster 192.168.100.129 6379  # 主节点主观下线
# +new-epoch 1  # 新的日志周期
# +vote-for-leader xxx  # 选举leader哨兵
# +switch-master mymaster 192.168.100.129 6379 192.168.100.150 6379  # 切换主节点为192.168.100.150
# +slave slave 192.168.100.140 6379 ...  # 其他从节点同步新主节点

3. 验证新主节点状态

# 再次查看哨兵信息，确认新主节点地址
redis-cli -p 26379 info Sentinel# 预期输出（主节点已切换）
master0:name=mymaster,status=ok,address=192.168.100.150:6379,slaves=2,sentinels=3

四、模式三：Cluster 集群（Redis Cluster）

哨兵模式仍存在“写操作集中在单个主节点、存储容量受单机限制”的问题，Cluster 集群通过数据分片（哈希槽） 实现“多主多从”，解决写负载均衡和存储扩展问题，是生产环境大规模部署的首选。

4.1 核心概念与作用

1. 核心特性

• 数据分片：Cluster 集群将数据分散到 16384 个“哈希槽”（编号 0-16383），每个主节点负责一部分哈希槽（如3主节点分别负责 0-5460、5461-10922、10923-16383）。
• 多主多从：推荐 3主3从架构（每个主节点1个从节点），主节点负责读写和哈希槽维护，从节点同步主节点数据，主节点故障时从节点自动升级为主节点。
• 自动故障转移：类似哨兵模式，主节点故障时，其从节点通过选举升级为主节点，确保集群可用性。

2. 数据分片原理

• 键映射规则：对键执行 CRC16(key) 计算，再对 16384 取余，得到该键所属的“哈希槽”，进而路由到负责该槽的主节点。
• 示例：key=username → CRC16(username)=5798 → 5798%16384=5798 → 路由到负责 5461-10922 槽的主节点。

4.2 搭建步骤（3主3从，单机模拟6节点）

环境准备

同“主从复制”的环境依赖（GCC、Redis 编译安装完成），此处用同一台机器的不同端口模拟6个节点（主：6001/6002/6003；从：6004/6005/6006）。

1. 创建节点目录与配置文件

# 创建6个节点的目录（存放配置、数据、日志）
mkdir -p /etc/redis/redis-cluster/redis600{1..6}# 复制Redis默认配置文件和执行文件到每个节点目录
for i in {1..6}; docp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i/cp /usr/local/redis/bin/redis-server /etc/redis/redis-cluster/redis600$i/cp /usr/local/redis/bin/redis-cli /etc/redis/redis-cluster/redis600$i/
done

2. 修改每个节点的配置文件（以6001为例，其他节点类推）

修改 /etc/redis/redis-cluster/redis6001/redis.conf：

bind 0.0.0.0                # 监听所有网卡
protected-mode no           # 关闭保护模式
port 6001                   # 节点端口（6001-6006，每个节点不同）
daemonize yes               # 后台运行
dir ./                      # 数据存储目录（当前节点目录）
appendonly yes              # 开启AOF持久化
cluster-enabled yes         # 832行：开启集群模式
cluster-config-file nodes-6001.conf  # 840行：集群配置文件（自动生成，记录槽分配、节点信息）
cluster-node-timeout 15000  # 846行：集群节点超时时间（15秒，超时判定节点下线）

其他节点仅需修改 port 和 cluster-config-file（如6002节点改为 port 6002、cluster-config-file nodes-6002.conf）。

3. 启动所有节点

# 批量启动6个节点
for i in {1..6}; docd /etc/redis/redis-cluster/redis600$i/./redis-server redis.conf
done# 验证节点启动状态（应看到6个redis-server进程）
ps -ef | grep redis-server

4. 初始化 Cluster 集群

通过 Redis 自带命令创建集群，指定“3主3从”（--cluster-replicas 1 表示每个主节点1个从节点）：

# 执行集群初始化命令（需确保所有节点已启动）
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# 交互提示：输入 yes 确认哈希槽分配（默认3主节点平分16384个槽）
# 预期输出：All 16384 slots covered.（所有槽已分配，集群创建成功）

4.3 验证集群状态

1. 查看集群节点信息

# 连接任一节点（加 -c 启用集群模式，支持自动路由）
redis-cli -p 6001 -c# 查看集群节点列表（包含主从角色、哈希槽范围）
127.0.0.1:6001> cluster nodes# 查看哈希槽分配情况
127.0.0.1:6001> cluster slots
# 预期输出（示例）：
# 1) 1) (integer) 5461  # 槽范围：5461-10922（主节点6003负责）
#    2) (integer) 10922
#    3) 1) "127.0.0.1"
#       2) (integer) 6003
#    4) 1) "127.0.0.1"  # 从节点6004（同步6003）
#       2) (integer) 6004

2. 验证数据分片与同步

# 在6001节点写入数据（自动路由到对应哈希槽的主节点）
127.0.0.1:6001> set username "zhangsan"
# 预期输出：-> Redirected to slot [5798] located at 127.0.0.1:6003（路由到6003节点）
# OK# 查看键的哈希槽
127.0.0.1:6003> cluster keyslot username  # 输出 5798（对应6003节点的槽范围）# 连接从节点6004（同步6003），验证数据同步
redis-cli -p 6004 -c
127.0.0.1:6004> get username  # 输出 "zhangsan"（数据同步成功）

五、三种模式对比与选型建议

维度	主从复制	哨兵模式	Cluster 集群
写负载均衡	❌（单主写入）	❌（单主写入）	✅（多主分片写入）
存储容量扩展	❌（单主存储限制）	❌（单主存储限制）	✅（多主分片扩展）
自动故障转移	❌（需手动切换）	✅（主节点自动转移）	✅（主节点自动转移）
部署复杂度	低	中（需维护哨兵集群）	高（需维护多主多从+槽）
适用场景	测试环境、读多写少的小规模场景	中小规模生产环境（需高可用，写量不大）	大规模生产环境（高并发读写、海量数据）

选型总结

1. 测试/小规模场景：优先主从复制（部署简单，满足基础冗余需求）。
2. 中小规模生产环境：选择哨兵模式（在主从基础上增加自动故障转移，保障高可用）。
3. 大规模/高并发场景：必须用 Cluster 集群（解决写负载和存储扩展问题，支持横向扩容）。