Redis高可用面试知识：持久化+主从复制+哨兵机制

Redis高可用面试知识持久化主从复制哨兵机制一、Redis RDB 持久化原理快照持久化RDBRedis Database是Redis默认的持久化方式核心原理是全量快照。在指定时间节点将内存中所有数据以二进制形式持久化到磁盘生成.rdb快照文件Redis重启时可通过该文件快速恢复全量数据。1、触发机制手动自动1手动触发SAVE主线程执行快照全程阻塞Redis不推荐生产使用BGSAVEfork子进程完成快照写入主线程继续处理客户端请求无阻塞生产默认使用2自动触发配置规则通过配置文件配置规则满足条件自动执行BGSAVE例如save 900 1表示900秒内至少1个key变更自动触发快照。同时执行flushall、正常关闭Redis也会自动触发RDB持久化。2、核心执行流程fork子进程主线程调用fork创建子进程此时会短暂阻塞Redis拷贝页表内存快照写入子进程基于操作系统写时复制机制COW读取当前内存全量数据写入临时RDB文件文件替换写入完成后用临时文件替换正式rdb文件保证文件完整性结束进程子进程退出持久化完成。3、RDB优缺点面试必背优点文件是二进制压缩文件体积小、恢复速度极快基于子进程执行不阻塞主线程性能损耗低适合冷备份、全量数据迁移、灾难恢复。缺点数据丢失风险大两次快照之间的增量数据未落地Redis宕机会丢失间隔内所有数据大数据量下fork子进程耗时久会引发短暂服务卡顿无法实现秒级、实时持久化数据安全性差。二、Redis AOF 持久化原理日志持久化AOFAppend Only File是增量日志持久化方案默认关闭。核心原理是记录Redis所有写操作命令读操作不记录以日志追加的方式写入aof文件重启时重放日志命令恢复数据主打高数据安全性。1、核心执行流程命令追加客户端执行写命令Redis将命令协议格式追加到AOF缓冲区缓冲区刷盘根据配置策略将缓冲区数据同步写入磁盘aof文件日志重写文件过大时触发AOF重写精简冗余命令压缩文件体积重启恢复服务重启时逐条执行aof文件中的命令还原内存数据。2、三大刷盘策略面试高频always每执行一条写命令立即刷盘。数据零丢失但是性能极差高并发禁用everysec默认每秒批量刷盘一次。性能均衡最多丢失1秒数据生产最常用no交由操作系统自主刷盘。性能最高丢失数据不可控安全性最低。3、AOF重写机制核心优化AOF持续追加命令会导致文件无限膨胀存在大量冗余命令如多次修改同一个key。Redis通过AOF重写精简日志fork子进程基于当前内存数据生成最简写命令替换旧日志文件大幅缩小文件体积、提升重启恢复速度。重写过程不影响主线程读写。4、AOF优缺点优点数据安全性极高默认策略仅丢失1秒数据日志文本格式清晰可手动修改、修复数据增量持久化无全量快照的卡顿问题。缺点日志文件体积远大于RDB恢复速度慢于RDB持续刷盘、重写会带来一定性能开销纯AOF重启恢复海量数据时速度较慢。自动触发满足两个条件 同时满足以下两个配置条件时自动触发当前 AOF 文件大小 auto-aof-rewrite-min-size 默认 64MB当前 AOF 文件大小 比 上次重写后大小 增长比例超过 auto-aof-rewrite-percentage 默认 100% 即翻倍 简单记 文件够大 比上次重写时大了一倍 → 自动重写三、RDBAOF 混合持久化Redis4.0 生产终极方案Redis 4.0 推出混合持久化机制完美结合RDB和AOF的优势解决了RDB数据不安全、AOF恢复慢的双重痛点是目前生产环境默认推荐开启的持久化方案。1、核心原理开启混合持久化后执行AOF重写时前半段将当前内存全量数据以RDB二进制格式写入AOF文件后半段追加重写过程中产生的增量AOF命令日志。最终AOF文件 RDB全量快照 AOF增量日志。2、重启恢复逻辑Redis重启时优先解析AOF文件先快速加载前段RDB二进制全量数据再重放后段增量AOF命令既保证恢复速度又保证数据完整性。3、核心优势与面试总结兼顾恢复速度RDB优势与数据安全AOF优势解决纯AOF文件过大、恢复慢的问题同时避免纯RDB丢失增量数据的缺陷生产环境必开是Redis持久化的最优解。四、Redis 主从复制原理高可用基础主从复制是Redis高可用的基础架构核心实现一主多从、数据单向同步主节点负责读写从节点同步主节点数据、分担读压力实现读写分离、数据备份为哨兵、集群架构提供支撑。1、主从复制核心流程完整三阶段1建立连接阶段从节点启动后向主节点发起连接请求主节点校验权限、端口建立长连接持续监听主节点写命令。2全量同步阶段首次同步主节点执行BGSAVE生成RDB快照将快照文件发送给从节点从节点清空本地旧数据加载RDB文件完成全量数据同步。同步期间主节点缓存新增写命令同步完成后补发缓存命令。3增量同步阶段持续同步全量同步完成后进入持续增量同步。主节点每执行一条写命令实时同步给从节点保证主从数据最终一致。基于复制偏移量复制积压缓冲区实现部分重同步避免网络断连后重复全量同步。2、核心机制部分重同步repl-backlogRedis为解决网络短暂断开、频繁全量同步的性能问题引入复制积压缓冲区主节点维护固定长度缓冲区记录近期写命令与偏移量。从节点断连重连后对比本地偏移量与主节点缓冲区偏移量若数据仍在缓冲区仅同步缺失增量数据无需全量同步大幅提升同步效率。3、主从复制优缺点优点实现读写分离提升Redis整体并发吞吐量多从节点备份数据降低数据丢失风险是哨兵、集群架构的前置基础。缺点主从同步存在毫秒级延迟无法实现强一致性主节点故障后无法自动切换存在单点故障需配合哨兵实现高可用。五、Redis 哨兵机制与故障转移高可用核心哨兵Sentinel是Redis实现自动高可用、故障自愈的核心方案基于主从架构搭建不处理业务读写仅负责监控、通知、自动故障转移、配置维护彻底解决主节点单点故障问题。生产标配1主2从3哨兵架构。1、哨兵四大核心功能监控哨兵集群持续PING主、从节点实时检测节点存活状态消息通知节点异常时哨兵主动通知客户端与运维平台自动故障转移主节点下线后自动选举新主库、重构主从架构配置中心实时维护主节点地址客户端通过哨兵获取最新主库节点无感切换。2、节点下线判定规则面试重点1主观下线 SDOWN单个哨兵节点PING超时单方面判定主节点下线仅代表当前哨兵视角不触发故障转移。2客观下线 ODOWN超过半数哨兵判定主节点主观下线才会标记为客观下线确认主节点真正故障触发后续故障转移流程。该机制避免网络抖动导致的误判。3、哨兵Leader选举机制主节点客观下线后哨兵集群需要选出一个Leader哨兵全权负责故障转移选举规则所有哨兵参与投票同一周期单个哨兵仅能投一票得票超过半数的哨兵成为Leader选举失败则随机重试保证最终只有一个Leader执行故障转移。4、新主节点选举规则最优从库筛选Leader哨兵按照优先级依次筛选选出最优从节点升级为新主库排除已经下线、异常的从节点优先选择主从复制偏移量最大的从节点数据最完整、丢失最少偏移量一致时选择运行ID最小的从节点作为新主。5、完整故障转移流程故障判定半数哨兵确认主节点客观下线选举Leader哨兵集群投票选出唯一Leader节点选举新主Leader按照规则筛选最优从库发送SLAVEOF NO ONE使其升级为主节点重构主从Leader通知其他所有从节点挂载到新主节点完成数据同步旧主降级原故障主节点恢复后自动降级为从节点同步新主数据通知客户端哨兵推送新主库地址客户端无感切换业务恢复正常。6、哨兵机制优缺点优点实现主节点故障自动转移秒级自愈保证服务高可用集群监控、容错性强半数节点故障不影响整体服务客户端无感切换业务无感知、零停机。缺点仅解决高可用问题无法解决海量数据分片、扩容问题仍存在主从同步延迟不支持强一致性场景。六、面试满分总结话术可直接背诵RDB是全量二进制快照恢复快、体积小但存在批量数据丢失风险适合冷备份AOF是增量命令日志数据安全性高默认每秒刷盘最多丢1秒数据但恢复速度慢。混合持久化结合两者优势AOF文件前存RDB全量数据、后存增量日志兼顾恢复速度和数据安全是生产最优持久化方案。主从复制分为全量同步、增量同步依托复制积压缓冲区实现部分重同步实现读写分离和数据备份但存在同步延迟、主节点单点故障问题。哨兵机制基于主从架构通过集群监控、客观下线判定、哨兵Leader选举、最优从库升级实现主节点故障自动转移解决Redis单点故障实现高可用适合绝大多数中小规模高并发业务。