Redis--持久化方案

Redis为什么要做持久化
redis本身运行时数据保存在内存中，在关闭redis的进程或者关闭计算机后数据肯定被会操作系统从内存中清掉。redis默认采用了一种持久化方式，即RDB （Redis DataBase）——可以在redis的目录中找到dump.rdb文件，这就是使用RDB方式做持久化后生成的数据文件。所以，redis如果没有做持久化，在重启redis后，数据会丢失，而redis默认就采用了一种持久化方式，即RDB（也称快照）。
RDB持久化(默认开启这种方式)
手动和自动两种机制
手动机制:可以使用save或者bgsave命令手动将内存中的数据dump到磁盘。
自动机制:当redis启动的时候初始化一个定时函数，每隔一段时间会执行一次bgsave,将内存中的数据dump到硬盘。

save命令：阻塞当前Redis主线程 ，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞。线上环境不建议用 。

bgsave命令：bgsave是一个异步式的命令，和 SAVE 命令直接阻塞服务器进程的做法不同，bgsave命令会派生出一个子进程，由子进程负责创建 RDB 文件，服务器进程（父进程）继续处理客户的命令。
Redis 在服务端进程会为 bgsave命令单独创建（fork）一个子进程，并由子进程在后台完成 RDB 的保存过程，在操作完成之后通知父进程然后退出。在整个过程中，服务器进程只会消耗少量时间在创建子进程和处理子进程信号量上，其余时间都是待命状态。bgsave是触发 RDB 持久化的主流方式，下面给出 bgsave命令生成快照的流程:
这里模拟下bgsave过程
首先设置一个新的值
然后再模拟一下宕机的过程
我们再次去查找的时候发现已经不存在了

当我们使用bgsave命令时就可以查看到原本的数据
优点：只需要输入一个命令就可以了
缺点：我们不确定什么时间会发生宕机，那我们为了以防万一每输入一个命令都需要bgsave，这样就过于繁琐了

我们可以通过修改下redis.conf配置文件,来减轻繁琐工作
因为我们使用bgsave命令时，会把数据存放到dump.rdb文件下的 "./"路径下
自动触发保存
因为 bgsave命令可以在不阻塞服务器进程的情况下执行，所以 Redis 的配置文件 redis.conf 提供了一个 save 选项，让服务器每隔一段时间自动执行一次 bgsave命令。用户可以通过 save 选项设置多个保存条件，只要其中任意一个条件被满足，服务器就会执行 bgsave命令。 Redis 配置文件 redis.conf 默认配置了以下 3 个保存条件：
那么只要满足以下 3 个条件中的任意一个，bgsave命令就会被自动执行：
服务器在 900 秒之内，对数据库进行了至少 1 次修改。
服务器在 300 秒之内，对数据库进行了至少 10 次修改。
服务器在 60 秒之内，对数据库进行了至少 10000 次修改。
（这里的10是我们自己添加的，为了时间短一点）
Redis 服务器会周期性地操作 serverCron 函数，这个函数每隔 100 毫秒就会执行一次，它的一项任务就是检查 save 选项所设置的保存条件是否满足，如果满足的话，就自动执行 bgsave命令。
修改完配置后重启Redis，让配置生效。就可以减轻前面的步骤了，这时我们查看一下目录，是存在一个dump.rdb文件的。

save与bgsave比较
RDB持久化方式的优缺点
优点：
压缩后的二进制文，适用于备份、全量复制，用于灾难恢复。
加载RDB恢复数据远快于AOF方式。
缺点：
无法做到实时持久化，每次都要创建子进程，频繁操作成本过高。
保存后的二进制文件，存在老版本不兼容新版本rd文件的问题。

AOF持久化(默认关闭的)
首先通过命令去修改配置信息
将appendonly 改为yes，默认是no。每当Redis执行一个改变数据集的命令时（比如 SET），这个命令就会被追加到AOF 文件的末尾。这样的话，当Redis重新启时，程序就可以通过重新执行 AOF文件中的命令来达到重建数据集的目的
启动的AOF时，会将数据存入到appendonly.aof的文件中，当开启AOF时，这时RDB会失效。
然后当开启时，会存在appendonly.aof文件
AOF持久化流程
所有的写入命令(set hset)会append追加到aof_buf缓冲区中
AOF缓冲区向硬盘做sync同步
随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩
当redis 服务重启，可load加载AOF文件进行恢复
持久化流程：
命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)
AOF的优缺点
优点：
1、AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求），也可以根据实际情况设置fsync的策略。

2、AOF 文件是一个只进行追加操作的日志文件， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。

3、Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

4、AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

缺点：
1、对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

2、根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。