如果同时有RDB与AOF文件，则恢复数据时优化AOF，因为AOF数据会比较全
RDB：根据配置的间隔生成快照
相关配置：
【RDB 方式保存配置】
# rdb 方式保存进行压缩
rdbcompression yes
#
rdbchecksum yes
# rdb 文件名
dbfilename dump.rdb
优点：
数据文件紧凑；fork子进程进行数据处理；恢复大数据集的时候比AOF快
缺点：
在大数据集中，需要保存整个数据集的状态，操作保存动作时间久
AOF：以Redis的协议格式追加的形式记录写操作命令；使用 rewrite 优化aof文件；
相关配置：
# 【AOF 配置】
# 是否开启，如果里面已经有数据了，则在开启这个之后，重启Redis会清空所有数据
appendonly no
# AOF文件
appendfilename "appendonly.aof"
# AOF记录规则，【一直同步|每秒同步|不自动，交给操作系统】
appendfsync everysec
# AOF是否重写，如果开启了，则会减小文件体积，相同的命令不会多次记录，即：对一个key，只有一条记录操作
no-appendfsync-on-rewrite no
# AOF文件重写规则
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
优点：
同步间隔秒级；只能文件追加，速度快；自动重写【优化】AOF文件；有恢复当前数据集的所有最小化命令，数据完整性好
缺点：可能会未知的BUG；数据集大时，载入AOF文件慢；
执行步骤：
1. fork子进程；
2. 子进程将新的AOF内容写到临时文件
3. 父进程对所有新AOF内容缓存到内存，且保存到原AOF文件，保证数据不会丢失
4. 子进程完成后，给父进程一个信号，开始写入父进程缓存的写入命令
5. 替换原来的AOF文件
持久化的一些命令：
bgrewriteaof # 后台重写aof文件
bgsave # 后台生成快照
save # 马上生成快照
redis-check-aof # aof 文件有异常时，此命令会修复，例如：执行的命令只写入了一半，导致不命令不完整【软件包中的相关程序，不是redis里面的命令】
RDB 与AOF的切换：
1. 备份 dump.rdb 文件
2. config set appendonly yes # 开启AOF
3. config set save "" # 【可选】关闭RDB
4. config rewrite # 保存变更的配置到redis.conf