持久化解决的是「单机重启后数据恢复」;高可用解决的是「单机宕机后服务不中断」,扩展解决的是「数据与读写能力如何随规模增长」。
Redis 在这两方面提供了主从复制、Sentinel 与 Cluster 三种机制:主从负责数据备份与读扩展,Sentinel 负责自动故障转移,Cluster 负责数据分片与写扩展。 我们从主从复制说起,再谈 Sentinel 与 Cluster,帮助你在架构层面正确选择高可用与扩展方案。
主从复制是 Redis 高可用的基础:一个主节点(Master)负责写,一个或多个从节点(Replica)从主节点同步数据,从节点可对外提供读服务,从而分担读压力。主从之间的同步是异步的:主节点收到写命令后先本地执行,再异步推送给从节点,因此主从之间存在短暂延迟,且主节点宕机时,未同步到从节点的数据可能丢失。从节点可以级联(从节点的从节点),形成链式复制,减轻主节点推送压力。
主从复制的配置通常是在从节点上执行 REPLICAOF master_ip master_port,从节点会向主节点发起全量同步(主节点生成 RDB 并传输)或增量同步(主节点发送复制积压缓冲区中的写命令)。主从复制解决了数据多机备份与读负载均衡,但无法自动故障转移:主节点宕机后,需要人工或借助 Sentinel 将从节点提升为新主节点,并让客户端切换写地址。

Sentinel(哨兵)是 Redis 官方提供的自动故障转移方案:一组 Sentinel 节点监控主从节点,当主节点被判定为不可用时,Sentinel 会协商选举一个从节点提升为新主节点,并通知其他从节点与客户端更新配置,从而在无需人工干预的情况下完成主从切换。Sentinel 本身不存储数据,只负责监控、判断下线、选举新主、下发配置;客户端需要连接 Sentinel 获取当前主节点地址,或在主从切换后收到 Sentinel 的通知(如 +switch-master)后主动刷新配置。
Sentinel 的「主观下线」与「客观下线」:单个 Sentinel 发现主节点 PING 超时,会将其标记为主观下线;当足够多的 Sentinel(通常为多数)都认为主节点下线时,会判定为客观下线,并触发故障转移。建议部署奇数个 Sentinel(如 3 个),避免选举时出现平票。Sentinel 解决了主从自动切换,但写仍然集中在单主节点,存储与写能力受单机限制;若需要水平扩展写与存储,需要 Cluster。

Redis Cluster 是分片集群:数据按槽位(slot,共 16384 个)分布到多个主节点,每个主节点负责一部分槽位,主节点之间通过 Gossip 协议通信,客户端根据 Key 的 CRC16 对 16384 取模得到槽位,再路由到对应节点。Cluster 支持水平扩展:增加节点时,可将部分槽位从现有节点迁移到新节点;每个主节点可以配置从节点,主宕机时从节点可被提升,从而在分片基础上实现高可用。
Cluster 的局限在于跨槽命令:若一个命令涉及多个 Key 且这些 Key 不在同一槽位,Redis 会报错,需要客户端用 Hash Tag(将多个 Key 的相同部分放在 {} 内,使它们落在同一槽位)或拆分命令。Cluster 适合数据量大、写压力大、需要水平扩展的场景;若数据量小、写压力小,主从 + Sentinel 即可。在下一讲中,我们将看 Redis 的性能问题与坑:大 Key、热点 Key 与内存淘汰策略,届时会讨论如何在实际运行中规避常见问题。
