Redis在开发中最常用的NoSql数据库，但因为是存储的缓存中，所以有可能会造成数据的丢失，因此就有了Redis持久化机制。
Redis提供两种持久化机制，分别为RDB（默认）和AOF，Redis4.0后支持RDB和AOF两种持久化机制混合使用，所以存在三种持久化策略。
一、RDB持久化
Redis 采用操作系统的多进程 COW（Copy On Write）机制实现快照持久化。在进行持久化操作时，通过 fork () 函数产生一个子进程，将快照持久化的任务完全交由子进程处理，而父进程则继续处理客户端的读写请求。当子进程对当前内存中的数据进行持久化时，不会对当前的数据结构进行修改。若父进程接收到读写请求，会将处理的那一部分数据复制一份到内存中，并对复制后的数据进行修改。因此，即便对某个数据进行了修改，Redis 持久化到 RDB 中的数据仍是未修改的数据，这也是 RDB 文件被称为 “快照” 文件的原因所在。子进程所看到的数据在其被创建的瞬间便已固定下来，父进程修改的某个数据只是该数据的复制品。
优点：
- 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了Redis的高性能；
- 相对于数据集大时，比AOF的启动效率更高；
缺点：
- RDB 是间隔一段时间进行持久化，如果在持久化时Redis发生故障，会发生数据丢失;
二、AOF持久化
AOF(Append-only file)日志存储的是redis服务器的顺序指令序列，即对内存中数据进行修改的指令记录，类似于MySQL的binlog日志。当redis收到修改指令后，先进行参数校验，如果校验通过，先把该指令存储到AOF日志文件中，再执行该指令。
当redis重启后，可以读取AOF文件中的指令，进行数据恢复，恢复的过程就是把记录的指令再顺序执行一次，这样就可以恢复到重启之前的状态了。
优点：
- AOF持久化可以配置appendfsync属性，有always属性，每进行一次命令操作就记录到AOF文件中一次；
- 通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一致性问题；
缺点：
- AOF文件总体大小比RDB文件大很多，并且恢复时速度很慢；
三、混合持久化
将RDB文件和增量AOF日志文件一起存放，而AOF日志不再是全量的redis指令，而是RDB持久化开始之后的这段时间发生的增量AOF日志，这样这部分AOF日志就会小很多。
示例图如下：
需要注意的是，如果同时有RDB文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整。