很多概念官网都有，我CV过来意义不大，概念还是建议不要看博客，去官网多花点时间看看吧，RDB和AOF到底哪个好啥时候用哪个官网说得也很明确了。下面我就只和大家分享一些值得注意的细节：
目录直通车
一、RDB（Redis Database） 之 SNAPSHOTTING 快照
（1）如何配置RDB
（2）关闭RDB
（3）rdbcompression的配置
（4）rdbchecksum的配置
（5）命令是save或bgsave
二、AOF（Append Only File）
（1）何时使用AOF
（2）AOF的文件修复
（3）appendfsync
（4）no-appendfsync-on-rewrite
（5）Rewrite
三、配置建议
先看一下官网对 RDB 与 AOF 的描述：
- The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
- the AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log on background when it gets too big.
- If you wish, you can disable persistence at all, if you want your data to just exist as long as the server is running.
- It is possible to combine both AOF and RDB in the same instance. Notice that, in this case, when Redis restarts the AOF file will be used to reconstruct the original dataset since it is guaranteed to be the most complete.
下方中文描述略有偏差，强烈建议强迫一下自己阅读上面的英文描述。
Redis 提供了多种不同级别的持久化方式：
- RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
- AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
- Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
- 你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
一、RDB（Redis Database） 之 SNAPSHOTTING 快照
（1）如何配置RDB
1、下面是默认的配置，把下面的记住，面试会问的，这个配置在 conf 的SNAPSHOTTING 这个位置。
save 900 1
save 300 10 # 5分钟内，只要修改了1次就在第五分钟的时候做一次备份，下面依次类推
save 60 10000
2、还有一种可能性，当某个KV非常重要的时候，需要马上备份，只需要在这个KV存进去之后，执行一个save即可手动备份。
（2）关闭RDB
save设置成空字符串或者直接注释掉。
save ""
此外，在conf里面有个Stop-writes-on-bgsave-error:true 这个默认配置，如果在备份时出错了，redis将会停止写入操作；如果你将true改成false之后，表示不在乎这个数据的一致性 或者是已经有了其它的解决方式（比如后期重改数据）。
（3）rdbcompression的配置
rdbcompression：对于存储到磁盘中的快照 rdb 文件是默认使用LZF算法压缩存储的，显然会消耗CPU资源但非常细微，如果你不需要压缩想要节省CPU资源，把这个设置为 no 就关了。
（4）rdbchecksum的配置
rdbchecksum：在上面压缩完了之后，也就是说快照已经存好了，此时redis使用CRC64这个算法来进行数据校验，这个虽然是好事情，但是这样做会增大约10%的性能消耗，如果想要高性能的话，可以把这个关了，不缺这点性能建议还是不要关。
（5）命令是save或bgsave
save:save时只管保存，其它不管，全部阻塞。
bgsave:redis在后台异步备份，同时还能响应请求；可以通过lastsave 来获取最后一次执行快照的时间。
二、AOF（Append Only File）
多的概念不讲，只讲一句话：AOF是以日志的形式来记录每一条命令。
（1）何时使用AOF
RBD的问题是什么？fork消耗多少内存先不说，最大的缺陷是丢失数据的风险很大。AOF解决了这个问题，最多也就丢失1秒钟的数据。那么就用AOF好了，干嘛还用RDB？接着往下阅读
如果此时像抖音视频，10分钟就可能有一万个赞，如果抖音使用的是redis ，这一万个点赞就会执行 一万次 incr ，AOF就会存储一万个 incr ，当然这可不是一个视频，备份当然没问题，如果是一万个视频每个视频都有一万个赞，那么这个备份文件执行备份的时候，会花多久？所以像这样的大数据备份，最两种方式都用上。
如果是执行的FULSALL这个命令，appendonly.aof 这个文件同样会记录下来，在恢复之前必先从aof 里面删除这个命令，在官网是如下描述的：
（2）AOF的文件修复
还有aof这个文件挂了的情况，比如说，redis正在按照aof文件恢复的时候，突然断电，可能就会导致有有其它的乱码写入这个文件，当然 shutdown 的时候会自动生成一个dump.rdb 的文件，但注意 aof 的优先级比rdb 更高，所以redis 启动恢复的时候去扫描 aof 文件。若 aof 文件里面有乱码，恢复不成功，可以使用官方提供的 redis-check-aof -fix appendonly.aof 来修复这个文件，这会将不符合 redis语法规范的东西全部删除。
AOF 和 RDB 在没有出现问题的情况下是可以同时执行的。
AOF and RDB persistence can be enabled at the same time without problems.
（3）appendfsync
如下图官网所示，有三种模式
1、always：同步持久化，每次数据变更会立即记录到磁盘，消耗资源较大但数据完整性好。
2、everysec：默认配置，每一秒记录，如果一秒宕机，就会丢失这1s的数据。
3、no：关了。
（4）no-appendfsync-on-rewrite
配置文件里面是这样描述的，重写的时候是否可以运用 appendfsync 默认为no的原因是保证数据的安全性。
（5）Rewrite
aof 在生产环境里面是越来越大的（废话），aof 采用了文件追加方式，为了避免文件越来越大的此种情况，新增了重写机制，当AOF文件大小超过了设定的阙值时，redis就会启动Aof 文件的内容压缩。只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof。
重写的原理
aof文件持续增大的时候，会fork出一条新进程将文件重写（先写临时文件在rename），遍历新进程的内存中数据，每条记录有一条set语句。重写aof 文件的操作，不会读取旧的aof 文件，而是将整个内存中的数据库内容用命令的方式来重写一个新的aof文件，与快照的那种方式有点类似。
配置文件里面有以下默认配置：
# 重写的百分比
auto-aof-rewrite-percentage 100
# 重写的基准值
auto-aof-rewrite-min-size 64mb三、配置建议
1、rbd 的配置仅保存 save 900 1 就够了。
2、建议开启AOF虽然会持续消耗IO，但是即使在容灾的情况下最多也只会丢失不超过2s的数据，AOF 的基准值设为 5G或以上，目的是减少AOR Rewrite的频率。
