如果作为mysql的缓存，则两个都不需要配
如果作为单独数据库则两个都配

RDB

RDB简介

（Redis DataBase)
RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
工作机制：每隔一段时间，就把内存中的数据保存到硬盘上的指定文件中。
RDB是默认开启的！
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
RDB的缺点是最后一次持久化后的数据可能丢失。

RDB保存策略

save 900 1 900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10 300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000 60 秒内如果至少有 10000 个 key 的值变化，则保存
save “” 就是禁用RDB模式；

RDB常用属性配置

属性	含义	备注
save	保存策略
dbfilename	RDB快照文件名
dir	RDB快照保存的目录	必须是一个目录，不能是文件名。最好改为固定目录。默认为./代表执行redis-server命令时的当前目录！
stop-writes-on-bgsave-error	是否在备份出错时，继续接受写操作	如果用户开启了RDB快照功能，那么在redis持久化数据到磁盘时如果出现失败，默认情况下，redis会停止接受所有的写请求
rdbcompression	对于存储到磁盘中的快照，可以设置是否进行压缩存储。	如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。
rdbchecksum	是否进行数据校验	在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

RDB数据丢失的情况

两次保存的时间间隔内，服务器宕机，或者发生断电问题。

RDB的触发

默认开启

持久化机制：在持久化的时候会调用linux的fork函数，复制一个与主进程一样的进程，主进程共享资源，计算器等

   ** 自动触发**<br />save time change<br />解释：在time时间内对Key执行了change次写的操作，此时会触发rdb

手动触发
save：复制的进程独享资源，持久哈的性能比较高，会主色客户端操作
bigsave：复制的进程与主进程共享资源，此时持久化性能相对比较慢，不会阻塞客户端操作。
flushall：先清空再保存，也会产生dump.rdb，但里面是空的，没有意义。
shutdown：停止服务保存数据

RDB的优缺点

缺点：可能丢失最后一段时间的数据
优点：

内存占用空间比AOF小—>只有一个文件
数据恢复速度比AOF快—>适合容灾备份
AOF
（append only file）
AOF简介
l AOF是以日志的形式来记录每个写操作，将每一次对数据进行修改，都把新建、修改数据的命令保存到指定文件中。Redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
l 默认不开启，需要手动开启
l AOF文件的保存路径，同RDB的路径一致。
l AOF在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！
l 当RDB和AOF同时存在时，按照AOF来恢复。因为AOF是对RDB的补充。备份周期更短，也就更可靠。

AOF保存策略

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！
appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即1秒钟的数据）。
appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒 fsync 一次，这种 fsync 策略可以兼顾速度和安全性。

redis

AOF常用属性
| 属性 | 含义 | 备注 | | —- | —- | —- | | appendonly | 是否开启AOF功能 | 默认是关闭的 | | appendfilename | AOF文件名称 | | | appendfsync | AOF保存策略 | 官方建议everysec | | no-appendfsync-on-rewrite | 在重写时，是否执行保存策略 | 执行重写，可以节省AOF文件的体积；而且在恢复的时候效率也更高。 | | auto-aof-rewrite-percentage | 重写的触发条件 | 当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写 | | auto-aof-rewrite-min-size | 设置允许重写的最小aof文件大小 | 避免了达到约定百分比但尺寸仍然很小的情况还要重写 | | aof-load-truncated | 截断设置 | 如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load |

AOF文件的修复

如果AOF文件中出现了残余命令，会导致服务器无法重启。此时需要借助redis-check-aof工具来修复！
命令： redis-check-aof —fix 文件

AOF的优缺点

优点：
l 备份机制更稳健，丢失数据概率更低
l 可读的日志文本，通过操作AOF稳健，可以处理误操作

缺点：
l 比起RDB占用更多的磁盘空间
l 恢复备份速度要慢
l 每次读写都同步的话，有一定的性能压力
l 存在个别Bug，造成恢复不能

备份建议

如何看待数据“绝对”安全

Redis作为内存数据库从本质上来说，如果不想牺牲性能，就不可能做到数据的“绝对”安全。
RDB和AOF都只是尽可能在兼顾性能的前提下降低数据丢失的风险，如果真的发生数据丢失问题，尽可能减少损失。
在整个项目的架构体系中，Redis大部分情况是扮演“二级缓存”角色。
二级缓存适合保存的数据
Ø 经常要查询，很少被修改的数据。
Ø 不是非常重要，允许出现偶尔的并发问题。
Ø 不会被其他应用程序修改。
如果Redis是作为缓存服务器，那么说明数据在MySQL这样的传统关系型数据库中是有正式版本的。数据最终以MySQL中的为准。

官方建议

如果作为数据库官方推荐两个都用；
如果对数据不敏感，可以选单独用RDB；
不建议单独用AOF，因为可能出现Bug;
如果只是做纯内存缓存，可以都不用

持久化

RDB