redis是一个内存型数据库，这就意味着，当主机重启或者宕机时，内存中的数据会被清空，redis可能会丢失数据。为了保存数据，实现数据持久化就必须要有一种机制，可以将redis数据库的数据保留在硬盘上，在下次使用前再读回内存，这种机制就叫做redis的持久化。在redis中实现这种机制的有两个方法，RDB和AOF。
1.RDB
1.1 RDB原理
RDB又叫做快照（RDB snapshhot）是一种全量备份，用二进制序列化形式存储内存数据，其存储结构十分紧凑。由于redis的单线程属性，不能在执行主程序时进行I/O操作，而快照又必须进行I/O操作。因此在redis中快照的实现使用了多进程的COW（copy and write）机制来实现。在持久化时调用glibc函数fork（增加分支）一个子进程，将持久化任务甩给子进程来处理，父进程继续进行客户请求处理。子进程只复制其产生的一瞬间的内存数据，与此时父进程的修改操作无关，因而redis的这种持久化又叫做快照。
1.2 RDB使用
redis的RDB是默认开启的。关闭RDB需要找到redis.conf文件，关闭RDB需要找到redis.conf文件，其中SNAPSHOTTING模块默认配置如下：
# save ""
save 900 1
save 300 10
save 60 10000
要关闭时将第一行的注释取消，将剩下几行注释掉。
形如save sec times配置是指当redis在sec秒内修改了数据times次时触发RDB。开启时达到触发条件后在硬盘上会生成一个.rdb文件，这个就是快照产生的数据，文件名可通过修改配置文件dbfilename dump.rdb语句来完成，文件路径修改dir ./语句，注意dir后面所跟的是不包括文件名的路径。
2.AOF
2.1 AOF原理
AOF日志存储了redis服务器的顺序指令序列，且只记录修改操作。redis通过在重启后重放AOF日志中的指令来完成持久化。当服务器收到修改指令操作后会进行指令的参数检验、逻辑处理，确保没有问题后才会写入AOF日志，保证存储的指令都是正确的。这也就意味着当服务器运行时间相当长之后，AOF日志会非常的大，因此必须定期进行AOF的瘦身（重写）。
redis提供了bgrewriteaof指令来对AOF日志进行瘦身，其原理就是开辟一个子进程对内存进行遍历，转换成一系列redis操作指令，序列化到一个新的AOF日志文件中。当序列化结束后再操作过程中发生的AOF增量追加到新的AOF日志文件中，追加完毕就立即用新日志文件代替旧的日志文件，瘦身就完成了。
在生产环境下，AOF的操作通常是1s写一次，因为这个操作是I/O操作因而速度很慢，如果改为只让系统决定何时同步磁盘会导致数据安全性下降，而当改为每次修改指令就触发一次会导致速度很慢。
2.2 AOF使用
AOF默认是关闭的，可以通过将配置文件APPEND ONLY MODE模块下appendonly no语句中的no改为yes来开启，修改：appendfilename "appendonly.aof"语句修改文件名。触发策略有以下3种：
# appendfsync always
appendfsync everysec
# appendfsync no
默认每秒钟写一次，第一行表示每次写操作都立刻写入到aof文件。第3行表示不要立刻刷，只有在操作系统需要刷的时候再刷。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
上面两个配置是redis的重写策略，第一行表示当AOF日志的大小达到指定百分比（对比上次重写时AOF文件的大小），Redis能够通过 BGREWRITEAOF 自动重写AOF日志文件。第二行表示达到指定大小就重写。
3.混合持久化
重启redis服务时，由于重写策略的缘故，RDB至少5分钟才会重写一次，因此可能会丢失大量的数据，而采用AOF持久化又会导致文件体积过大，所以在redis4.0之后采用了混合策略来实现持久化。
其实现原理为当redis重启时，先加载rdb的内容，然后在重放增量AOF的日志，使得重启效率大幅提升。开启混合持久化需要在配置文件中配置两个地方：
appendonly yes
aof-use-rdb-preamble yes