前言：redis是我们常用的缓存方式，今天就来介绍下两种持久化的方式吧，先科普概念，再实战操作
一、RDB
Redis将某一时刻的快照（备份的数据库数据）保存成一种称为RDB格式的文件中，这种格式是经过压缩的二进制文件。redis保存和恢复文件，如图1和图2所示。
保存RDB数据的命令：有两种，一个是save，一个是bgsave，一般用的都是bgsave命令。
1、save命令：save命令会阻塞redis服务器的进程，直到RDB文件创建完，在该期间，redis不能处理任何的命令请求，这就是save命令最大的缺陷。
2、bgsave命令：与save命令不同的是，bgsave在生成RDB文件时，会派生出一个子进程，子进程负责创建RDB文件，在此期间，主进程和子进程是同时存在的，因此不会阻塞redis服务器进程。
说明：（可用lastsave命令查看生成RDB文件是否成功）
RDB快照持久化数据的优缺点：
1、优点：
（1）、采用子线程创建RDB文件，不会对redis服务器性能造成大的影响；
（2）、快照生成的RDB文件是一种压缩的二进制文件，可以方便的在网络中传输和保存。通过RDB文件，可以方便的将redis数据恢复到某一历史时刻，可以提高数据安全性，避免宕机等意外对数据的影响。
（3）、适合大规模的数据恢复。
（4）、如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
2、缺点：
（1）、在redis文件在时间点A生成，之后产生了新数据，还未到达另一次生成RDB文件的条件，redis服务器崩溃了，那么在时间点A之后的数据会丢失掉，数据一致性不是完美的好，
如果可以接受这部分丢失的数据，可以用生成RDB的方式；
（2）、快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时，创建子线程和生成RDB文件会占用大量的系统资源和处理时间，对 redis处理正常的客户端请求造成较大影响。
（3）、数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
（4）、备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
触发RDB快照：
1、在指定的时间间隔内，执行指定次数的写操作
2、执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
3、执行flushall 命令，清空数据库所有数据，意义不大
4、执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义...也不大。
通过RDB文件恢复数据：
将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。
二、AOF
AOF是redis对将所有的写命令保存到一个aof文件中，根据这些写命令，实现数据的持久化和数据恢复。
AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。
Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF文件生成机制：
1、生成过程包括三个步骤：命令追加、文件写入、文件同步。
redis打开AOF持久化功能之后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录还没有写到appendonly.aof文件中。
然后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，
调用fsync函数即是文件同步的过程，只有经过了文件的同步过程，写命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的频率的选项。
AOF重写：
1、redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。
比如对key1初始值是0，调用incr命,100次，key1的值变为100，那么其实直接一句set key1 100 就可以顶之前的100局调用，AOF重写功能就是干这个事情的。
重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。
2、重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（太大了）。最后替换旧的aof文件
3、重写触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。
AOF优缺点：
优点：
1、提供了多种同步命令的方式，默认1秒同步一次写命令，做多会丢失1秒内的数据；
2、如果AOF文件有错误，比如在写AOF文件时redis崩溃了，redis提供了多种恢复AOF文件的方式，
例如使用redis-check-aof工具修正AOF文件（一般都是最后一条写命令有问题，可以手动取出最后一条写命令）；
3、AOF文件可读性交强，也可手动操作写命令。
4、数据的完整性和一致性更高
缺点：
1、AOF文件比RDB文件较大；
2、redis负载较高时，RDB文件比AOF文件具有更好的性能；
3、RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，
比如使用阻塞命令时，这些bug的场景RDB是不存在的。
4、因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
触发AOF快照：
根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。
根据AOF文件恢复数据：
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，
从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。
以上简单罗列了下两种快照的基本信息，更多详细信息可以参考：https://www.jianshu.com/p/cbe1238f592a，下面开始实战
三、实战RDB操作
打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容
（1）、RDB核心规则配置（重点）
save <seconds> <changes>
save 900 1
save 300 10
save 60 10000
说明：save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，
则将内存中的数据快照写入磁盘。若不想用RDB方案，可以把 save "" 的注释打开，下面三个注释。
（2）、指定本地数据库文件名，一般采用默认的 dump.rdb
配置：dbfilename dump.rdb
（3）、指定本地数据库存放目录，一般也用默认配置
配置：dir ./
（4）、默认开启数据压缩
配置：rdbcompression yes
说明：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。
1、配置save：设置了120S，修改3次，则持久化一次（shutdown和FLUSHALL也有生成快照的功能）
2、开始测试
3、通过RDB文件恢复数据
流程：
1、先备份一份dump.rdb为dump_bak.rdb（模拟线上）
2、flushall清空数据（模拟数据丢失........注意flushall也会触发rbd持久化）
3、将dump_bak.rdb替换为dump.rdb
4、重启redis服务，恢复数据
四、实战AOF操作
打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容
1、redis 默认关闭，开启需要手动把no改为yes
配置：appendonly yes
2、指定本地数据库文件名，默认值为 appendonly.aof
配置：appendfilename "appendonly.aof"
3、指定更新日志条件
配置：# appendfsync always
appendfsync everysec
# appendfsync no
配置说明：always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步
4、配置重写触发机制
配置：auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
配置说明：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。
1、修改配置appendonly为yes（需要重启redis）
2、开始测试
3、通过AOF文件恢复数据
流程：
1、执行flushall，模拟数据丢失
2、重启redis服务，恢复数据
3、修改appendonly.aof，模拟文件异常
4、重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。
5、使用redis-check-aof 校验appendonly.aof 文件。重启Redis 服务后正常。
注意：当你使用flushall清空数据的时候，重启redis服务发现数据没恢复，是因为FLUSHALL 命令也被写入AOF文件中，导致数据恢复失败。
只需要删除aof文件中的flushall就行了
五、总结
1、Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
2、RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
3、Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
4、AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
5、Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
6、若只打算用Redis 做缓存，可以关闭持久化。（RDB关闭：注释掉所有save，AOF关闭：appendonly为no）
7、若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。
以上就是文章的全部内容了，实战部分为本人亲测。