redis中的数据存储在缓存中，如果没有持久化的策略，Redis一旦宕机，那么将会导致数据丢失；因此redis提供了以下两种持久化方式：RDB和AOF
一般来说，大部分公司对这两种方式都是同时开启的
一、RDB
RDB策略全称Redis database backup file（Redis数据备份文件），也被叫做redis数据快照；简单来说就是把缓存中所有的数据都记录到磁盘中。
当redis故障重启的时候，从这个快照文件中读取保存的数据以实现数据恢复
数据RDB有两种方式：
1、手动redis-cli执行保存快照：
1、使用save命令，用主线程来将缓存中的数据保存到快照文件中
这种方式如果数据量大的话，会阻塞业务，一般不用
2、使用使用bgsave命令，开启一个子进程来执行RDB，这样你在后面备份，不影响正常的主业务允许
2、自动保存快照频率
自动保存快照是开启一个子进程进行定时写入RDB文件，不会影响主进程；在redis.conf中配置
# 代表：在900秒内，如果有1条redis中的key被修改，那么则执行bgsave保存快照
save 900 1
# 代表：在300秒内，如果有10条redis中的key被修改，那么则执行bgsave保存快照
save 300 10
# 代表：在60秒内，如果有10000条redis中的key被修改，那么则执行bgsave保存快照
save 60 1000 具体使用什么频率来保存，根据不同的业务场景来定
3、RDB的原理
bgsave开始时会fork主进程的到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件。
fork采用 的是copy-only-write技术：
- 当主进程执行读操作时，主进程直接访问共享内存
- 当主进程执行写操作时，则主进程会把要写的数据拷贝一份出来进行写入，此时页表进行读这一个数据时，也会访问这个“副本”，最后把副本写入共享内存，这样就避免了脏数据的问题
二、AOF
AOF全称为Append only file（追加文件）。Redis处理的每一个写命令都会记录在AOF文件中，可以看做是命令日志文件，什么时候写入数据，对哪条数据进行了修改都有记录。
1、如何开启AOF
老版本的redis，默认是不开启AOF功能的，需要修改redis.conf配置文件来开启AOF
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"2、AOF的命令记录频率
可以在redis.conf配置文件中修改：
# 1、表示每执行一次写命令，立即记录到AOF文件
# 优点：可靠性性高，几乎不会丢数据；缺点：每次操作都写文件，性能低
appendfsync always
# 2、写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区的数据写入AOF文件，是默认方案
# 优点：性能适中；缺点：如果Redis宕机，可能丢失这一秒的数据
appendfsync everysec
# 3、写命令执行完先放入AOF缓冲区，然后由操作系统决定何时将缓冲区内容写入磁盘
# 优点：性能最好；缺点：如果Redis宕机，可能丢失大量数据
appendfsync no
因为是记录Redis的写入命令，这导致AOF文件会比RDB文件大得多。而且AOF文件会记录对同一个key的多次写操作，但是只有最后一次写操作才有意义（因为最后一次修改的才需要保存嘛，前面的留着干啥）
通过手动执行bgrewriteaof命令（background rewrite aof后台重写aof文件）可以让aof文件执行重写功能，用最少的命令达到同样的效果（Redis恢复，以及可以减少文件的大小）
Redis也可以在触发阈值时自动去重写AOF文件。阈值可以在redis.conf文件中配置：
# AOF文件比上次文件，增加超过多少百分比时，则触发重写
# 100代表如果AOF文件大小超过100%了（翻倍），则重写一次，也可以配置90 80之类的
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上，才触发重写
# 代表只有AOF文件超过64M大小了，才会重写
auto-aof-rewrite-min-size 64mb三、RDB和AOF的优缺点对比
在现实开发场景中，大部分公司都是两种策略都开启的
