Redis 三种服务架构详解:从主从复制到集群模式
Redis 三种服务架构详解:从主从复制到集群模式
文章目录
- Redis 三种服务架构详解:从主从复制到集群模式
- 一、Redis 三种架构模式概述
- 二、主从复制:高可用的基石
- 核心作用
- 工作流程
- 搭建步骤(示例)
- 三、哨兵模式:自动化故障转移
- 核心功能
- 故障转移流程
- 搭建步骤(基于主从架构)
- 四、Cluster 集群:突破单机限制
- 核心特性
- 哈希槽分配示例
- 搭建步骤(6 节点:3 主 3 从)
- 五、架构选择建议
在分布式系统中,Redis 作为高性能的键值存储数据库,其高可用性和扩展性至关重要。本文将详细介绍Redis 的三种种种服务架构:主从复制、哨兵模式和 Cluster 集群,深入解析它们的工作原理、搭建方法及适用场景,帮助你根据实际需求选择合适的架构方案。
一、Redis 三种架构模式概述
Redis 提供了三种核心架构模式,分别针对不同的业务场景解决高可用和性能问题:
模式 | 核心特点 | 优势 | 局限性 |
---|---|---|---|
主从复制 | 数据单向复制(主到从) | 实现数据备份、读负载均衡 | 故障需手动恢复、写操作无法负载均衡 |
哨兵模式 | 基于主从复制,增加自动故障转移 | 自动恢复主节点故障、通知客户端 | 存储能力受单机限制、写操作仍集中在主节点 |
Cluster 集群 | 分布式存储,数据分片 + 主从备份 | 突破单机存储限制、读写负载均衡 | 部署复杂、需维护哈希槽映射 |
二、主从复制:高可用的基石
主从复制是 Redis 高可用的基础,通过将主节点(Master)的数据复制到从节点(Slave),实现数据冗余和读操作分流。
核心作用
- 数据冗余:除持久化外的热备份方案,避免单点数据丢失
- 故障恢复:主节点故障时,可手动切换从节点提供服务
- 负载均衡:主节点负责写操作,从节点分担读请求,提高并发能力
工作流程
- 从节点启动后向主节点发送同步请求
- 主节点执行 RDB 持久化生成数据快照,同时缓存后续写命令
- 主节点发送快照文件给从节点,从节点加载快照并应用缓存的写命令
- 后续主节点的写操作会实时同步到从节点
搭建步骤(示例)
-
环境准备(所有节点):
systemctl stop firewalld setenforce 0 yum install -y gcc gcc-c++ make # 安装 Redis 并设置软链接
-
主节点配置(192.168.10.23):
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
-
从节点配置(192.168.10.14/15):
vim /etc/redis/6379.conf # 新增配置指向主节点 replicaof 192.168.10.23 6379 /etc/init.d/redis_6379 restart
-
验证配置:
# 在主节点执行 redis-cli info replication # 显示 connected_slaves:2 即表示成功
三、哨兵模式:自动化故障转移
哨兵模式在主从复制基础上增加了监控和自动故障转移能力,解决了主节点故障需手动干预的问题。
核心功能
- 监控:定期检测主从节点健康状态
- 自动故障转移:主节点故障时,自动选举新主节点并调整从节点指向
- 通知机制:将故障转移结果告知客户端
故障转移流程
- 主观下线:单个哨兵检测到主节点无响应(超过
down-after-milliseconds
阈值) - 客观下线:超过半数哨兵认为主节点下线,触发故障转移
- 选举新主:通过 Raft 算法选举哨兵 leader,由其执行故障转移:
- 筛选健康从节点(优先选优先级高、数据最完整的节点)
- 将选中的从节点升级为主节点
- 其他从节点改为复制新主节点
- 原主节点恢复后作为从节点加入集群
搭建步骤(基于主从架构)
-
修改哨兵配置(所有节点):
vim /opt/redis-5.0.7/sentinel.conf protected-mode no port 26379 # 哨兵默认端口 daemonize yes logfile "/var/log/sentinel.log" # 监控主节点(mymaster 为集群名称,2 表示需 2 个哨兵同意判定故障) sentinel monitor mymaster 192.168.10.23 6379 2 sentinel down-after-milliseconds mymaster 30000 # 30秒无响应判定下线
-
启动哨兵:
cd /opt/redis-5.0.7/ redis-sentinel sentinel.conf &
-
验证哨兵状态:
redis-cli -p 26379 info Sentinel # 显示 master0:name=mymaster,status=ok 即正常
-
故障测试:
# 杀死主节点进程 kill -9 [redis-server pid] # 查看哨兵日志确认故障转移 tail -f /var/log/sentinel.log
四、Cluster 集群:突破单机限制
Cluster 集群是 Redis 3.0 引入的分布式架构,通过数据分片和主从备份,解决了单机存储上限和写操作瓶颈问题。
核心特性
- 数据分片:采用 16384 个哈希槽(0-16383),每个主节点负责一部分槽
- 自动负载均衡:键通过
CRC16(key) % 16384
映射到对应槽,自动路由到目标节点 - 高可用:每个主节点可配置从节点,主节点故障时从节点自动升级
哈希槽分配示例
- 节点 A(6001):0-5460 号槽
- 节点 B(6002):10923-16383 号槽
- 节点 C(6003):5461-10922 号槽
- 从节点(6004-6006):分别对应主节点 A-C
搭建步骤(6 节点:3 主 3 从)
-
准备节点目录:
mkdir -p /etc/redis/redis-cluster/redis600{1..6} # 复制配置文件和可执行文件到各目录
-
修改节点配置(以 6001 为例):
vim /etc/redis/redis-cluster/redis6001/redis.conf port 6001 protected-mode no cluster-enabled yes # 开启集群模式 cluster-config-file nodes-6001.conf # 集群配置文件 cluster-node-timeout 15000 # 节点超时时间 appendonly yes
-
启动所有节点:
for d in {1..6}; docd /etc/redis/redis-cluster/redis600$dredis-server redis.conf done
-
创建集群:
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 # --cluster-replicas 1 表示每个主节点配 1 个从节点
-
验证集群:
redis-cli -p 6001 -c # -c 允许节点间自动跳转 127.0.0.1:6001> cluster slots # 查看槽分配 127.0.0.1:6001> set name zhangsan # 自动路由到对应节点
五、架构选择建议
- 中小规模应用:主从复制 + 哨兵模式足以满足需求,部署简单且能保证高可用
- 大规模分布式系统:Cluster 集群是首选,可突破单机存储和性能限制
- 读多写少场景:主从复制配合读写分离,显著提升读操作吞吐量
- 核心业务系统:至少采用哨兵模式,避免主节点故障导致服务中断
通过合理选择 Redis 架构,既能保证系统的高可用性,又能根据业务增长平滑扩展,为应用提供稳定高效的数据存储服务。