Redis高可用架构：哨兵与集群模式
Redis单实例存在单点故障风险，一旦Redis宕机，依赖缓存的服务将直接承受数据库压力，可能导致雪崩效应。构建Redis高可用架构是保障系统稳定性的必要措施。本文介绍Redis Sentinel（哨兵）和Redis Cluster（集群）两种高可用方案。
「Redis高可用架构：哨兵与集群模式」是数据团队绕不开的现实课题。Redis 缓存与内存治理不是一次性项目，而是伴随业务增长持续演进的过程，需要把性能、安全与成本放在同一个框架里长期权衡。
主从复制
主从复制是所有高可用方案的基础。Master负责写操作，Slave复制Master的数据并提供读服务。配置方式：replicaof master_ip master_port。复制过程分两阶段：全量同步（首次连接时RDB快照+增量AOF）和增量同步（基于repl_offset的command传播）。
注意：主从复制是异步的，Master宕机时可能丢失少量未同步的数据。对数据一致性要求高的场景可以配置 min-replicas-to-write 1（至少一个Slave确认写入成功）。
哨兵模式（Sentinel）
Sentinel在主从复制基础上增加了自动故障转移能力。当Master宕机时，Sentinel集群（至少3个节点）通过投票机制判断Master是否真的下线（主观下线→客观下线），然后自动选举一个Slave提升为新的Master，其他Slave切换到新Master。
Sentinel还负责通知客户端新的Master地址。客户端连接Sentinel而非直接连接Redis，Sentinel返回当前Master的地址。Master发生故障转移后，Sentinel自动更新Master地址，客户端无感知切换。
集群模式（Cluster）
Redis Cluster是Redis的原生分布式方案，通过数据分片实现水平扩展。16384个哈希槽分配到不同节点，每个节点负责一部分槽。客户端通过 MOVED 和 ASK 重定向找到正确的节点。
Cluster模式下每个Master可以有Slave，Master故障时Slave自动提升。Cluster支持在线扩缩容：添加新节点 → 迁移哈希槽 → 完成扩容。整个过程不停服。
限制：不支持跨槽的多Key操作（除非使用Hash Tag），不支持SELECT多数据库。事务只支持同一槽的多个Key。
阿里云Redis
阿里云Redis默认就是高可用的（双机热备+自动切换），集群版支持256GB-4TB内存，无需自建哨兵或集群。对于大多数场景，直接使用阿里云Redis是更省心的选择。
从排查到预防：把经验沉淀为机制
- 慢的问题先定位再动手：用执行计划与监控数据说话，避免凭感觉改索引、改参数。
- 变更留痕：每一次调整记录原因与预期，便于复盘与回退。
- 容量预警前置：为存储、连接数、内存等关键水位设置提前量告警。
- 演练常态化：把恢复演练、切换演练纳入日常，而不是出事才第一次做。
机制化的沉淀，能让Redis 缓存与内存治理从「个人经验」变成「团队能力」。
Redis 缓存与内存治理的三个基本盘
其一是可恢复性：备份的价值不在于「做了」，而在于「能恢复」，定期演练恢复流程比增加备份份数更重要。其二是可回滚性：任何结构或参数变更都应有回退路径，避免把生产当试验场。其三是可预估性：容量与增长趋势要有数据支撑，而不是等到告警才响应。
这三个基本盘稳固之后，再去做性能调优和架构升级，风险会小很多。