文章目录1.快照snapshotBGSAVE和SAVE的区别2.AOF(append only file)只追加日志持久化方式两种快照也称RDB)和AOF。如图↓1.快照snapshot默认是此方式保存的文件是rdb格式所以也叫rdb方式。生成方式有客户端方式通过bgsave和save命令或者服务器配置自动触发方式。BGSAVE和SAVE的区别SAVE和BGSAVE都用于生成 RDB 快照区别主要在于是否阻塞 Redis 主进程。命令执行方式是否阻塞客户端请求适用场景SAVE由主进程同步生成 RDB是一般不建议在生产环境使用BGSAVEfork 子进程在后台生成 RDBRedis 主进程可继续处理请求常用的 RDB 持久化方式BGSAVE执行时Redis 会 fork 出一个子进程。父进程继续处理客户端请求子进程负责将 fork 时刻的数据写入临时 RDB 文件完成后再替换原来的 RDB 文件。父子进程并不是各自占用一部分内存而是最开始共享相同的物理内存页。当父进程继续处理写请求、某些内存页发生修改时操作系统才会通过Copy-On-Write写时复制为被修改的页复制一份因此在写入频繁时BGSAVE期间可能产生额外的内存开销。配置文件中的自动 RDB 快照也是以后台保存的方式执行本质上与BGSAVE的工作方式一致。SAVE则不会创建后台子进程而是由 Redis 主进程同步完成 RDB 快照。在快照生成完成之前Redis 会阻塞其他客户端请求因此实际使用中一般优先使用BGSAVE。上图模拟断电后重启服务器查询为空就是rdb方式的弊端因为上一次快照和下次快照中间有间隙间隙时间断电会导致此时间段的数据丢失。2.AOF(append only file)只追加日志AOF 会记录修改数据集的写命令但真正同步到磁盘的时机由 appendfsync 策略决定。always 每次写入后 fsynceverysec 每秒 fsync 一次默认、常用no 由操作系统决定刷盘时机。版本说明 以下 AOF 重写流程基于本文使用的 Redis 3.2适用于 Redis 7.0 之前。Redis 7.0 起改为 Multi-Part AOFBase AOF Incremental AOF Manifest但“后台重写以压缩 AOF”的核心目的不变。win环境下redis目录有两个配置文件一个windows.conf,一个windows-service.conf前者主要用于命令行手动启动 Redis后者主要用于以 Windows 服务方式运行 Redis。为了解决aof文件臃肿问题可以使用AOF重写来减小aof文件体积重写方式有两种1.客户端执行bgrewriteaof此方式不会阻塞redis.2.配置文件中配置自动触发也相当于执行了bgrewriteaof命令。重写不会读取旧的aof文件而是将旧的aof文件进行了替换流程如下1.调用fork生成子进程子进程遍历当前内存数据集根据数据当前最终状态生成能够重建这些数据的最简命令并写入新的临时 AOF 文件。2.主进程继续处理客户端请求照常把命令写入至aof文件同时会将新的写命令(快照中未搜集的)进行缓存写aof文件是为了保证重写失败后仍有完整的aof文件缓存是为了保证上一次快照没搜集到的最新命令不会遗漏。3.子进程完成写入命令至临时文件后会发信号通知父进程父进程再将缓存的命令也写入临时文件。4.父进程对临时文件重命名替换掉之前的aof文件然后继续进行常规的aof文件记录直到下一次重写。总结RDB 生成的是某一时刻的数据快照文件通常更紧凑、恢复速度更快但两次快照之间的数据可能丢失AOF记录写操作数据持久性更强但文件通常更大恢复速度也通常慢于 RDB实际数据丢失风险取决于 appendfsync 策略。RDB 和 AOF 可以同时开启两者都存在时 Redis 启动会优先使用 AOF 恢复因为 AOF 通常保存的数据更完整。