redis启动之后，redis会将数据load到内存中，之后的运算都在内存中进行，这是redis速度很快的最主要原因。
redis提供了两种持久化的方式：RDB和AOF。
一、RDB快照
默认情况下，redis将内存中的数据保存在dump.rdb的二进制文件中。
查看配置文件
# save 900 1 # save 300 10 save 60 1000
举例说明save 60 1000：在60s内有1000个键被改动，触发持久化。
当然还可以手动执行命令生成RDB快照，save和bgsave，每次执行都会生成新的快照，覆盖原有文件。
save命令是同步生成快照，会阻塞主进程，但不会消耗额外内存。
bgsave是异步的，bgsave子进程是主进程fork生成的，不会阻塞客户端的命令，但是会消耗额外内存。
二、AOF持久化
使用RDB的方式做持久化，如果发生故障，可能会丢失最近的数据。
AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中。
开启AOF持久化
appendonly yes
重启redis之后，每次使用改变数据的命令，redis都会将这个命令追加到appendonly.aof文件中。redis重启时，程序自动通过aof文件恢复数据。
配置fsync的时机
# 每次有命令就追加
# appendfsync always
# 每秒fsync一次
appendfsync everysec
# 将写入交给操作系统决定
# appendfsync no
推荐使用每秒fsync一次，保证安全的同时能兼顾到速度。
使用aof的方式，文件中可能会有很多重复的命令，占用空间。比如连续执行了多次incr命令。redis提供了AOF重写的方式，合并一些命令，使文件更小
# 是否开启AOF no-appendfsync-on-rewrite yes # 上一次AOF重写，文件大小增长了100%再次触发重写 auto-aof-rewrite-percentage 100 # AOF文件至少要达到64mb才进行重写 auto-aof-rewrite-min-size 64mb
进入客户端可以使用bgrewriteaof命令重写，redis会fork一个子进程去处理，并不会影响redis处理正常的命令。查看aof文件会发现部分命令已经合并。
RDB方式和AOF方式对比：
RDB快照文件体积小(二进制数据文件)，恢复速度快，但是容易丢数据
AOF快照文件体积小大(存储的是命令)，恢复速度慢，但是比较安全，数据不易丢失
三、混合持久化
针对RDB和AOF的特性，redis4.0版本之后推出了混合持久化的模式，要先开启aof持久化
# 开启混合持久化
aof-use-rdb-preamble yes
如果开启了混合持久化，aof重写时会将此刻之前的内存做RDB快照处理，并且将快照和增量的数据都写入文件再完成appendonly.aof文件替换。这样文件内容包含二进制数据和命令，redis重启时恢复数据的速度会提升。