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

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

news 2025/9/22 6:43:51

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

    • 一、Redis 主从复制：数据冗余与读写分离的基石
      • 1.1 主从复制的核心作用
      • 1.2 主从复制的工作流程
      • 1.3 主从复制的搭建步骤（Linux 环境）
        • 环境准备
        • 步骤1：所有节点安装 Redis
        • 步骤2：配置主节点（Master）
        • 步骤3：配置从节点（Slave1/Slave2）
        • 步骤4：验证主从效果
    • 二、Redis 哨兵模式：主从自动故障转移的解决方案
      • 2.1 哨兵模式的核心概念
      • 2.2 哨兵模式的核心作用
      • 2.3 哨兵模式的搭建步骤（基于主从复制）
        • 环境准备
        • 步骤1：修改哨兵配置文件（所有节点）
        • 步骤2：启动哨兵节点
        • 步骤3：验证哨兵模式
    • 三、Redis 集群模式：数据分片与水平扩展的终极方案
      • 3.1 集群模式的核心概念
      • 3.2 集群模式的核心作用
      • 3.3 集群模式的搭建步骤（单机模拟 6 节点：3 主 3 从）
        • 环境准备
        • 步骤1：创建节点目录与配置文件
        • 步骤2：启动所有节点
        • 步骤3：创建 Redis 集群
        • 步骤4：验证集群模式
    • 四、总结
  • Redis 三大核心架构总结
      • 一、架构定位与核心价值
      • 二、核心机制对比
      • 三、适用场景与选型建议
      • 四、架构演进逻辑

在高并发、大数据量的业务场景中，单一 Redis 实例往往无法满足可用性、扩展性和性能需求。Redis 提供了三种核心服务架构——主从复制、哨兵模式和集群模式，分别解决了数据冗余、自动故障转移和数据分片的问题。本文将从原理、作用、搭建步骤三个维度，详细解析这三种架构，帮助开发者理解并落地 Redis 高可用方案。

一、Redis 主从复制：数据冗余与读写分离的基石

主从复制是 Redis 高可用架构的基础，其核心是将主节点（Master）的数据单向复制到从节点（Slave），实现数据冗余和读写分离。默认情况下，每台 Redis 都是主节点，一个主节点可对应多个从节点，但一个从节点只能关联一个主节点。

1.1 主从复制的核心作用

主从复制通过“一主多从”的架构，解决了单一实例的三大痛点：

  • 数据冗余：实现数据热备份，是 RDB/AOF 持久化之外的额外冗余保障，避免单点数据丢失。
  • 故障恢复：主节点故障时，从节点可临时提供读服务，减少业务中断时间（需手动切换主从）。
  • 负载均衡：配合“主写从读”策略，主节点承担写操作，从节点分担读请求（如查询、统计），提升并发能力（尤其适合写少读多场景）。
  • 高可用基石：是哨兵模式和集群模式的基础，没有主从复制，后续架构无法落地。

1.2 主从复制的工作流程

主从复制的核心是“全量同步+增量同步”，具体流程如下：

  1. 从节点发起同步：从节点启动后，向主节点发送 SYNC 命令，请求建立同步连接。
  2. 主节点生成全量数据快照：主节点收到请求后，启动后台进程生成 RDB 快照文件，并缓存此过程中所有写操作（避免数据不一致）。
  3. 全量数据同步：主节点将 RDB 文件发送给从节点，从节点接收后先写入本地磁盘，再加载到内存，完成初始数据同步。
  4. 增量数据同步：全量同步完成后，主节点将后续所有写操作（如 SET、DEL）实时发送给从节点，从节点执行相同操作，保持数据与主节点一致。
  5. 断连重连：若从节点因故障宕机，恢复后会自动重新连接主节点，主节点仅需同步断连期间的增量数据（无需再次全量同步）。

注意：若多个从节点同时请求同步，主节点会只生成一份 RDB 文件，分发给所有从节点，避免重复消耗资源。

1.3 主从复制的搭建步骤（Linux 环境）

环境准备
  • 主节点（Master）：IP 192.168.10.23，端口 6379
  • 从节点（Slave1/Slave2）：IP 分别为 192.168.10.14、192.168.10.15，端口均为 6379
  • 所有节点关闭防火墙和 SELinux：
    systemctl stop firewalld
setenforce 0
步骤1：所有节点安装 Redis
  1. 安装依赖并下载 Redis 源码（以 Redis 5.0.7 为例）：
    yum install -y gcc gcc-c++ make
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/
  2. 编译安装并配置环境变量：
    cd /opt/redis-5.0.7/
make && make PREFIX=/usr/local/redis install
# 执行安装脚本，指定 Redis 可执行文件路径
cd /opt/redis-5.0.7/utils
./install_server.sh
# 交互时输入：/usr/local/redis/bin/redis-server（指定 Redis 服务路径）
# 建立软链接，方便命令调用
ln -s /usr/local/redis/bin/* /usr/local/bin/
步骤2：配置主节点（Master）

修改 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 持久化（可选，增强数据安全性）

重启主节点服务：

/etc/init.d/redis_6379 restart
步骤3：配置从节点（Slave1/Slave2）

从节点配置与主节点基本一致，仅需额外添加“关联主节点”的配置：

vim /etc/redis/6379.conf
# 复制主节点的基础配置（bind、daemonize 等），再添加：
replicaof 192.168.10.23 6379  # 关联主节点的 IP 和端口

重启从节点服务：

/etc/init.d/redis_6379 restart
步骤4：验证主从效果
  1. 在主节点查看从节点连接状态：
    redis-cli info replication
# 关键输出（表示 2 个从节点已连接）
role:master
connected_slaves:2
slave0:ip=192.168.10.14,port=6379,state=online,offset=1246,lag=0
slave1:ip=192.168.10.15,port=6379,state=online,offset=1246,lag=1
  2. 测试数据同步：
    • 主节点执行 set key1 value1，从节点执行 get key1，若返回 value1，则同步成功。
    • 从节点默认只读（replica-read-only yes），执行写操作会报错，确保“主写从读”策略生效。

二、Redis 哨兵模式：主从自动故障转移的解决方案

主从复制的痛点是“主节点故障后需手动切换”，而哨兵模式（Sentinel）通过分布式监控+自动故障转移，解决了这一问题，实现 Redis 高可用的自动化。

2.1 哨兵模式的核心概念

  • 哨兵节点（Sentinel）：特殊的 Redis 节点，不存储数据，仅负责监控主从节点、判断故障、选举新主节点。
  • 数据节点：即主节点（Master）和从节点（Slave），负责存储数据。
  • 故障判定：分为“主观下线（SDOWN）”和“客观下线（ODOWN）”：
    • 主观下线：单个哨兵节点 ping 主节点超时（默认 30 秒），认为主节点“可能故障”。
    • 客观下线：超过半数哨兵节点（如 3 个哨兵中至少 2 个）认为主节点主观下线，确认主节点“确实故障”。
  • 选举机制：主节点客观下线后，哨兵节点通过 Raft 算法选举出一个“哨兵leader”，由其执行故障转移。

2.2 哨兵模式的核心作用

  • 监控：实时检测主从节点和其他哨兵节点的健康状态。
  • 自动故障转移：主节点故障后，自动将一个从节点升级为新主节点，并让其他从节点关联新主节点，原主节点恢复后变为从节点。
  • 通知：将故障转移结果（如新主节点地址）通知给客户端，确保客户端正常访问。

2.3 哨兵模式的搭建步骤（基于主从复制）

环境准备
  • 基于前文的主从架构（Master：192.168.10.23；Slave1：192.168.10.14；Slave2：192.168.10.15）。
  • 所有节点均需部署哨兵（建议至少 3 个哨兵节点，避免单点故障）。
步骤1：修改哨兵配置文件（所有节点）

哨兵配置文件位于 Redis 源码目录下（/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"        # 工作目录（与 Redis 数据节点一致）
# 监控主节点：mymaster（主节点名称，自定义）、主节点 IP:端口、故障判定所需最小哨兵数（2）
sentinel monitor mymaster 192.168.10.23 6379 2
sentinel down-after-milliseconds mymaster 30000  # 30 秒未响应则主观下线
sentinel failover-timeout mymaster 180000        # 故障转移超时时间（180 秒）
步骤2：启动哨兵节点

先启动主节点，再启动从节点，最后启动所有哨兵节点：

# 所有节点执行（启动哨兵）
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-server 进程号
kill -9 进程号
    • 查看哨兵日志，确认故障转移：
      tail -f /var/log/sentinel.log
# 关键日志（表示主节点切换为 192.168.10.15）
+switch-master mymaster 192.168.10.23 6379 192.168.10.15 6379
    • 再次查看哨兵状态，确认新主节点：
      redis-cli -p 26379 info Sentinel
# 输出中 address 变为新主节点 IP:端口
master0:name=mymaster,status=ok,address=192.168.10.15:6379,slaves=2,sentinels=3

三、Redis 集群模式：数据分片与水平扩展的终极方案

主从复制和哨兵模式虽解决了高可用，但仍存在“单机内存上限”的问题——所有节点存储全量数据，无法突破单节点的内存限制。Redis 集群模式（Redis Cluster）通过数据分片（哈希槽），将数据分散到多个主节点，实现水平扩展，同时支持主从复制和自动故障转移。

3.1 集群模式的核心概念

  • 节点角色：集群包含主节点（Master）和从节点（Slave），仅主节点负责读写和哈希槽维护，从节点仅复制主节点数据。
  • 哈希槽（Hash Slot）：Redis 集群将数据划分为 16384 个哈希槽（编号 0-16383），每个主节点负责一部分哈希槽。
    • 数据定位规则：对 Key 执行 CRC16(Key) % 16384 计算，得到哈希槽编号，再将数据存储到负责该槽的主节点。
    • 示例（3 主 3 从集群）：
      • 主节点 1：负责 0-5460 号槽
      • 主节点 2：负责 5461-10922 号槽
      • 主节点 3：负责 10923-16383 号槽
  • 高可用保障：每个主节点至少关联一个从节点，若主节点故障，从节点自动升级为新主节点，确保哈希槽不缺失。

3.2 集群模式的核心作用

  • 数据分片：突破单机内存限制，支持海量数据存储（如 3 主节点可存储 3 倍于单节点的 data）。
  • 水平扩展：新增主节点时，可重新分配哈希槽，无需停机扩容。
  • 高可用：自带主从复制和自动故障转移，无需依赖哨兵。

3.3 集群模式的搭建步骤（单机模拟 6 节点：3 主 3 从）

环境准备
  • 单机模拟 6 个 Redis 节点，端口分别为：
    • 主节点：6001、6002、6003
    • 从节点：6004、6005、6006
  • 关闭防火墙和 SELinux（同前文）。
步骤1：创建节点目录与配置文件
  1. 创建 6 个节点的目录，并复制 Redis 可执行文件：
    cd /etc/redis/
mkdir -p redis-cluster/redis600{1..6}  # 创建 6 个目录
# 复制 Redis 配置文件和可执行文件到每个目录
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
  2. 修改每个节点的配置文件（以 6001 为例，其他节点仅需修改端口）：
    cd /etc/redis/redis-cluster/redis6001
vim redis.conf
# 关键配置项
# bind 127.0.0.1              # 注释掉，监听所有网卡
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 持久化
步骤2：启动所有节点
# 批量启动 6 个节点
for d in {1..6}; docd /etc/redis/redis-cluster/redis600$dredis-server redis.conf
done
# 验证节点是否启动成功
ps -ef | grep redis-server  # 应看到 6 个 redis-server 进程
步骤3：创建 Redis 集群

执行集群创建命令，指定 6 个节点，并设置“每个主节点 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 个设为从节点）。
步骤4：验证集群模式
  1. 连接集群节点（需加 -c 参数，支持节点间自动跳转）：
    redis-cli -p 6001 -c
  2. 查看哈希槽分配：
    127.0.0.1:6001> cluster slots
# 输出示例（6001 负责 0

四、总结

Redis 三大核心架构总结

Redis 主从复制、哨兵模式与集群模式，是逐步解决单机 Redis 性能瓶颈、可用性风险和存储上限问题的递进式方案。三者各有定位，又可层层衔接，共同支撑 Redis 在高并发、大数据场景下的稳定运行，其核心逻辑与适用场景可总结如下：

一、架构定位与核心价值

三种架构的设计目标各有侧重，分别对应 Redis 不同阶段的需求痛点：

架构类型核心目标解决的核心问题关键优势局限性
主从复制数据冗余 + 读写分离单机数据丢失风险、读请求并发瓶颈部署简单、支持“主写从读”分担读压力、数据热备份主节点故障需手动切换、无法突破单机存储上限
哨兵模式自动故障转移主从复制的“手动切换”痛点，提升高可用自动化程度无需人工干预、实时监控节点健康、通知故障结果仍未解决单机存储上限，所有节点存全量数据
集群模式数据分片 + 水平扩展哨兵模式的存储瓶颈，支持海量数据与弹性扩容突破单机内存限制、支持动态扩缩容、自带高可用部署复杂度高、需维护多节点哈希槽一致性

二、核心机制对比

三者在数据同步、故障处理、资源分配上的核心逻辑差异，决定了其适用场景：

  1. 数据同步机制

    • 主从复制：主节点通过“全量同步（RDB快照）+ 增量同步（写命令缓存）”，将数据单向复制到从节点；
    • 哨兵模式：基于主从复制的同步逻辑，仅新增“哨兵监控主从数据一致性”的校验；
    • 集群模式：主节点仅存储部分哈希槽数据，从节点复制对应主节点的槽数据，同步范围限于“单个主从组”。

  2. 故障处理逻辑

    • 主从复制：主节点故障后，从节点仅能提供读服务，需人工将从节点切换为主节点；
    • 哨兵模式：通过“主观下线（单哨兵判定）→ 客观下线（多哨兵投票）→ Raft选举哨兵Leader → 故障转移”，自动将从节点升级为主节点；
    • 集群模式：无需哨兵，主节点故障后，其从节点通过“投票选举”直接升级为主节点，同时更新集群哈希槽映射。

  3. 资源分配规则

    • 主从复制：1主多从，所有节点存储全量数据，资源利用率低；
    • 哨兵模式：1主多从 + N个哨兵节点（至少3个），哨兵节点不存数据，仅消耗少量监控资源；
    • 集群模式：3主3从（最小高可用单元），每个主节点负责16384个哈希槽的一部分，资源按需分配，利用率高。

三、适用场景与选型建议

  1. 主从复制：适合“读多写少、数据量不大、可接受短暂人工干预”的场景，如中小规模业务的缓存服务（如电商商品详情页缓存）。
  2. 哨兵模式：适合“读多写少、数据量不大、需高可用自动化”的场景，如支付系统的交易缓存（需避免人工切换导致的服务中断）。
  3. 集群模式：适合“数据量大（超单机内存）、高并发读写、需弹性扩容”的场景，如社交平台的用户关系数据、大数据平台的实时缓存。

四、架构演进逻辑

从“主从复制”到“哨兵模式”再到“集群模式”，是 Redis 从“基础可用”到“高可用自动化”再到“海量扩展”的演进路径，实际落地中需根据业务规模逐步升级：

  • 初期（业务冷启动）：单机 Redis → 主从复制（解决数据冗余）；
  • 中期（业务增长）：主从复制 → 哨兵模式（解决自动高可用）；
  • 后期（规模爆发）：哨兵模式 → 集群模式（解决存储与扩容）。

简言之，三种架构并非互斥，而是 Redis 应对不同业务阶段的“阶梯式解决方案”，需结合数据量、并发量、可用性要求综合选型。

http://www.dtcms.com/a/393454.html

相关文章：

  • Redis 三种服务架构详解：主从复制、哨兵模式与集群
  • 速通ACM省铜第十一天 赋源码（Gellyfish and Flaming Peony）
  • JAVA八股文——JAVA堆
  • Spark专题-第二部分：Spark SQL 入门（7）-算子介绍-Windows
  • JavaScript 闭包(Closure)深度讲解
  • QT与Spring Boot通信：实现HTTP请求的完整指南
  • 服务器ubuntu 22.04装nvidia驱动
  • nginx流量复制
  • spring-ai-alibaba-nl2sql 学习（五）——python 分析
  • 分布式链路追踪关键指标实战：精准定位服务调用 “慢节点” 全指南（三）
  • SimpleVLA-RL：通过 RL 实现 VLA 训练的 Scaling
  • Java 大视界 -- 基于 Java 的大数据可视化在企业供应链动态监控与优化中的应用
  • 《Linux 进程控制完全指南》
  • GitHub 热榜项目 - 日榜(2025-09-21)
  • 鹿鼎记豪侠传：Rust 重塑 iOS 江湖（上）
  • echarts监听dataZoom拖动缩放事件
  • Chrome学习小记3：基于Chrome Views框架创建最小示例窗口A（从Example分析开始）
  • Chrome学习小记2：GN构建系统小记
  • Chrome性能优化指南大纲
  • 【iOS】AFNetworking学习
  • Kafka 分层存储（Tiered Storage）原理、配置、快速上手与生产落地
  • 多元函数微分学核心概念辨析：连续、偏导与可微
  • 9.21 快选|倍增|栈+贡献法
  • AI.工作助手.工作提效率.AI应用开发平台
  • 【名人简历】鲁迅
  • linux文件系统基本管理
  • 2.1 进程与线程 (答案见原书 P57)
  • SDL2 开发详解
  • c++ 深拷贝之 std::string 与 char*
  • [数理逻辑] 决定性公理与勒贝格可测性(II) 一维情况