【Redis】高可用核心讲解

Redis 进阶篇持久化 主从复制 哨兵 集群面试必杀本篇你将掌握Redis 数据为什么不会完全丢Redis 如何实现高可用Redis 如何支撑大规模系统面试官最爱问的架构问题一、Redis 为什么不会“完全丢数据”很多人以为Redis 内存数据库 一断电就没了 ❌其实Redis 提供持久化机制二、Redis 持久化机制Redis 有两种核心持久化方式方式本质RDB快照AOF日志1️⃣ RDB快照模式什么是 RDB在某一时刻把内存数据拍个快照存到磁盘类比理解RDB ≈ 游戏存档触发方式自动触发配置save9001# 900秒内有1次修改save30010save6010000手动触发SAVE# 同步阻塞BGSAVE# 异步推荐✅ 优点恢复速度快文件小性能影响低❌ 缺点会丢数据最后一次快照之后的数据可能丢失2️⃣ AOF追加日志什么是 AOF把每一次写操作记录下来SET name Tom INCR count类比AOF ≈ 操作日志回放恢复三种刷盘策略面试必问策略说明always每次写都同步最安全everysec每秒同步推荐no操作系统决定✅ 优点更安全最多丢1秒数据❌ 缺点文件大恢复慢3️⃣ 面试标准答案Redis 持久化如何选生产环境AOF RDB 混合使用Redis 4.0 之后支持混合持久化AOF RDB三、Redis 高可用主从复制核心为什么需要主从单机 Redis → 容易挂 ❌解决一主多从Master Slave架构图理解Master / \ Slave Slave原理面试重点第一次同步全量复制Slave 发送请求Master 执行BGSAVE → 生成 RDB发送给 SlaveSlave 加载数据后续同步增量复制通过命令传播面试加分点Redis 复制是异步复制重要四、Redis 哨兵Sentinel为什么需要哨兵主从架构问题Master 挂了怎么办❌哨兵的作用1️⃣ 监控 Redis2️⃣ 自动故障转移3️⃣ 选举新 Master架构图Sentinel Sentinel Sentinel \ | / Redis集群故障转移流程面试重点哨兵发现 Master 挂了投票选举新 MasterSlave 升级为 Master通知客户端面试关键点哨兵是分布式系统多个节点投票五、Redis 集群Cluster为什么需要集群主从的问题数据量太大 → 一台机器放不下 ❌解决Redis Cluster分片核心思想数据分散到多个节点核心机制Hash Slot槽位Redis 有16384 个槽位数据分布key → hash → slot → 节点示例Node1: 0-5000 Node2: 5001-10000 Node3: 10001-16383面试高频问题为什么是 16384权衡太大 → 计算复杂太小 → 分布不均集群特点去中心化自动分片支持扩容六、Redis 架构总结三种模式对比模式特点单机简单但不可靠主从读写分离哨兵高可用集群高可用 高扩展七、面试高频问题1. RDB 和 AOF 区别RDB快照恢复快但可能丢数据 AOF日志更安全但恢复慢2. Redis 如何保证高可用主从复制 哨兵3. Redis 集群如何分片Hash Slot163844. 主从复制是同步的吗不是 → 异步复制5. 哨兵如何选主投票机制类似 Raft 思想八、实际开发建议✅ 生产推荐架构Redis Cluster 哨兵或云服务✅ 持久化推荐AOF everysec RDB✅ 客户端建议Spring Boot → Lettuce默认避免 Jedis 连接池问题九、总结面试速记版Redis 高可用核心 1. 持久化RDB AOF 2. 主从复制读写分离 3. 哨兵自动故障转移 4. 集群分片 扩展