Redis 的性能优势来自内存数据结构和事件循环，但生产可靠性取决于持久化、复制、故障检测、数据淘汰和业务降级的整体设计。
一、Redis 在架构中的位置
Redis 常见角色包括缓存、分布式锁、计数器、排行榜、会话存储和轻量消息结构。不同角色对一致性、持久化和可用性的要求完全不同。缓存可以接受回源；订单状态、库存扣减等核心数据不能简单地把 Redis 当作唯一事实源。
二、持久化：RDB 与 AOF
RDB 通过快照生成某一时刻的数据文件，恢复速度快、文件紧凑，但两次快照之间可能丢失数据，且 fork 期间会产生写时复制开销。
AOF 记录写命令，可配置 appendfsync 策略。同步频率越高，数据丢失窗口越小，但磁盘和延迟压力越大。生产环境通常结合 AOF 重写、RDB 快照和备份校验，不能只看"开启了持久化"这一项。
如果 Redis 只是纯缓存，可以把重建能力放在数据库和应用侧；如果 Redis 承载不可轻易重建的数据，则必须明确备份、恢复演练和 RPO/RTO 指标。
三、主从复制与 Sentinel
主从复制解决数据副本和读扩展问题，但复制默认是异步的，主节点故障时可能存在尚未复制到从节点的数据丢失。Sentinel 负责监控、选主和通知客户端，适合中小规模高可用部署。
Sentinel 不是数据一致性魔法。发生网络分区时，故障判断依赖 quorum、主观下线和客观下线；客户端还必须正确处理拓扑变化、连接重建和重试风暴。
四、Redis Cluster
Redis Cluster 使用 16384 个 hash slot 将 key 分片到多个主节点，每个主节点可配置副本。它解决了单机容量和吞吐上限，但引入了 MOVED/ASK 重定向、跨 slot 多 key 操作限制、故障迁移和热点 slot 等复杂性。
设计 key 时应避免把热点集中到一个固定 key。对计数器、排行榜和大促活动，要结合分片计数、局部聚合和随机后缀降低热点；对需要原子操作的多 key 场景，尽量使用 hash tag 让相关 key 落在同一 slot。
五、缓存一致性与击穿治理
常见缓存模式是 Cache Aside：读缓存，未命中读数据库并回填；写入时先更新数据库，再删除缓存。删除后短时间内的并发回填、延迟双删、消息订阅和版本号校验，都要根据业务一致性要求选择。
- 缓存穿透：对不存在的 key 反复查询，使用参数校验、布隆过滤器或空值短缓存。
- 缓存击穿：热点 key 过期瞬间大量回源，使用互斥锁、逻辑过期或热点预热。
- 缓存雪崩：大量 key 同时失效，使用随机 TTL、分批发布、多级缓存和限流降级。
六、分布式锁的边界
Redis 锁至少要具备唯一 token、过期时间和只删除自身 token 的校验。锁只适合缩小并发窗口，不应替代数据库事务。对支付、库存等场景，要配合幂等号、状态机和最终一致性补偿；不能因为"加了锁"就认为流程不会重复执行。
七、监控与故障演练
重点监控内存使用、evicted_keys、expired_keys、命中率、blocked_clients、慢查询、复制延迟、主从切换次数、AOF rewrite 和 fork 延迟。演练时至少验证：主节点故障、网络分区、磁盘满、恢复备份、客户端重连和业务降级。
八、常见误区
- 把 Redis Cluster 当成强一致数据库。
- 只配置副本，不验证副本延迟和故障切换。
- 使用大 key、热 key，却只通过加机器解决。
- 开启淘汰策略后没有评估核心 key 是否被淘汰。
- 重试没有退避和上限，故障时形成连接风暴。
九、架构结论
Redis 高可用的核心不是"部署几个节点"，而是明确数据等级：可重建缓存、可恢复状态、不可丢失事实数据分别采用不同的持久化、复制和降级策略。架构设计必须同时回答 RPO、RTO、一致性、容量、热点和恢复演练六个问题。
参考：Redis 官方文档中的 Persistence、Replication、Sentinel、Cluster 和 eviction 章节。