redis是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据安全性产生了新的问题，即当redis所在服务器发生宕机后，redis数据库里的所有数据将会全部丢失。为了解决这个问题，redis提供了持久化功能——RDB和AOF。通俗的讲就是将内存中的数据写入硬盘中。
一、RDB持久化
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件。当redis所在的服务器发生宕机，重启会自动载入rdb文件，恢复数据。实际生产中，rdb备份文件通常保存在两个服务器上。防止服务器发生故障，备份文件也丢失。
1、自动触发
在conf配置文件中：
save 900 1 save 300 10 save 60 10000
注意：你可以注释掉所有的 save 行来停用保存功能。也可以直接一个空字符串来实现停用：save ""
当上面三个条件中有一个符合就会触发RDB
2、手动触发
当然如果不满足上面条件，也可以手动触发RDB
1）、SAVE是阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。
2）、BGSAVE属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。
redis 127.0.0.1:6379> set k1 v1 OK redis 127.0.0.1:6379> save OK redis 127.0.0.1:6379>
3、优缺点
优点：
1、采用这种方式，一旦系统出现故障，就可以用rdb文件进行恢复
2、在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
3、RDB采用全量写入，当数据发生变化，就会生成新的rdb文件来替代旧的rdb文件，相对于AOF，RDB恢复启动效率更高
缺点：
1、系统一旦在定时持久化之前出现宕机现象，最后一次没有来得及写入磁盘的数据都将丢失。
2、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
一、AOF持久化
与RDB的保存整个redis数据库状态不同，AOF是通过保存对redis服务端的写命令（如set、sadd、rpush）来记录数据库状态的，即保存你对redis数据库的写操作，只许追加文件，不可改写文件，redis启动之初会读取该文件将写指令从前到后执行一次以完成数据的恢复工作。
1、配置
appendonly yes appendfilename "appendonly.aof"
appendonly no修改为appendonly yes
appendfsync always appendfsync everysec appendfsync no
no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
always表示每次写入都执行fsync，以保证数据同步到磁盘。
everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
如果redis开启了AOF持久化功能，那么当redis服务重启时会优先使用AOF文件来还原数据库。
2、aof文件修复
万一aof文件遭到破坏，就可以使用命令redis-check-aof.exe appendonly.aof来修复。
3、优缺点
优点：
1)、Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。默认策略是每秒同步，效率高，所一旦系统出现宕机现象，那么只会丢失一秒钟之内修改的数据。
2)、采用增量写入的方式，在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。即使出现乱码，也可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3）、如果日志过大，Redis可以自动启用rewrite机制。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。用户可以通过该文件完成数据的重建。
缺点：
1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。