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

Redis三种集群模式

news 2025/9/21 9:50:30

深入理解Redis三种集群模式：原理、搭建与实践

在高并发、大数据量的业务场景中，单节点Redis面临着性能瓶颈、存储容量限制和单点故障等问题。为解决这些挑战，Redis提供了三种核心集群模式：主从复制、哨兵模式和Cluster集群。本文将从原理、作用、搭建步骤三个维度，全面解析这三种模式，帮助你根据业务需求选择合适的Redis集群方案。

一、Redis三种集群模式概述

Redis的三种集群模式并非孤立存在，而是逐步演进的关系：主从复制是基础，哨兵模式在主从复制之上实现了故障自动转移，Cluster集群则进一步解决了写负载均衡和存储容量限制问题。三者的核心差异如下表所示：

特性主从复制哨兵模式（Sentinel）Cluster集群
核心能力数据备份、读负载均衡主从故障自动转移、服务监控数据分片、写负载均衡、高可用
写操作负载均衡不支持（仅主节点写）不支持（仅主节点写）支持（多主节点分布式写入）
存储容量限制受单机内存限制受单机内存限制无（分布式存储）
故障恢复手动切换主节点自动选举新主节点自动故障转移（主从+哨兵逻辑）
适用场景读多写少、数据备份读多写少、需高可用（无扩容）高并发读写、大数据量存储

二、Redis主从复制：高可用的基石

主从复制是Redis集群的基础方案，通过将一台主节点（Master）的数据复制到多台从节点（Slave），实现数据冗余和读负载分担。数据复制是单向的，仅支持“主→从”同步。

2.1 主从复制的核心作用

  1. 数据冗余：从节点是主节点的实时备份，避免因单机故障导致数据丢失（配合持久化使用更可靠）。
  2. 故障恢复：主节点宕机后，可手动将从节点切换为主节点，减少服务中断时间。
  3. 负载均衡：主节点负责写操作，从节点负责读操作（如查询、统计），缓解主节点压力，提升并发能力。
  4. 高可用基石：哨兵模式和Cluster集群均基于主从复制实现，没有主从复制就无法构建更高级的集群。

2.2 主从复制的工作流程

主从复制的同步过程分为“全量复制”和“增量复制”，具体流程如下：

  1. 从节点发起同步请求：从节点启动后，向主节点发送SYNC命令，请求建立同步连接。
  2. 主节点生成数据快照：主节点收到请求后，启动后台进程执行RDB持久化，生成全量数据快照，并缓存此过程中所有写操作（避免数据不一致）。
  3. 全量数据同步：主节点将RDB快照发送给从节点，从节点接收后写入磁盘，再加载到内存中。
  4. 增量数据同步：全量同步完成后，主节点将后续的写操作（如SET、DEL）实时发送给从节点，保证主从数据一致。
  5. 断线重连：若从节点因网络故障断开连接，恢复后会自动重新发起同步（优先增量复制，仅当增量日志丢失时才触发全量复制）。

2.3 实战：搭建Redis主从复制

环境准备
  • 主节点（Master）：192.168.10.23（Redis端口6379）
  • 从节点（Slave）：192.168.10.14、192.168.10.15（Redis端口均为6379）
  • 所有节点关闭防火墙和SELinux：
    systemctl stop firewalld
setenforce 0
步骤1：安装Redis（所有节点）
# 安装依赖
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/# 编译安装
cd /opt/redis-5.0.7/
make && make PREFIX=/usr/local/redis install# 配置环境变量（方便命令调用）
ln -s /usr/local/redis/bin/* /usr/local/bin/# 初始化Redis服务
cd /opt/redis-5.0.7/utils/
./install_server.sh  # 按提示操作，默认端口6379
步骤2：配置主节点（192.168.10.23）

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

vim /etc/redis/6379.conf
# 核心配置项
bind 0.0.0.0          # 监听所有网卡（允许外部访问）
daemonize yes         # 后台运行
logfile /var/log/redis_6379.log  # 日志路径
dir /var/lib/redis/6379          # 数据存储路径
appendonly yes        # 开启AOF持久化（增强数据可靠性）# 重启Redis服务
/etc/init.d/redis_6379 restart
步骤3：配置从节点（192.168.10.14、192.168.10.15）

从节点配置与主节点基本一致，仅需增加“指定主节点”的配置：

vim /etc/redis/6379.conf
# 新增配置（指定主节点IP和端口）
replicaof 192.168.10.23 6379  # Redis 5.0+用replicaof，旧版本用slaveof# 重启Redis服务
/etc/init.d/redis_6379 restart
步骤4：验证主从效果

在主节点执行以下命令，查看从节点连接状态：

# 进入Redis客户端
redis-cli# 查看复制信息
127.0.0.1:6379> info replication
# 输出结果应包含以下内容（表示2个从节点已连接）
role:master
connected_slaves:2
slave0:ip=192.168.10.14,port=6379,state=online,offset=xxx,lag=0
slave1:ip=192.168.10.15,port=6379,state=online,offset=xxx,lag=0

此外，可在主节点执行SET key value，在从节点执行GET key，验证数据是否同步。

三、Redis哨兵模式：自动故障转移的实现

主从复制的缺陷是“故障恢复需手动操作”，而哨兵模式（Sentinel）通过引入“哨兵节点”，实现了主节点故障的自动检测和自动转移，进一步提升了Redis的高可用性。

3.1 哨兵模式的核心原理

哨兵模式由“哨兵节点”和“数据节点（主从节点）”组成：

  • 哨兵节点：特殊的Redis节点，不存储数据，仅负责监控、选举和通知。
  • 数据节点：即主从复制中的主节点和从节点，负责数据存储和读写。

哨兵模式的核心逻辑分为三步：

  1. 监控（Monitoring）：每个哨兵节点每隔1秒向主节点、从节点及其他哨兵节点发送PING命令，检测节点是否存活。
  2. 故障检测（Fault Detection）：
    • 若某节点超过down-after-milliseconds（默认30秒）未回复PING，哨兵标记该节点为“主观下线（SDOWN）”。
    • 当超过半数哨兵节点均标记主节点为“主观下线”，则主节点被标记为“客观下线（ODOWN）”，触发故障转移。
  3. 故障转移（Failover）：
    • 哨兵节点通过Raft算法选举出一个“哨兵 leader”，由其执行故障转移。
    • 哨兵 leader 从所有健康从节点中选择新主节点（优先级：replica-priority配置 → 复制偏移量 → 运行时间）。
    • 通知所有从节点同步新主节点，原主节点恢复后变为从节点。

3.2 哨兵模式的核心作用

  1. 自动故障转移：无需人工干预，主节点故障后快速切换新主节点，减少服务中断。
  2. 节点监控：实时监控主从节点和哨兵节点的健康状态。
  3. 通知机制：故障转移完成后，可通过脚本通知客户端（如短信、邮件）更新主节点地址。

3.3 实战：搭建Redis哨兵模式

环境准备

基于前文的主从复制环境（主192.168.10.23，从192.168.10.14/15），在所有节点部署哨兵。

步骤1：配置哨兵（所有节点）

修改哨兵配置文件/opt/redis-5.0.7/sentinel.conf：

vim /opt/redis-5.0.7/sentinel.conf
# 核心配置项
protected-mode no                # 关闭保护模式（允许外部访问）
port 26379                       # 哨兵默认端口
daemonize yes                    # 后台运行
logfile "/var/log/sentinel.log"  # 哨兵日志路径
dir "/var/lib/redis/6379"        # 工作目录
# 监控主节点（mymaster为集群名称，2表示需2个哨兵同意才判定主节点下线）
sentinel monitor mymaster 192.168.10.23 6379 2
# 判定主节点下线的超时时间（30秒）
sentinel down-after-milliseconds mymaster 30000
# 故障转移的超时时间（180秒）
sentinel failover-timeout mymaster 180000
步骤2：启动哨兵（所有节点）
# 进入Redis源码目录，启动哨兵（指定配置文件）
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &  # 后台运行
步骤3：验证哨兵效果

  1. 查看哨兵状态：

    redis-cli -p 26379 info Sentinel
# 输出结果应包含以下内容（表示监控1个主节点、2个从节点、3个哨兵）
sentinel_masters:1
master0:name=mymaster,status=ok,address=192.168.10.23:6379,slaves=2,sentinels=3

  2. 模拟主节点故障：
    在主节点（192.168.10.23）杀死Redis进程：

    ps -ef | grep redis-server  # 找到主节点Redis进程号
kill -9 进程号

  3. 验证故障转移：

    • 查看哨兵日志，确认新主节点选举结果：
      tail -f /var/log/sentinel.log
# 关键日志：+switch-master mymaster 192.168.10.23 6379 192.168.10.14 6379（表示192.168.10.14成为新主）
    • 再次查看哨兵状态，确认新主节点地址：
      redis-cli -p 26379 info Sentinel
# 输出应显示master0的address为新主节点IP和端口

四、Redis Cluster集群：分布式存储与高并发解决方案

哨兵模式虽解决了故障自动转移，但仍存在“写操作集中在单主节点”和“存储容量受单机限制”的问题。Redis Cluster（集群模式）通过数据分片和多主节点，彻底解决了这些痛点，是Redis应对高并发、大数据量的终极方案。

4.1 Cluster集群的核心原理

1. 数据分片：哈希槽（Hash Slot）

Redis Cluster将数据划分为16384个哈希槽（编号0-16383），每个主节点负责一部分哈希槽。数据存储时，通过以下算法确定槽位：

槽位 = CRC16(key) % 16384

客户端根据槽位自动路由到对应的主节点，实现分布式存储。

例如，3主3从的集群中，哈希槽分配可能如下：

  • 主节点1（6001）：0-5460
  • 主节点2（6002）：5461-10922
  • 主节点3（6003）：10923-16383
2. 高可用保障

每个主节点对应至少1个从节点，当主节点故障时，从节点自动升级为主节点（类似哨兵模式的故障转移），保证哈希槽不丢失，服务不中断。

4.2 Cluster集群的核心作用

  1. 写负载均衡：多主节点分布式写入，突破单主节点的写性能瓶颈。
  2. 无限存储容量：数据分片存储在多个节点，不受单机内存限制。
  3. 自动故障转移：主节点故障后，从节点自动接管，高可用性更强。
  4. 弹性扩容：支持动态添加/删除节点，无需停机（需重新分配哈希槽）。

4.3 实战：搭建Redis Cluster集群

环境准备

在单台服务器上模拟6个节点（3主3从），以端口区分：

  • 主节点：6001、6002、6003
  • 从节点：6004、6005、6006
步骤1：创建节点目录与配置文件
# 创建集群目录
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 /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i/
done
步骤2：配置每个节点（以6001为例，其他节点同理）

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

vim /etc/redis/redis-cluster/redis6001/redis.conf
# 核心配置项
bind 0.0.0.0                    # 监听所有网卡
protected-mode no               # 关闭保护模式
port 6001                       # 节点端口（6002-6006对应修改）
daemonize yes                   # 后台运行
cluster-enabled yes             # 开启集群模式
cluster-config-file nodes-6001.conf  # 集群配置文件（自动生成，需与端口一致）
cluster-node-timeout 15000      # 节点超时时间（15秒）
appendonly yes                  # 开启AOF持久化
logfile /var/log/redis6001.log  # 日志路径（6002-6006对应修改）
dir /var/lib/redis/6001         # 数据路径（6002-6006对应修改）
步骤3：启动所有节点
# 批量启动6个节点
for i in {1..6}; docd /etc/redis/redis-cluster/redis600$i/./redis-server redis.conf
done# 验证节点是否启动成功
ps -ef | grep redis-server  # 应显示6个redis-server进程
步骤4：创建Cluster集群

执行集群初始化命令，自动分配主从关系和哈希槽：

# --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确认集群创建，Redis会自动将前3个节点设为主节点，后3个设为从节点，并分配哈希槽。

步骤5：验证集群效果
  1. 查看集群状态：
    #
http://www.dtcms.com/a/392976.html

相关文章：

  • C++ map_set封装
  • NW836NW884美光固态闪存NW885NW913
  • STM32计算步进电机转速
  • liboffice 全屏禁用工具栏
  • Photoshop - Photoshop 调整图像品质
  • 【CF】Day146——杂题 (递归 | 规律与操作)
  • PyTorch 中特征变换：卷积与转置卷积
  • HashMap底层原理详解：扩容、红黑树与ConcurrentHashMap的线程安全
  • autodl文件存储，文件同步，conda环境同步问题
  • 【ROS2】Begginer : CLI tools - 理解 ROS 2 话题
  • Java网络编程：从基础到实战
  • 面试MYSQL的索引类型、索引的工作原理、以及索引优化策略
  • 一、Pytorch安装教程-windows环境，利用Anaconda搭建虚拟环境，Pycharm开发工具
  • JWT登录校验
  • 对症下药：电商、B2B、本地服务和内容媒体的GEO定制化策略
  • 分类预测 | Matlab实现GWO-BP灰狼算法优化BP神经网络多特征分类预测
  • pcl封装11 （快速定义）旋转矩阵
  • Windows 系统中如何通过 Docker 调用 CUDA 和 cuDNN 加速大模型推理
  • 从零编写vue3系统--5步教学
  • 嵌入式Linux C语言程序设计三
  • 【记录】初赛复习 Day5 6（2021S第一轮错题，内附深井题目讲解）
  • 【C++】类和对象—(下) 收官之战
  • 人工智能学习：什么是迁移学习
  • 模型进阶与神经网络
  • 微软.NET离线运行库合集 v2025.09.09_Win中文_NET运行库_安装教程
  • Galileo AI-AI驱动的UI界面设计工具
  • 布谷鸟布隆过滤器和计数式布隆过滤器和原始布隆过滤器相比分别解决了什么问题？
  • 大模型介绍
  • 基于Springboot的无人之境智能酒店服务平台
  • ICCV-2025 | 大模型驱动的认知导航框架！CogNav：面向目标导航的大型语言模型驱动的认知过程建模