经常在目录下会看见一个dump.rdb的文件，
但是自己也很清楚不是自己手动创建的，而且删除后，一段时间后他又就出现了，很诧异。
当我们cat看下这个文件内容时，里面显示一堆乱码，其实里面是二进制的文件内容，不过我们可以通过redis-check-rdb dump.rdb 命令来了解下它
通过图片信息，我们可以知道目前redis持久化的版本、大小、生成时间、那个库、及redis里有多少值于过期情况等。
我们大概知道这些就OK了，但若你想知道里面的具体内容，可以通过rdbtools工具来查看。
OK，下面具体了解下Redis的两种持久化。
一、RDB
RDB是一种快照存储持久化方式，具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb，而在Redis服务器启动时，会
重新加载dump.rdb文件的数据到内存当中恢复数据。 ，触发 RDB 持久化过程分为手动触发和自动触发。
1、手动触发机制
手动触发分别对应 save 和 bgsave 命令:
·save 命令:阻塞当前 Redis 服务器，直到 RDB 过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
·bgsave 命令:Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。
除了执行命令手动触发之外，Redis 内部还存在自动触发 RDB 的持久化机制，例如以下场景:
1)使用 save 相关配置，如“save m n”。表示 m 秒内数据集存在 n 次修改时，自动触发 bgsave。
2)如果从节点执行全量复制操作，主节点自动执行 bgsave 生成 RDB 文件并发送给从节点。
3)执行 debug reload 命令重新加载 Redis 时，也会自动触发 save 操作。
4)默认情况下执行 shutdown 命令时，如果没有开启 AOF 持久化功能则自动执行 bgsave。
下图是bgsave流程解析
1、执行 bgsave 命令，Redis 父进程判断当前是否存在正在执行的子进程，如 RDB/AOF 子进程，如果存在 bgsave 命令直接返回。
2、父进程执行 fork 操作创建子进程，fork 操作过程中父进程会阻塞，通过 info stats 命令查看 latest_fork_usec 选项，可以获取最近一个 fork 操作的耗时，单位为微秒。
3、父进程 fork 完成后，bgsave 命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
4、子进程创建 RDB 文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行 lastsave 命令可以获取最后一次生成 RDB 的时间，对应 info 统计的 rdb_last_save_time 选项。
5、进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence 下的 rdb_* 相关选项。
这里可以用php code 模拟实现下save与bgsave的实现过程
使用pcntl_fork函数fork一个子进程实现异步
2、服务器配置自动触发
我们可以通过redis.conf配置文件指定选项
# 900s内至少达到一条写命令
save 900 1
# 300s内至少达至10条写命令
save 300 10
# 60s内至少达到10000条写命令
save 60 10000
当然，我们也可以在配置文件中指定dump.rdb的生成位置
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./
下面要讲的.aof生成的位置也是由这个配置决定的。
二、AOF
AOF(append only file)持久化:与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令到日志当中，并将这些写操作 以Redis协议追加保存到以后缀为aof文件末尾
默认情况下AOF功能是关闭的，开启需要设置配置文件（这跟mysql开启二进制日志类似，主要原因是消化性能）；
也是可以设置保存后的文件名；
appendonly yes
appendfilename "appendonly.aof"
#fsync持久化策略 一般情况我们都是选第二种
appendfsync always #每次操作直接生成持久化
appendfsync everysec #每秒 先将命令放到缓存，再打包生成
appendfsync no #一直将命令放到缓存
#自动触发aof是根据这俩个参数决定的
#代表当前 AOF 文件空间(aof_current_size)和上一次重写后 AOF 文件空间(aof_base_size)的比值。
auto-aof-rewrite-percentage 100
#表示运行 AOF 重写时文件最小体积，默认为 64MB。
auto-aof-rewrite-min-size 64mb
#如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件
aof-load-truncated yes
大家看到这里可以发现一个问题，由于AOF相较于RDB频繁保存，且AOF里都是命令，而RDB是所以结果的快照，所以相隔一段时间后，目录下.aof文件会比dump.rdb文件大很多。这也是在大量的写入和载入的时候，AOF的效率会比RDB低的原因
所以AOF还有一个重写机制bgrewriteaof
例如：将多条命令合并成一条命令
lpush list a
lpush list b
lpush list c
=> lpush list a b c
AOF 重写降低了文件占用空间。
除此之外，另一个目的是:更小的 AOF 文件可以更快地被 Redis 加载。
在目录生成的appendonly.aof文件，我们可以通过cat看里面的内容，都是一条条redis命令。
但是通过重写后，该文件就变成了二进制文件（Redis5以后的版本新增的特性，5以前的版本还是可以查看里面内容的）
当然，针对个人开发者来说，可以接受十几分钟或更多数据的丢失，大可选择RDB对Redis性能更加友好。
若只能接受秒级的数据丢失，那就的选择AOF了
持久化的配置方案
- 企业级的持久化的配置策略
save 60 10000:如果你希望尽可能确保说，RDB最多丢1分钟的数据，那么尽量就是每隔1分钟都生成一个快照，低峰期，数据量很少，也没必要
10000->生成RDB，1000->RDB，这个根据你自己的应用和业务的数据量，你自己去决定
AOF一定要打开，fsync，everysec
auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%，上次的两倍 auto-aof-rewrite-min-size 64mb: 根据你的数据量来定，16mb，32mb - 数据备份方案
1、写crontab定时调度脚本去做数据备份
2、每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
3、每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份
4、每次copy备份的时候，都把太旧的备份给删了
5、每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去【crontab】