Redis实现持久化存储，互联网公司常用分库分表方案汇总

#900秒内，至少有一个key进行了修改，就进行持久化操作

save 900 1

#300秒内，至少有10个key进行了修改，就进行持久化操作

save 300 10

#60秒内，至少有1000个key进行了修改，就进行持久化操作

save 60 10000

流程说明：

1.父进程执行fork操作创建子进程

2.子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原来文件进行原子替换。

3.进程发送信号给父进程表示完成，父进程更新统计信息。

整个过程主进程不进行任何io操作，保证了性能，如果进行大规模数据恢复，RDB和AOP都可以进行数据恢复，RDB数据恢复完整性不敏感，RDB更加高效，缺点时最后一次持久化后的数据可能丢失，默认使用的就是RDB，一般情况不需要修改这个配置。

RDB文件处理：

RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定，默认为一个dump.rdb文件(在生产环境中最好对dump.rdb文件进行备份)。可以通过执行config set dir {newDir}和config set dbfilename {newFileName}运行期动态执行，当下次运行时会保存到新目录。

如果redis加载的RDB文件损坏时拒绝启动，可以使用Redis提供的redis-check-dump工具检测RDB文件并获得对应的错误报告。

RDB优点：

• RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适合备份：父进程正常处理用户请求，fork分支一个子进程进行备份。

• 适合大规模的数据恢复，如果服务器宕机了，不要删除rdb文件，重启自然在目录下，自动会读取，并且数据恢复速度远大于AOF方式。

RDB缺点：

• RDB并不能做到实时持久化，存储需要一定的时间间隔，可以自行修改设置。如果redis意外宕机，最后一次的修改数据会丢失。

• fork进程的时候，会占用一定的内存空间。

• RDB使用特定的二进制格式保存，可能存在新老版本不兼容问题。

AOF机制

AOF（append only file）持久化： 以独立日志

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

的方式记录每次执行的命令（除读操作外），重启时重新执行AOF文件中的命令来恢复文件。（aof默认是文件无限追加，大小会不断扩张，如果是文件过大就需要写很久）

开启AOF需要我们设置配置：appendonly yes，默认不打开。文件名通过appendfilename配置设置，默认文件名为appendonly.aof。

执行流程：

• 命令写入（append）：所有命令会追加到aof_buf（缓冲区）中。

• 文件同步（sync）：AOF缓冲区根据对应的策略向硬盘做同步操作。

• 文件重写（rewrite）：随着文件越来越大，需要定期对AOF文件进行重写，达到压缩目的。

• 重启加载（load）：重启时，可以加载AOF文件进行数据恢复

AOF文件损坏：

加载损坏的AOF文件时会拒绝启动，并打印日志。我们可以先备份文件，后采用redis-check-aof --fix命令修复，修复后使用diff -u对比数据的差异，找出丢失的数据，有些可以进行人工修复。