RDB持久化方式：
save 60 10000，60秒内有1000个键发生了改变，则进行一次RDB快照，可以使用多条策略来控制持久化频率。
RDB可以看作是redis在某一时间点上的快照，适用于备份和灾难恢复。在执行持久化保存rdb文件时，redis调用fork创建出一个子进程，子进程将数据保存到一个临时文件(tem-<redis-pid>.rdb)中，当子进程完成转储过程后，这个临时文件会被重命名为dbfilename定义的名字并覆盖旧rdb文件。由于使用了写时复制(copy-on-write)，所有子进程不会使用redis占用同等的内存。
AOF持久化方式：
appendonly yes，开启AOF功能
AOF的运作方式是不断地将命令追加到aof文件的末尾。首先命令会被写入缓冲区，然后通过系统调用fsync()将缓冲区命令刷新到磁盘中，这是一个阻塞调用，只有磁盘设备反馈缓冲区命令写入完成后才会返回。redis可以在不打断客户端情况下，对aof文件重写。
RDB和AOF结合使用(redis4.x)：
aof-use-rdb-preamble yes，开启rdb和aof混合功能。
在重写aof文件时，redis首先会把数据集以RDB格式转储到内存中并作为aof文件的开始部分，在重写之后，redis继续使用传统的AOF格式记录写入的命令。
RDB优劣性：
- RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本。
- RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。
- RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。
- 比起AOF，在数据量比较大的情况下，RDB的启动速度更快。
- RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。
- RDB使用
fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。
AOF优劣性：
- 可以制定不同的fsync策略：no fsync、everysec fsync一次和always fsync。默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。
- AOF日志文件是一个只进行追加的文件。即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。
- 当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完，Redis会把新旧文件进行切换，然后开始继续把数据写到新文件上。
- AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。假设你不小心执行了FLUSHALL命令，但只要AOF文件未被重写，那么只要停止服务器，移除AOF文件末尾的FLUSHALL命令，并重启Redis，就可以将数据集恢复到FLUSHALL执行之前的状态。
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略，AOF的速度可能会慢于RDB。在一般情况下，每秒fsync的性能依然非常高，而关闭fsync可以让AOF的速度和RDB一样快，即使在高负荷之下也是如此。