RDB （Snapshotting）（快照）持久化和AOF（Append Only File）持久化
1.RDB（Snapshotting）（快照）持久化
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
查看dump.rdb存放路径
在自己linux环境中是 cd 到 redis的安装目录中去启动的
验证之后果然发现 出现了问题~ 问题的所在 就是 配置文件中的 ./ 这里的./不是指的是redis.conf 文件所在的文件路径
而是 执行命令的路径~ 所以会在根目录下~出现dump.rdb 文件
修改redis.conf 文件 dir 属性为 全路径之后 无论何种方式启动 都没有问题了。
所以总结 redis.conf 文件的 dir 属性 应该填写为 指定路径的全路径 不能使用 ./ 之类的 否在会在执行启动命令的目录下生成dump.rdb文件
若在etc文件夹下启动则会在etc下新建dump.rdb
可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内如超过10个key被修改，则发起快照保存
save 60 10000 #60秒内 如果超过10000 个key被修改，则发起快照保存
dbfilename 快照备份文件的文件名
dir 数据库快照备份的文件放置的路径
RDB优缺点:
优点：
1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
缺点：
1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE
SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求
redis> SAVE//等待直到RDB 文件创建完毕OK
和SAVE命令直接阻塞服务器进程的做法不同，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB 文件，服务器进程(父进程)继续处理命令请求
redis> BGSAVE//派生子进程，并由子进程创建RDB 文件Background saving started
rbd模式数据恢复
恢复数据 运行config get dir 获得文件的存储目录，将dump.rdb文件放入该目录下 启动redis会自动加载该文件的内容.
若启动时目录非 /usr/local/redis/etc 则不能恢复
当切换到 /usr/local/redis/etc 时恢复数据成功
2.AOF（ Append Only File ）持久化
redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)
当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）
appendonly yes//启用aof持久化方式
appendfilename appendonly.aof #AOF文件的名称，默认为appendonly.aof
appendfsync always//每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync 选项及同步频率
always ：每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能
everysec ：每秒执行一次同步，显式地将多个写命令同步到硬盘
no ：让操作系统来决定应该何时进行同步 完全依赖os，性能最好,持久化没保证
配置redis自动重写AOF文件的条件
auto-aof-rewrite-percentage 100# 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据
auto-aof-rewrite-min-size 64mb# 允许重写的最小AOF文件大小
Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少
启动服务在启动目录下可以看到appendonly.aof
这里来看一下记录首先设置name age hobby 接着关闭服务器server
查看appendonly.aof 发现操作redis都已经记录在appendonly.aof上了
以日志的形式来记录每个写操作（读操作不记录），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件
redis启动之初会读取该文件重新构建数据，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
这里重启服务器，命令 keys * 查看已有键。发现数据恢复。
优点：
每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
不同步：appendfsync no 从不同步
缺点：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
总结
客户端--->命令请求--->服务器 ------->网络协议格式的命令内容-->AOF文件
AOF 文件是一个只进行追加的日志文件
Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
AOF文件有序地保存了对数据库执行所有写入操作，这些写入操作作为redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松
对于相同的数据集来说，AOF文件的体积通常大于RDB文件的体积，根据所使用的fsync策略，AOF的速度可能会慢于RDB
如何选择使用哪种持久化方式？
一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免 AOF 程序的某些 bug 。
其他注意点：
当redis需要中途开启AOF存储方式时，在充redis服务之前一定要拷贝一份当前的rbd文件，因为重启后会优先读取.aof文件，当第二次重启时，会将aof文件的数据存储到dump.rdb文件当中，这就会造成数据的丢失.
如果说我们将现在的数据存储到aof文件当中，在开启AOF存储方式时，那么当前的数据也会被AOF读取.
那么再开启AOF之前一定要运行bgrewriteaof，这样先会生成一个aof文件.（如果之前已经存在则不需要使用该命令）
请始终牢记AOF的优先级高于Snapshot的优先级