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

---

在分布式系统中，Redis作为高性能的键值存储数据库，其高可用和扩展性至关重要。Redis提供了三种核心服务架构模式，分别是主从复制、哨兵模式和Cluster集群，它们各自解决不同场景下的问题。本文将详细解析这三种模式的原理、作用及搭建方法，帮助你根据业务需求选择合适的架构。

一、Redis三种模式概述

Redis的三种集群模式各有侧重，从基础的数据备份到自动化故障转移，再到分布式存储，逐步解决高可用和扩展性问题：

• 主从复制：最基础的集群模式，实现数据的多机备份和读操作负载均衡，但故障恢复需手动干预，且写操作无法负载均衡。
• 哨兵模式：基于主从复制，增加了自动化故障转移能力，解决主节点故障后的自动切换问题，但仍受限于单机存储容量和写操作瓶颈。
• Cluster集群：分布式存储方案，通过数据分片突破单机存储限制，同时支持写操作负载均衡和自动故障转移，是最完善的高可用方案。

二、Redis主从复制

主从复制是Redis高可用的基础，通过单向数据复制（主到从）实现数据冗余和读负载均衡。

2.1 主从复制的核心作用

1. 数据冗余：主节点数据实时复制到从节点，提供热备份，补充持久化的不足。
2. 故障恢复：主节点故障时，可手动将从节点切换为主节点，快速恢复服务。
3. 负载均衡：主节点负责写操作，从节点分担读操作，提升并发处理能力（尤其适合读多写少场景）。
4. 高可用基石：是哨兵模式和Cluster集群的基础，没有主从复制，后续高可用方案无从谈起。

2.2 主从复制流程

主从复制的工作流程可概括为“同步-增量复制”：

1. 从节点启动后，向主节点发送SYNC命令请求同步。
2. 主节点收到请求后，启动后台进程生成RDB快照，并缓存此过程中的所有写命令。
3. 主节点将RDB文件发送给从节点，从节点加载RDB到内存，完成初始化同步。
4. 主节点将缓存的写命令发送给从节点，从节点执行这些命令，实现数据一致性。
5. 后续主节点的写操作会实时同步到从节点（增量复制），若从节点宕机恢复后会自动重连并同步。

2.3 搭建主从复制（实战步骤）

环境准备

• 主节点（Master）：192.168.10.120
• 从节点（Slave1）：192.168.10.99
• 从节点（Slave2）：192.168.10.98
• 关闭防火墙和SELinux：

  systemctl stop firewalld
  setenforce 0
  

安装Redis（所有节点）

# 安装依赖
yum install -y gcc gcc-c++ make# 下载并解压Redis
wget -P /opt http://download.redis.io/releases/redis-5.0.7.tar.gz
tar zxvf /opt/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
# 执行时指定redis-server路径：/usr/local/redis/bin/redis-server# 建立软链接方便使用
ln -s /usr/local/redis/bin/* /usr/local/bin/

配置主节点（192.168.10.120）

vim /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持久化# 重启服务
/etc/init.d/redis_6379 restart

配置从节点（192.168.10.99和192.168.10.98）

vim /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持久化
# 除主节点的基础配置外，增加：
replicaof 192.168.10.23 6379  # 287行，指定主节点IP和端口# 重启服务
/etc/init.d/redis_6379 restart

验证主从关系

# 在主节点查看从节点状态
redis-cli info replication# 输出应包含类似内容：
# role:master
# connected_slaves:2
# slave0:ip=192.168.10.99,port=6379,state=online,...
# slave1:ip=192.168.10.98,port=6379,state=online,...

验证结果

redis-cli  #在主机上进入Redis
set yufei 1 #创建一个键值对
keys * 	#在从机上验证结果

创建键值对

从机验证结果

三、Redis哨兵模式

主从复制的缺陷是主节点故障后需手动切换，哨兵模式通过引入“哨兵节点”解决了这一问题，实现自动化故障转移。

3.1 哨兵模式的核心作用

1. 监控：哨兵节点定期向主从节点发送心跳（ping命令），检测节点是否存活。
2. 自动故障转移：主节点故障时，哨兵通过投票选举新主节点，并通知所有从节点切换复制目标。
3. 通知：将故障转移结果告知客户端，确保客户端连接新主节点。

3.2 哨兵模式原理

• 哨兵节点：特殊的Redis节点（不存储数据），通常部署3个及以上（避免脑裂）。
• 故障判定：
  • 主观下线：单个哨兵判定主节点无响应（超时未回复ping）。
  • 客观下线：超过半数哨兵认为主节点主观下线，则标记为客观下线。
• 故障转移：
  1. 哨兵通过Raft算法选举 Leader 哨兵，负责执行故障转移。
  2. Leader 从健康的从节点中选举新主节点（优先选优先级高、复制最完整的从节点）。
  3. 新主节点接管服务，原主节点恢复后变为从节点。

3.3 搭建哨兵模式（实战步骤）

环境准备

基于已搭建的主从复制环境（主192.168.10.120，从99、98）。

配置哨兵（所有节点）

vim /opt/redis-5.0.7/sentinel.conf
# 修改以下配置
protected-mode no                   # 关闭保护模式 17行
port 26379                          # 哨兵默认端口 21行
daemonize yes                       # 后台运行    26行
logfile "/var/log/sentinel.log"     # 日志路径 	 36行
dir "/var/lib/redis/6379"           # 工作目录    65行
# 监控主节点（mymaster为集群名，2表示至少2个哨兵同意判定故障）
sentinel monitor mymaster 192.168.10.120 6379 2   #84行
sentinel down-after-milliseconds mymaster 30000  # 30秒未响应判定为下线 113行
sentinel failover-timeout mymaster 180000        # 故障转移超时时间180秒         146行

启动哨兵（先启主节点，再启从节点）

cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &  # 后台启动

验证哨兵配置

# 查看哨兵信息
redis-cli -p 26379 info Sentinel# 输出应包含：
# master0:name=mymaster,status=ok,address=192.168.10.23:6379,slaves=2,sentinels=3

故障模拟与验证

# 在主节点杀死Redis进程
ps -ef | grep redis-server  # 找到主节点进程号
kill -9 [主节点进程号]# 查看哨兵日志，观察故障转移过程
tail -f /var/log/sentinel.log# 验证新主节点（应切换为98或99）
redis-cli -p 26379 info Sentinel

四、Redis Cluster集群

Cluster集群是Redis的分布式存储方案，通过数据分片解决单机存储限制，同时支持写负载均衡和自动故障转移。

4.1 Cluster集群的核心作用

1. 数据分区：将数据分散到多个主节点（通过哈希槽），突破单机内存限制，提升读写并发。
2. 高可用：每个主节点配备从节点，主节点故障时自动切换从节点为主节点。

4.2 数据分片：哈希槽机制

Redis Cluster将数据划分为16384个哈希槽（0-16383），每个主节点负责一部分槽：

• 键通过CRC16(key) % 16384计算所属槽，自动路由到对应主节点。
• 示例：3主节点时，可能A负责0-5460，B负责5461-10922，C负责10923-16383。

4.3 搭建Cluster集群（实战步骤）

环境准备

在单台服务器模拟6个节点（3主3从），端口6001-6006。

准备节点配置

# 创建节点目录
cd /etc/redis/
mkdir -p 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

配置节点（以6001为例，其他节点修改端口即可）

vim /etc/redis/redis-cluster/redis6001/redis.conf
# 修改以下配置
# bind 127.0.0.1                  # 注释，监听所有网卡
protected-mode no                # 关闭保护模式
port 6001                        # 节点端口
daemonize yes                    # 后台运行
cluster-enabled yes              # 开启集群
cluster-config-file nodes-6001.conf  # 集群配置文件
cluster-node-timeout 15000       # 节点超时时间15秒
appendonly yes                   # 开启AOF持久化

启动所有节点

for d in {1..6}; docd /etc/redis/redis-cluster/redis600$dredis-server redis.conf
done# 验证启动
ps -ef | grep redis-server

初始化集群

# 创建集群（--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确认

验证集群

# 连接任意节点（-c表示支持跨节点跳转）
redis-cli -p 6001 -c# 查看哈希槽分配
127.0.0.1:6001> cluster slots# 测试数据存储（会自动路由到对应槽的节点）
127.0.0.1:6001> set name zhangsan
-> Redirected to slot [5798] located at 127.0.0.1:6002
OK# 查看从节点数据（从节点会同步主节点数据）
redis-cli -p 6002 -c
127.0.0.1:6002> keys *
1) "name"

总结

• 主从复制：适合数据备份和读负载均衡，需手动处理故障，适合简单场景。
• 哨兵模式：在主从基础上实现自动故障转移，适合需要高可用但存储需求不高的场景。
• Cluster集群：适合大规模分布式场景，解决存储限制和写负载均衡，是生产环境的首选。

根据业务的可用性、扩展性需求，选择合适的Redis架构，才能充分发挥其高性能优势。