redis支持三种方式的持久化
1.RDB(Redis DataBase)
2.AOF(Append Only File)
3.混合方式
一.RDB(Redis DataBase)
.RDB：也称快照方式，配置每隔一段时间执行一次全量备份，Redis将数据集快照保存在磁盘上，保存在一个名为dump.rdb的二进制文件中，也可以手动调用SAVE或BGSAVE命令。redis启动后会自动读取dump.rbd中的内容写入到redis中（前提没开aof）
RDB的原理：
Redis会单独创建（fork）一个子进程来进行持久化，子进程和主进程完全一致。会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。保存的文件是dump.rdb
fork:
fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
RDB优点：
非常适合做备份与回滚到指定的时间点，例如我们可以每天晚上2点执行定时计划全量备份一次Redis中的数据，以后我们进行恢复的时候可以将Redis恢复到指定的时间点的版本；与AOF相比使用RDB方式性能较高；与AOF相比Redis重启的速度较快；当AOF文件变的过大时可以自动进行重写（2.4版本以上，2.4以下版本需要手动调用）
RDB的缺点:
相比AOF丢失的数据可能会更多，比如设置5分钟备份一次快照，那么最多会损失5分钟的数据。RDB的缺点是最后一次持久化后的数据可能丢失。
触发RDB进行保存：
Save：save时只管保存，其它不管，全部阻塞
BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave
命令获取最后一次成功执行快照的时间。
flushall:清空也可以
flushdb:同上
满足配置文件中的设置（redis.conf）:
save < seconds > < changes >
每秒中达到多少次写操作就触发，例如save 900 1,没五分钟有一个的写（增，删，改）操作就保存，自己可以根据实际修改。
大牛的建议配置：
一分钟内修改1W次
5分钟内修改10次
15分钟内修改1次
二.AOF(Append Only File)
AOF: 以追加的方式记录Redis的写操作，并在Redis重启时进行重放（与MySQL的binlog日志的原理是一样的）。当AOF日志过大时，redis支持日志重写。【这里提供一个小知识点，在Redis中是先执行命令再记录日志到AOF，这也是Redis事务不支持回滚的原因：即使发生异常，没有可以用来执行回滚操作的日志。而传统的数据库例如MySQL都是先做日志然后再做操作，所以能够支持回滚】，保存时appendonly.aof文件
AOF默认是关闭的，配置文件（redis.conf）写着appendonly no
如果我们需要开启AOF则是需要将no改为yes。
触发条件：
开启后的每一次写（增，删，改），flushall，flushdb都会被立即写入到追加到aof文件中。展示appendonly.aof文件记录的内容。set操作被记录到文件中
优点：
如果不考虑性能，AOF可以最大限度保证数据完整性，可以设置每发生一次写操作就调用一次fsync函数；更加灵活，可以使用不同的fsync策略，完全不使用fsync，每秒使用fsync（默认），以及每次查询时使用fsync；
缺点：
与RDB方式相比，相同数据集大小AOF占用空间更大（与之相关有aof文件的重写），恢复速度慢于rdb；若调用fsync的频率过快，性能会变差；aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
重写（rewrite）: AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集（比如将10000个incr key转换为incyby 10000）.可以使用命令bgrewriteaof。
重写原理： AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
重写触发的机制： Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发，redis.conf配置文件中有写着
同步的策略：
每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失，默认出厂设置
不同步：appendfsync no 从不同步
三.混合方式（4.0版本之后才有)
这也是官方的推荐模式
当两者同时开启，相当于同时有dump.rdb和appendonly.aof文件。此时每次重启redis，首先加载的的appendonly.aof.这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志。
开启混合模式：
aof-use-rdb-preamble yes
使用bgrewriteaof重写AOF，此时的aof文件格式（下面两种图片来其他博客）
Redis在重启时，先重写rdb到内存，然后在重写aof到内存，重启效率高，还能减少数据的丢失。
持久化文件有错误的修复：
dump.rdb: redis-check-dump --fix rdb文件的路径和名字
appendonly-aof: redis-check-aof --fix aof文件的路径和名字
推荐一位大佬的博客：https://blog.csdn.net/yhl_jxy/article/details/91879874