Redis 高可用与扩展
持久化解决的是「单机重启后数据恢复」；高可用解决的是「单机宕机后服务不中断」，扩展解决的是「数据与读写能力如何随规模增长」。
Redis 在这两方面提供了主从复制、Sentinel 与 Cluster 三种机制：主从负责数据备份与读扩展，Sentinel 负责自动故障转移，Cluster 负责数据分片与写扩展。 我们从主从复制说起，再谈 Sentinel 与 Cluster，帮助你在架构层面正确选择高可用与扩展方案。
主从复制
主从复制是 Redis 高可用的基础：一个主节点（Master）负责写，一个或多个从节点（Replica）从主节点同步数据，从节点可对外提供读服务，从而分担读压力。主从之间的同步是异步的：主节点收到写命令后先本地执行，再异步推送给从节点，因此主从之间存在短暂延迟，且主节点宕机时，未同步到从节点的数据可能丢失。从节点可以级联（从节点的从节点），形成链式复制，减轻主节点推送压力。
主从复制的配置通常是在从节点上执行 REPLICAOF master_ip master_port，从节点会向主节点发起全量同步（主节点生成 RDB 并传输）或增量同步（主节点发送复制积压缓冲区中的写命令）。主从复制解决了数据多机备份与读负载均衡，但无法自动故障转移：主节点宕机后，需要人工或借助 Sentinel 将从节点提升为新主节点，并让客户端切换写地址。
Sentinel
Sentinel（哨兵）是 Redis 官方提供的自动故障转移方案：一组 Sentinel 节点监控主从节点，当主节点被判定为不可用时，Sentinel 会协商选举一个从节点提升为新主节点，并通知其他从节点与客户端更新配置，从而在无需人工干预的情况下完成主从切换。Sentinel 本身不存储数据，只负责监控、判断下线、选举新主、下发配置；客户端需要连接 Sentinel 获取当前主节点地址，或在主从切换后收到 Sentinel 的通知（如 +switch-master）后主动刷新配置。
Sentinel 的「主观下线」与「客观下线」：单个 Sentinel 发现主节点 PING 超时，会将其标记为主观下线；当足够多的 Sentinel（通常为多数）都认为主节点下线时，会判定为客观下线，并触发故障转移。建议部署奇数个 Sentinel（如 3 个），避免选举时出现平票。Sentinel 解决了主从自动切换，但写仍然集中在单主节点，存储与写能力受单机限制；若需要水平扩展写与存储，需要 Cluster。
Cluster 模式
Redis Cluster 是分片集群：数据按槽位（slot，共 16384 个）分布到多个主节点，每个主节点负责一部分槽位，主节点之间通过 Gossip 协议通信，客户端根据 Key 的 CRC16 对 16384 取模得到槽位，再路由到对应节点。Cluster 支持水平扩展：增加节点时，可将部分槽位从现有节点迁移到新节点；每个主节点可以配置从节点，主宕机时从节点可被提升，从而在分片基础上实现高可用。
Cluster 的局限在于跨槽命令：若一个命令涉及多个 Key 且这些 Key 不在同一槽位，Redis 会报错，需要客户端用 Hash Tag（将多个 Key 的相同部分放在 {} 内，使它们落在同一槽位）或拆分命令。Cluster 适合数据量大、写压力大、需要水平扩展的场景；若数据量小、写压力小，主从 + Sentinel 即可。在下一讲中，我们将看 Redis 的性能问题与坑：大 Key、热点 Key 与内存淘汰策略，届时会讨论如何在实际运行中规避常见问题。
