RDB 持久化
可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
AOF 持久化
记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。
RDB持久化优点
1. RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如，你可能想要每小时归档最近24小时的RDB文件，每天保存近30天的RDB快照。这允许你很容易的恢复不同版本的数据集以容灾。 2. RDB非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心。 3. RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。 4. RDB在重启保存了大数据集的实例时比AOF要快。
RDB持久化缺点
当你需要在Redis停止工作(例如停电)时最小化数据丢失，RDB可能不太好。你可以配置不同的保存点(save point)来保存RDB文件(例如，至少5分钟和对数据集100次写之后，但是你可以有多个保存点)。然而，你通常每隔5分钟或更久创建一个RDB快照，所以一旦Redis因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。
RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且CPU性能不够强大的话，Redis会停止服务客户端几毫秒甚至一秒。AOF也需要fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。
RDB持久化基本配置
save 900 1 save 300 10 save 60 10000 配置分别表示： 900秒（15分钟）内有1个更改 300秒（5分钟）内有10个更改 60秒内有10000个更改 当达到以上定义的配置时间时，就将内存数据持久化到磁盘。
RDB持久化高级配置
save 900 1 save 300 10 save 60 10000 配置分别表示： 900秒（15分钟）内有1个更改 300秒（5分钟）内有10个更改 60秒内有10000个更改 当达到以上定义的配置时间时，就将内存数据持久化到磁盘。
AOF持久化基本配置
appendonly yes/no appendfsync always appendfsync everysec appendfsync no 配置分别表示： 是否打开aof日志功能 每1个命令,都立即同步到aof 每秒写1次 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof
AOF持久化高级配置
no-appendfsync-on-rewrite yes/no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 配置分别表示： 正在导出rdb快照的过程中,要不要停止同步aof aof文件大小比起上次重写时的大小,增长率100%时重写,缺点:业务开始的时候，会重复重写多次。 aof文件,至少超过64M时,重写
RDB到AOF切换
no-appendfsync-on-rewrite yes/no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 配置分别表示： 正在导出rdb快照的过程中,要不要停止同步aof aof文件大小比起上次重写时的大小,增长率100%时重写,缺点:业务开始的时候，会重复重写多次。 aof文件,至少超过64M时,重写
redis中有哪些持久化的方式？有什么区别？
rdb: 基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能
aof: 以追加的方式记录redis操作日志。可以最大程度的保证redis数据安全，类似于mysql的binlog