Redis数据库（三）—— 深入解析Redis三种高可用架构：主从复制、哨兵与集群模式

前言

Redis作为高性能的键值数据库，在现代应用中扮演着至关重要的角色。为了保证服务的高可用性与数据可靠性，Redis提供了多种集群架构方案。

本文将详细介绍Redis的三种核心集群模式：主从复制、哨兵模式与Cluster集群，包括其原理、优缺点及实战搭建过程，帮助开发者根据实际业务需求选择最适合的架构方案。

一、Redis三种集群模式概述

1.1 Redis集群的三种模式简介

Redis集群有三种主流部署模式，分别是主从同步/复制（Replication）、哨兵模式（Sentinel）和Cluster集群（Cluster）。每种模式都有其特定的应用场景和优缺点，下面将详细讲解这三种模式的工作机制及部署方法。

1.1.1 主从复制模式

主从复制是Redis高可用架构的基础，哨兵模式和Cluster集群都是在此基础上实现的高可用方案。主从复制主要实现了数据的多机备份、读操作的负载均衡和简单的故障恢复功能。

缺陷：

• 故障恢复无法自动化，需要人工干预
• 写操作无法实现负载均衡，只能由主节点处理
• 存储能力受单机内存限制

1.1.2 哨兵模式

在主从复制的基础上，哨兵模式增加了自动化的故障恢复能力，能够监控Redis节点的健康状况并在主节点故障时自动进行故障转移。

缺陷：

• 写操作仍然无法负载均衡
• 存储能力仍受单机限制
• 哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。

1.1.3 Cluster集群模式

通过Cluster集群，Redis解决了写操作无法负载均衡和存储能力受单机限制的问题，实现了较为完善的高可用方案，是真正意义上的分布式Redis解决方案。

二、Redis主从复制模式

2.1 主从复制概念解析

主从复制是指将一台Redis服务器（称为主节点/Master）的数据，复制到其他Redis服务器（称为从节点/Slave）的过程。数据复制是单向的，只能从主节点流向从节点。

默认情况下，每台Redis服务器都是主节点。一个主节点可以有多个从节点（也可以没有），但一个从节点只能有一个主节点。

2.2 主从复制的作用与价值

2.2.1 数据冗余

主从复制实现了数据的热备份，是除了持久化之外的一种重要数据冗余方式，提高了数据的安全性。

2.2.2 故障恢复

当主节点出现故障时，可以从节点提供服务，实现快速故障恢复，提高了服务的可用性。

2.2.3 负载均衡（读写分离）

在主从复制的基础上，配合读写分离策略，可以由主节点处理写服务，从节点处理读服务，有效分担服务器负载。特别是在读多写少的场景下，通过多个从节点分担读负载，可以显著提高Redis服务器的并发处理能力。

2.2.4 高可用基石

主从复制不仅是数据冗余和负载均衡的基础，更是哨兵模式和Cluster集群能够实施的前提，因此被认为是Redis高可用架构的基石。

2.3 主从复制工作流程（重点）

主从复制的工作流程如下：

1. 同步请求：当启动一个Slave进程时，它会向Master发送一个"sync command"命令，请求建立同步连接
2. 数据快照：无论是首次连接还是重新连接，Master都会启动后台进程，执行RDB操作将数据快照保存到数据文件中，同时记录修改数据的所有命令并缓存
3. 数据同步：后台进程完成缓存操作后，Master会向Slave发送数据文件，Slave将数据文件保存到硬盘并加载到内存中
4. 命令传播：Master将修改数据的所有操作命令发送给Slave端（以AOF的方式）
5. 重连机制：如果Slave因故障宕机，恢复正常后会自动重新连接并同步数据
6. 多Slave处理：当Master同时收到多个Slave的同步请求时，会在后台启动一个进程保存数据文件，然后发送给所有Slave，确保所有从节点数据一致

2.4 Redis主从复制搭建实战

2.4.1 环境准备

• Master节点：192.168.10.110
• Slave1节点：192.168.10.120
• Slave2节点：192.168.10.123

系统配置：

systemctl stop firewalld
setenforce 0

2.4.2 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
# 注意：当提示选择redis可执行文件路径时，指定为/usr/local/redis/bin/redis-server# 创建软链接
ln -s /usr/local/redis/bin/* /usr/local/bin/

2.4.3 Master节点配置

vim /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

2.4.4 Slave节点配置

vim /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行，指定工作目录
replicaof 192.168.10.110 6379       # 288行，指定要同步的Master节点IP和端口
appendonly yes                     # 700行，开启AOF持久化功能# 重启服务
/etc/init.d/redis_6379 restart

2.4.5 验证主从效果

在Master节点查看日志：

tail -f /var/log/redis_6379.log 
# 应看到类似以下内容：
# Replica 192.168.10.120:6379 asks for synchronization
# Replica 192.168.10.123:6379 asks for synchronization

在Master节点验证从节点状态：

redis-cli info replication# 输出示例：
# Replication
# role:master
# connected_slaves:2
# slave0:ip=192.168.10.120,port=6379,state=online,offset=1246,lag=0
# slave1:ip=192.168.10.123,port=6379,state=online,offset=1246,lag=1

在Master节点插入一条数据验证结果：

# 在Master节点插入一条数据
set master 192.168.10.110
# 在slave节点查看数据
get master

三、Redis哨兵模式

3.1 哨兵模式概述

在主从复制模式下，当主节点宕机后，需要手动将一台从节点升级为主节点，这个过程需要人工干预，既费时费力又会造成服务一段时间不可用。为了解决这个问题，Redis引入了哨兵机制。

哨兵的核心功能是在主从复制的基础上，实现了主节点的自动故障转移，大大提高了系统的可用性。

3.2 哨兵模式工作原理

哨兵(Sentinel)是一个分布式系统，用于监控主从结构中的每台服务器，并在出现故障时通过投票机制选择新的Master，将所有Slave连接到新的Master。为了保证投票机制的可靠性，整个运行哨兵的集群数量不得少于3个节点。

3.3 哨兵模式的主要功能

3.3.1 监控

哨兵会定期检查主节点和从节点是否正常运行，确保系统状态的实时感知。

3.3.2 自动故障转移

当主节点不能正常工作时，哨兵会自动启动故障转移操作，将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

3.3.3 通知提醒

哨兵可以将故障转移的结果发送给客户端，使客户端能够及时感知到集群状态的变化。

3.4 哨兵系统组成

哨兵结构由两部分组成：

3.4.1 哨兵节点

哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据，只负责监控和故障转移。

3.4.2 数据节点

主节点和从节点都是数据节点，负责实际的数据存储和读写操作。

3.5 故障转移机制详解

3.5.1 主观下线与客观下线

• 主观下线：每个哨兵节点每隔1秒会向所有节点发送ping命令做心跳检测。如果主节点在一定时间内不响应或响应错误，哨兵会认为该主节点主观下线
• 客观下线：当超过半数的哨兵节点认为主节点主观下线时，该主节点就会被标记为客观下线

3.5.2 选举领导者

当主节点客观下线后，哨兵节点会通过Raft算法选举出一个leader哨兵节点，由它负责执行故障转移操作。

3.5.3 执行故障转移

领导者哨兵执行故障转移的过程：

1. 将一个从节点升级为新的主节点
2. 让其他从节点指向新的主节点
3. 通知客户端主节点已经更换
4. 如果原主节点恢复，将其变为从节点并指向新的主节点

注意：客观下线是主节点才有的概念。从节点和哨兵节点发生故障时，被主观下线后不会再有客观下线和故障转移操作。

3.6 主节点选举策略

当需要选举新的主节点时，哨兵会按照以下策略选择：

1. 过滤掉不健康的（已下线的）、没有回复哨兵ping响应的从节点
2. 选择配置文件中优先级最高（replica-priority配置值，默认100）的从节点
3. 选择复制偏移量最大（数据复制最完整）的从节点

注意：哨兵的启动依赖于主从模式

3.7 Redis哨兵模式搭建实战

3.7.1 环境准备

• Master节点：192.168.10.110
• Slave1节点：192.168.10.120
• Slave2节点：192.168.10.123

systemctl stop firewalld
setenforce 0

3.7.2 配置哨兵模式（所有节点操作）

vim /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.10.110 6379 2   # 84行，指定监控的主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000  # 113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000        # 146行，故障节点的最大超时时间（180秒）

3.7.3 启动哨兵模式

注意：先启动master，再启动slave

cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

3.7.4 查看哨兵信息

redis-cli -p 26379 info Sentinel# 输出示例：
# Sentinel
# sentinel_masters:1
# sentinel_tilt:0
# sentinel_running_scripts:0
# sentinel_scripts_queue_length:0
# sentinel_simulate_failure_flags:0
# master0:name=mymaster,status=ok,address=192.168.10.110:6379,slaves=2,sentinels=3

3.7.5 故障模拟测试

# 查看redis-server进程号
ps -ef | grep redis# 杀死Master节点上redis-server的进程
kill -9 $(cat /var/run/redis_6379.pid)# 查看哨兵日志，观察故障转移过程
tail -f /var/log/sentinel.log# 验证master是否被切换
redis-cli -p 26379 INFO Sentinel

四、Redis Cluster集群模式

4.1 Cluster集群概述

Redis Cluster是Redis 3.0开始引入的分布式存储方案，是真正意义上的分布式Redis实现。集群由多个节点(Node)组成，数据分布在这些节点中。

集群中的节点分为主节点和从节点：

• 主节点：负责处理读写请求和集群信息维护
• 从节点：负责复制主节点数据和状态信息和处理读请求

4.2 Cluster集群的核心价值

4.2.1 数据分区

数据分区（数据分片）是集群最核心的功能：

• 突破了Redis单机内存大小的限制，存储容量大大增加
• 每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力
• 解决了单机内存大小受限问题。例如：
  • bgsave和bgrewriteaof的fork操作可能导致的主进程阻塞问题
  • 主从环境下主机切换时可能导致从节点长时间无法提供服务
  • 全量复制阶段主节点的复制缓冲区可能溢出。

4.2.2 高可用性

集群支持主从复制和主节点的自动故障转移（与哨兵类似），当任一节点发生故障时，集群仍然可以对外提供服务，保证了系统的高可用性。

4.3 Redis集群的数据分片机制（重点）

Redis集群引入了哈希槽的概念：

• Redis集群有16384个哈希槽（编号0-16383）
• 每个哈希槽512字节
• 集群的每个节点负责一部分哈希槽
• 每个Key通过CRC16校验后对16384取余来决定放置哪个哈希槽，通过这个值找到对应的节点，然后自动跳转到对应节点进行存取操作

4.3.1 哈希槽分配示例

以3个节点组成的集群为例：

• 节点A包含0到5460号哈希槽
• 节点B包含5461到10922号哈希槽
• 节点C包含10923到16383号哈希槽

4.3.2 Redis集群的主从复制模型

假设集群中有A、B、C三个主节点，如果节点B失败，整个集群会因缺少5461-10922范围的槽而不可用。

为每个节点添加一个从节点A1、B1、C1后，集群由三个主节点和三个从节点组成。当节点B失败后，集群会选举B1为新的主节点继续服务。只有当B和B1都失败时，集群才不可用。

4.4 Redis Cluster集群搭建实战

4.4.1 环境准备

Redis集群一般需要6个节点，3主3从。为方便演示，在同一台服务器上使用不同端口模拟：

• 3个主节点端口：6001、6002、6003
• 3个从节点端口：6004、6005、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

4.4.2 配置集群节点

以redis6001为例，其他节点配置类似（注意修改端口号）：

vim /etc/redis/redis-cluster/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                     # 699行，开启AOF持久化

4.4.3 启动所有节点

for d in {1..6}
docd /etc/redis/redis-cluster/redis600$dredis-server redis.conf
done# 检查进程
ps -ef | grep redis

4.4.4 创建集群

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 才可以创建。
# --cluster-replicas 1 表示每个主节点有1个从节点
# 根据提示输入yes完成创建

4.4.5 测试集群

# 连接集群，-c参数允许节点间跳转
redis-cli -p 6001 -c# 查看节点的哈希槽编号范围
127.0.0.1:6001> cluster slots

# 设置数据测试
127.0.0.1:6001> set name zhangsan# 查看key的槽编号
127.0.0.1:6001> cluster keyslot name

# 在从节点上查看数据
redis-cli -p 6004 -c
127.0.0.1:6005> keys *

# 插入100条数据，在不同的主库上查看数据，看数据是否是分布式存储
for i in {1..100}; do redis-cli -p 6001 -c SET "key:$i" "value-$i"; done127.0.0.1:6001> DBSIZE
(integer) 33
127.0.0.1:6001> keys *
127.0.0.1:6002> DBSIZE
(integer) 30
127.0.0.1:6002> keys *
127.0.0.1:6003> DBSIZE
(integer) 37
127.0.0.1:6003> keys *

4.4.6 故障模拟测试

# 查看进程号
ps -ef | grep redis# 杀死端口6001的主库进程
kill -9 7009

# 查看节点的哈希槽编号范围
CLUSTER SLOTS

# 重新启动6001
/etc/redis/redis-cluster/redis6001
redis-server redis.conf
CLUSTER SLOTS

---

总结

Redis三种集群模式各有特点，适用于不同的业务场景：

1. 主从复制模式：redis 主从复制是一种数据同步机制，主服务器数据的修改会实时同步到从服务器上，实现数据备份和读写分离

2. 哨兵模式：redis哨兵是一个用于管理多个redis服务器的系统，它提供了监控、通知、自动故障迁移和配置提供的功能点，以实现redis高可用性

3. Cluster集群模式：Cluster集群是一个提供高性能 、高可用 、数据分片和故障转移特性的一个分布式数据库解决方案，但不支持多键操作和键的重命名。

在实际项目中，应根据业务需求、数据规模、性能要求和运维成本等因素综合考虑，选择最适合的Redis集群方案。对于大多数企业级应用，Redis Cluster集群模式是目前最为推荐的选择，它既能满足大数据量的存储需求，又能提供高性能和高可用性的保证。