目录一.环境准备二.搭建Redis 主从复制2.1Redis安装 部署2.2Master节点配置2.3Slave节点配置2.4验证主从效果三、Redis哨兵模式3.1配置哨兵模式所有节点操作3.2启动哨兵模式3.3查看哨兵信息3.4故障模拟测试四.Redis 群集模式4.1创建集群配置文件每台机器两个实例4.2在另外两台机器上重复步骤34.3启动所有Redis实例三台机器4.4组建集群在一台机器上执行即可4.5验证集群状态4.6测试数据写入五.故障测试六.redis说明6.1 为什么选择该架构①业务需求分析②架构选型对比③选择本方案的核心原因6.2拓扑关系简图6.3节点角色说明七.总结1. 环境准备与主从复制2. 哨兵模式实现高可用3. Redis Cluster 集群部署4. 架构优势与特点5. 关键注意事项一.环境准备Master节点192.168.10.110Slave1节点192.168.10.111Slave2节点192.168.10.112系统配置systemctl stop firewalld setenforce 0二.搭建Redis 主从复制2.1Redis安装 部署# 安装依赖 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.2Master节点配置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 restart2.3Slave节点配置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 restart2.4验证主从效果在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:ip192.168.10.120,port6379,stateonline,offset1246,lag0 slave1:ip192.168.10.123,port6379,stateonline,offset1246,lag1在Master节点插入一条数据验证结果# 在Master节点插入一条数据 set master 192.168.10.110 # 在slave节点查看数据 get master三、Redis哨兵模式3.1配置哨兵模式所有节点操作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.2启动哨兵模式注意先启动master再启动slavecd /opt/redis-5.0.7/ redis-sentinel sentinel.conf 3.3查看哨兵信息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:namemymaster,statusok,address192.168.10.110:6379,slaves2,sentinels33.4故障模拟测试# 查看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 群集模式4.1创建集群配置文件每台机器两个实例以192.168.10.110为例创建两个配置文件主节点 6379mkdir -p /etc/redis/cluster/6379 /etc/redis/cluster/6380 cp /opt/redis-5.0.7/redis.conf /etc/redis/cluster/6379/redis.conf cp /opt/redis-5.0.7/redis.conf /etc/redis/cluster/6380/redis.conf修改 6379 配置主节点vim /etc/redis/cluster/6379/redis.conf修改以下内容bind 0.0.0.0 protected-mode no port 6379 daemonize yes cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000 appendonly yes修改 6380 配置从节点vim /etc/redis/cluster/6380/redis.conf修改以下内容bind 0.0.0.0 protected-mode no port 6380 daemonize yes cluster-enabled yes cluster-config-file nodes-6380.conf cluster-node-timeout 15000 appendonly yes4.2在另外两台机器上重复步骤3192.168.10.111同样创建 6379主、6380从192.168.10.112同样创建 6379主、6380从4.3启动所有Redis实例三台机器redis-server /etc/redis/cluster/6379/redis.conf redis-server /etc/redis/cluster/6380/redis.conf检查进程ps -ef | grep redis4.4组建集群在一台机器上执行即可在192.168.10.110上执行redis-cli --cluster create \ 192.168.10.110:6379 \ 192.168.10.111:6379 \ 192.168.10.112:6379 \ 192.168.10.111:6380 \ 192.168.10.112:6380 \ 192.168.10.110:6380 \ --cluster-replicas 1⚠️注意顺序前三个是主节点110:6379, 111:6379, 112:6379后三个是从节点111:6380, 112:6380, 110:6380这样分配后110:6379 的从节点是 111:6380不是本机 ✅111:6379 的从节点是 112:6380不是本机 ✅112:6379 的从节点是 110:6380不是本机 ✅执行后会提示分配哈希槽输入yes确认。4.5验证集群状态redis-cli -h 192.168.10.110 -p 6379 cluster nodes或查看详细信息redis-cli -h 192.168.10.110 -p 6379 cluster info查看主从关系redis-cli -h 192.168.10.110 -p 6379 info replication4.6测试数据写入redis-cli -h 192.168.10.110 -p 6379 -c set name zhangsan redis-cli -h 192.168.10.110 -p 6379 -c get name五.故障测试测试场景主节点宕机模拟 M1 故障# 在主机A192.168.10.110上停止主节点 M1 ps -ef | grep redis | grep 6379 kill -9 M1进程PID日志记录# 从节点 S1192.168.10.111:6380日志 23062:x 08 Aug 2026 10:15:30.123 # sdown master mymaster 192.168.10.110 6379 23062:x 08 Aug 2026 10:15:35.456 # new-epoch 1 23062:x 08 Aug 2026 10:15:35.457 # vote-for-leader 0fef2cc38d8db8cc... 1 23062:x 08 Aug 2026 10:15:38.789 # switch-master mymaster 192.168.10.110 6379 192.168.10.111 6380 23062:x 08 Aug 2026 10:15:38.790 * slave slave 192.168.10.112:6380 192.168.10.112 6380 mymaster 192.168.10.111 6380 23062:x 08 Aug 2026 10:15:38.790 * slave slave 192.168.10.110:6379 192.168.10.110 6379 mymaster 192.168.10.111 6380故障转移后集群状态redis-cli -h 192.168.10.111 -p 6380 cluster nodes查看新的主节点# 通过任意可用节点查看集群状态 redis-cli -h 192.168.10.111 -p 6379 cluster nodes# 在111机器上执行 redis-cli -h 192.168.10.111 -p 6380 info replication六.redis说明6.1 为什么选择该架构①业务需求分析需求说明高可用性任意一台机器宕机数据不丢失服务不中断读写分离主节点负责写从节点可分担读压力水平扩展未来可动态增加节点突破单机内存限制数据安全每个主节点都有跨主机的从节点备份②架构选型对比对比项主从复制哨兵模式Cluster集群本方案自动故障转移❌✅✅写负载均衡❌❌✅数据分片存储水平扩展❌❌✅16384槽分片跨主机数据冗余✅✅✅从节点不跟主同机可配置可配置✅本方案实现运维复杂度低中中高③选择本方案的核心原因数据分片突破单机内存瓶颈3个主节点分担数据存储总容量是单机的3倍跨主机高可用每个主节点的从节点都在其他机器上单机宕机不影响整体服务读写性能提升3主3从读操作可由从节点分担提升并发能力自动故障转移主节点宕机后哨兵机制自动选举从节点升级为主节点满足「主从不同机」的容灾要求物理隔离避免单点故障导致数据全部丢失6.2拓扑关系简图6.3节点角色说明节点标识IP地址端口角色负责哈希槽范围所属物理机M1192.168.10.1106379主节点0 – 5460主机AS3192.168.10.1106380从节点复制M3主机AM2192.168.10.1116379主节点5461 – 10922主机BS1192.168.10.1116380从节点复制 M1主机BM3192.168.10.1126379主节点10923 – 16383主机CS2192.168.10.1126380从节点复制 M2主机C七.总结本文详细介绍了 Redis 高可用集群的完整搭建过程涵盖了从基础环境准备到三种核心架构模式的实践操作1. 环境准备与主从复制完成了三台服务器192.168.10.110/111/112的基础环境配置成功搭建了 Redis 主从复制架构实现了数据同步和读写分离通过日志监控和命令验证确保了主从同步的正常运行2. 哨兵模式实现高可用配置并启动了 Redis Sentinel 哨兵集群实现了主节点故障时的自动故障转移通过故障模拟测试验证了哨兵模式的可靠性3. Redis Cluster 集群部署在三台机器上分别部署了主从实例每台机器 6379 主 6380 从成功组建了 3 主 3 从的 Redis 集群实现了数据分片存储突破了单机内存限制验证了集群状态和数据读写功能4. 架构优势与特点高可用性任意节点故障不影响整体服务数据安全跨主机备份避免单点故障导致数据丢失性能扩展读写分离 数据分片支持水平扩展自动运维哨兵机制实现自动故障检测和转移5. 关键注意事项集群组建时注意节点顺序确保主从节点分布在不同的物理机上哨兵配置中的 quorum 参数需要根据实际节点数量合理设置故障转移后需要验证新的主从关系和数据一致性生产环境建议配置监控告警及时发现和处理异常通过本文的实践读者可以掌握 Redis 从单机部署到高可用集群的完整技术栈为生产环境中的 Redis 应用提供可靠的技术保障。这套架构方案既满足了数据安全和高可用的需求又具备了良好的扩展性是构建大规模 Redis 应用的理想选择。
