前言:在上一篇文章中我们介绍了 Redis 的安全管控、性能压测与持久化分析。然而单机 Redis 始终面临一个致命问题单点故障。一旦 Redis 服务器宕机所有依赖它的业务都将中断。本文将系统介绍 Redis 高可用架构的三大核心方案——主从复制、哨兵模式和Redis Cluster 集群涵盖从基础的数据冗余到自动故障转移再到分布式数据分片与水平扩展的完整演进路径。一、主从复制高可用的基础1.1 什么是主从复制主从复制Master-Slave Replication是指将一台 Redis 服务器的数据复制到其他 Redis 服务器。其中前者称为主节点Master负责处理所有写操作后者称为从节点Slave/Replica实时同步主节点数据并可分担读请求。数据的复制是单向的只能由主节点复制到从节点。主从复制主要实现三大目标数据冗余备份主节点数据在从节点上有多份副本读写分离读操作可分散到多个从节点提升性能高可用基础主节点故障时从节点可接管服务1.2 主从复制的工作流程主从复制过程分为三个阶段第一阶段建立连接准备阶段从节点向主节点发送PSYNC命令建立复制连接。第二阶段全量同步从服务器发送PSYNC ? -1命令主服务器执行BGSAVE生成RDB文件主服务器将RDB文件发送给从服务器从服务器清空数据库并载入 RDB 文件主服务器将复制积压缓冲区的命令发送给从服务器触发全量同步的三种情况首次连接、复制 ID 不匹配、偏移量不在积压缓冲区范围内。第三阶段增量同步命令传播如果偏移量在积压缓冲区范围内主服务器发送CONTINUE响应随后发送积压缓冲区中的增量命令。增量同步的优势在于减少网络传输、降低主服务器负载、缩短同步时间。1.3 主从复制配置步骤准备工作确保主节点和从节点都已安装 Redis且网络互通。配置主节点redis.confconfbind 0.0.0.0 # 绑定 IP确保从节点可连接 port 6379 # 监听端口 requirepass your_password # 可选设置密码配置从节点redis.confconfbind 0.0.0.0 port 6380 slaveof master_ip master_port # 指定主节点 masterauth your_password # 主节点有密码则需配置建立主从连接的三种方式客户端命令SLAVEOF masterip masterport启动参数redis-server --slaveof masterip masterport配置文件在redis.conf中写入slaveof masterip masterport启动并验证bash# 启动主节点 redis-server /path/to/master/redis.conf # 启动从节点 redis-server /path/to/slave/redis.conf # 在主节点查看复制状态 redis-cli info replication # 输出应显示: role:master, connected_slaves:1 # 在从节点查看复制状态 redis-cli info replication # 输出应显示: role:slave, master_link_status:up1.4 主从复制的优缺点优点局限简单易实现成本低故障切换需人工干预读写分离扩展读性能写性能无法扩展数据冗余备份存在主从延迟主从复制解决了数据冗余和读扩展的问题但写操作仍然集中在主节点且主节点故障时需要人工介入才能恢复服务。哨兵模式正是为解决这一问题而生。二、哨兵模式自动故障转移2.1 为什么需要哨兵在主从复制架构中所有写操作都依赖主节点。如果主节点宕机将无法执行任何写操作只能通过人工重启或手动切换主节点来恢复服务。哨兵Sentinel机制的出现正是为了实现主从节点的自动故障转移。2.2 哨兵的核心功能哨兵是一个独立的 Redis 服务器进程主要提供三大功能节点监控持续监控主节点和从节点的健康状态自动故障转移主节点不可用时自动选举新主节点通知在实例发生故障或恢复时向管理系统发送通知2.3 哨兵的工作原理1主观下线与客观下线哨兵每秒向主从节点发送PING命令。如果服务器正常会返回有效回复PONG、-LOADING、-MASTERDOWN等。主观下线SDOWN单个哨兵在指定时间内未收到有效回复将该节点标记为主观下线客观下线ODOWN当主节点被标记为主观下线后哨兵会向其他哨兵发起投票。当投票数达到预设的quorum值时主节点被标记为客观下线quorum一般设置为哨兵个数的一半加 1例如 3 个哨兵设为 2。为什么哨兵也要集群哨兵本身也需要避免单点故障。多个哨兵节点同时监控 Redis 主从架构通过协商机制避免误判。2领导者选举与故障转移客观下线确认后哨兵们通过选举产生一个领导哨兵Leader Sentinel领导哨兵从所有健康的从节点中选举一个新的主节点执行主从切换新主节点上线其他从节点指向新主节点选举算法基于Raft 协议的变种确保在分布式环境下达成共识。2.4 哨兵配置步骤第一步配置哨兵节点sentinel.confconf# 监控主节点master-name ip port quorum sentinel monitor mymaster 192.168.1.100 6379 2 # 连接超时时间毫秒默认30秒 sentinel down-after-milliseconds mymaster 30000 # 故障转移超时时间毫秒默认180秒 sentinel failover-timeout mymaster 180000 # 允许同时同步的从节点数量 sentinel parallel-syncs mymaster 1 # 如果主节点有密码 sentinel auth-pass mymaster your_password # 关闭保护模式 protected-mode no第二步启动哨兵bashredis-sentinel /path/to/sentinel.conf # 或 redis-server /path/to/sentinel.conf --sentinel第三步验证哨兵状态bash# 列出所有监控的主服务器 redis-cli -p 26379 SENTINEL masters # 获取指定集群的从节点 redis-cli -p 26379 SENTINEL slaves mymaster # 获取当前主节点地址 redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster # 手动触发故障转移 redis-cli -p 26379 SENTINEL failover mymaster2.5 哨兵模式的优缺点优点缺点实现主从自动故障转移写操作仍集中在主节点写性能瓶颈未解决哨兵集群避免单点故障系统复杂性增加客户端可自动获取新主节点地址数据存储能力受限于单节点内存当数据量持续增长、单节点内存无法满足需求时就需要Redis Cluster 集群来解决海量数据存储与高并发写入的问题。三、Redis Cluster 集群分布式数据分片3.1 为什么需要集群主从复制和哨兵模式解决了高可用问题但写性能和存储容量仍然受限于单节点。Redis Cluster 集群通过数据分片Sharding将数据分散存储到多个节点上实现水平扩展支持 TB 级数据存储和高并发访问自动故障转移数据多副本存储节点故障自动切换去中心化无单点故障节点自治3.2 集群核心概念哈希槽Hash SlotRedis Cluster 采用16384 个逻辑槽位Slot进行数据分片。每个键值对通过CRC16(key) % 16384算法计算所属槽位并存储在对应的主节点上。槽位分配示例3 主 3 从集群主节点槽位范围槽位数Master 10 - 54605461Master 25461 - 109225462Master 310923 - 163835461每个主节点至少有一个从节点作为备份当主节点故障时从节点自动晋升。3.3 集群搭建步骤环境规划以 3 主 3 从为例节点IP端口角色节点 1192.168.1.1017000Master节点 2192.168.1.1017001Master节点 3192.168.1.1017002Master节点 4192.168.1.1017003Slave节点 5192.168.1.1017004Slave节点 6192.168.1.1017005Slave第一步配置每个节点redis-7000.confconfport 7000 cluster-enabled yes cluster-config-file nodes-7000.conf cluster-node-timeout 5000 appendonly yes requirepass yourpassword masterauth yourpassword注意cluster-node-timeout控制故障检测灵敏度默认 15 秒。生产环境建议每个主节点至少配备 1 个从节点。第二步启动所有节点bashredis-server /path/to/redis-7000.conf redis-server /path/to/redis-7001.conf # ... 依次启动所有节点第三步创建集群Redis 5.0 使用redis-cli替代redis-trib.rbbashredis-cli --cluster create \ 192.168.1.101:7000 \ 192.168.1.101:7001 \ 192.168.1.101:7002 \ 192.168.1.101:7003 \ 192.168.1.101:7004 \ 192.168.1.101:7005 \ --cluster-replicas 1 \ -a yourpassword--cluster-replicas 1表示为每个主节点分配 1 个从节点。第四步验证集群状态bash# 查看集群信息 redis-cli -c -h 192.168.1.101 -p 7000 -a yourpassword CLUSTER INFO # 查看节点列表 redis-cli -c -h 192.168.1.101 -p 7000 -a yourpassword CLUSTER NODES # 检查集群健康 redis-cli --cluster check 192.168.1.101:7000 -a yourpassword3.4 集群高可用与故障切换故障检测机制节点间通信集群内节点通过Gossip 协议定期交换状态信息故障标记PFAIL当节点 A 连续 5 次未收到节点 B 的 PING 响应时将 B 标记为可能故障PFAIL故障确认FAIL当半数以上主节点确认某节点为 PFAIL 时升级为FAIL状态自动选举从故障主节点的从节点中选举新主节点基于 Raft 协议变种槽位重新映射集群元数据更新将故障主节点的槽位分配给新主节点故障切换时间单分片主节点故障时备节点通常在15 秒到 30 秒内完成主备切换。运维建议配置cluster-node-timeout控制故障检测灵敏度保持每个主节点至少 1 个从节点定期执行redis-cli --cluster check验证集群健康状态四、集群节点管理增加与删除节点Redis Cluster 支持在线动态扩缩容在不中断服务的情况下增加或删除节点。4.1 增加节点集群扩容场景业务增长需要扩展集群的存储和读写能力。步骤一启动新节点bash# 配置文件 redis-7006.conf port 7006 cluster-enabled yes cluster-config-file nodes-7006.conf cluster-node-timeout 5000 requirepass yourpassword masterauth yourpassword # 启动 redis-server /path/to/redis-7006.conf步骤二将新节点加入集群bashredis-cli --cluster add-node 192.168.1.101:7006 192.168.1.101:7000 -a yourpassword此时新节点已加入集群但不承载任何槽位处于“待分配”状态。步骤三迁移槽位数据重分布bash# 从现有节点迁移槽位到新节点 redis-cli --cluster reshard 192.168.1.101:7000 \ --cluster-from source_node_id \ --cluster-to new_node_id \ --cluster-slots number_of_slots \ --cluster-yes \ -a yourpassword槽位分配策略均匀分配将现有槽位平均分配到所有节点按需分配根据业务访问模式手动指定槽位范围迁移过程是平滑的迁移期间访问被迁移的 Key 会被ASK临时转发业务基本无感知。步骤四添加从节点可选bashredis-cli --cluster add-node 192.168.1.101:7007 192.168.1.101:7000 \ --cluster-slave \ --cluster-master-id new_master_id \ -a yourpassword扩容最佳实践选择业务低峰期执行扩容操作每次迁移槽位数量控制在总量的10%以内迁移前备份数据迁移过程中监控redis-cli --cluster check输出4.2 删除节点集群缩容场景业务缩减或节点需要下线维护。步骤一迁移槽位仅针对主节点如果待删除的是主节点需要先将该节点上的所有槽位迁移到其他主节点bash# 将槽位从待删除节点迁移到其他节点 redis-cli --cluster reshard 192.168.1.101:7000 \ --cluster-from node_to_remove_id \ --cluster-to target_node_id \ --cluster-slots all_slots \ --cluster-yes \ -a yourpassword步骤二删除节点bash# 删除节点主节点需先完成槽位迁移 redis-cli --cluster del-node 192.168.1.101:7000 node_id -a yourpassword步骤三集群广播自动完成删除节点后集群会通过 Gossip 协议向所有节点广播该节点已下线其他节点从节点表中移除该节点。缩容注意事项若主节点上有槽位必须先迁移槽位再删除建议先删除从节点再删除主节点删除前确认集群有足够的容量承载被删除节点的数据五、三种架构方案对比维度主从复制哨兵模式Redis Cluster数据分片❌ 无❌ 无✅ 16384 槽位自动故障转移❌ 人工干预✅ 哨兵自动切换✅ 集群内置水平扩展❌ 受限于单机❌ 受限于单机✅ 在线扩缩容读写分离✅ 支持✅ 支持✅ 支持写性能受限于单机受限于单机随节点增加线性扩展存储容量受限于单机内存受限于单机内存随节点增加线性扩展复杂度低中高适用场景数据量小、读多写少数据量小、高可用要求高海量数据、高并发读写三者是“基础→增强→扩展”的递进关系主从复制是基础解决数据冗余和读扩展哨兵模式在主从之上增强解决自动故障转移Redis Cluster进一步扩展解决海量数据存储和写性能瓶颈总结本文系统介绍了 Redis 高可用架构的三大核心方案主从复制通过一主多从架构实现数据冗余和读写分离配置简单是 Redis 高可用的基础。但故障切换需要人工干预写性能受限于单节点。哨兵模式在主从复制基础上引入哨兵集群实现主节点自动故障检测与转移。通过主观下线、客观下线和 Raft 选举机制确保在主节点宕机时服务自动恢复。但存储和写能力仍受限于单节点。Redis Cluster 集群通过 16384 个哈希槽实现数据分片支持水平扩展和在线扩缩容。集群内置故障检测与自动恢复机制适合海量数据和高并发场景。在实际生产环境中架构选择应基于业务需求数据量小、读多写少→ 主从复制数据量小、高可用要求高→ 哨兵模式海量数据、高并发读写→ Redis Cluster建议将故障演练纳入常态化运维流程定期验证自动故障转移机制的有效性确保在高可用架构真正面临故障时能够平稳切换。