Redis两种持久化

       Redis是内存数据库。如果不能将内存中的数据状态保存到磁盘，那么一旦服务器进程退出，服务器中数据库状态也会消失， 所以Redis提供了持久化功能

---

RDB (Redis DataBase)

什么是rdb

在主从复制中 rdb就是在从机上备用的

---

        在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）写入磁盘,也就是我们所说的Snapshot快照( VMware快照类似),它恢复时是将快照文件直接读到内存中!

        Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入一个临时文件中，待持久化过程全部结束，再将这个临时文件替换上次持久化的文件。整个过程中 主进程是不进行任何IO操作的。这就保证了极高的性能。如果需要进行大规模数据的恢复，且对数据恢复完整性不是非常敏感 那么RDB方式更加高效。

---

RDB默认开启

Rdb保存的文件是: dump.rdb
都是在redis.conf配置文件中配置的

触发机制

1. save的规则满足的情况下，会自动触发rdb规则。
2. 执行flushdb也会触发rdb规则。
3. 退出redis也会触发rdb规则。
   备份会自动生成dump.rdb文件

---

恢复RDB文件数据

只需要将我们的dump.rdb文件放都redis启动目录即可。redis启动会自动检查dump.rdb文件，恢复其中的数据。

config get dir #查看rdb文件保存位置

save 和 bgsave 保存

Redis 提供了save和bgsave这两种不同的保存方式,并且这两个方式在执行的时候都会调用rdbSave函数，但它们调用的方式各有不同

1. save 直接调用 rdbSave方法 ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
2. bgsave 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave 在子进程被调用，所以 Redis 服务器在 bgsave 执行期间仍然可以继续处理客户端的请求。
3. save 是同步操作，bgsave 是异步操作。
4. bgsave命令的使用方法和save命令的使用方法是一样的。

---

shutdown 保存

1.事实上，shutdown命令也是可以保存数据。

---

优点

1. RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。适合大规模的数据恢复。
2. RDB 非常适用于灾难恢复（disaster recovery）。
3. 对数据完整性要求不高。
4. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

缺点

1. 需要一定的时间间隔去操作，如果再此期间redis宕机，最后一次的修改数据修改就会丢失
2. frok进程的时候，需要一定的内存空间

---

AOF (Append Only File)

什么是aof

将我们的所有命令都记录下来，history，恢复至时就把这个文件的命令全部执行一遍。

        以日志的形式来记录每一个写操作，将Redis执行过的所有指令记录下来(读操作不记录)，只追加文件但不可以改写文件。redis启动之初会读取该文件重新构建数据。换言之，重启redis的话就根据日志文件的内容将写指令从前到后执行一次完成数据的恢复工作!
Aof保存的是appendonly.aof文件

---

AOF开启设置

配置文件设置

appendonly yes #是否开启aof。默认关闭
appendfilename "appendonly.aof" #aof生成的文件名。默认即可
# appendfsync always #每次修改都会同步速度比较慢，消耗性能
appendfsync everysec #每秒执行一次，可能会丢失这一秒的数据
# appendfsync no     #不执行sync，操作系统自己同步数据，速度是最快的
no-appendfsync-on-rewrite no #重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性
auto-aof-rewrite-percentage 100 #设置重写的基准值
auto-aof-rewrite-min-size 64mb  #设置重写的基准值

---

        上面这三种策略中，always虽然能够保证数据的完整性，但是会带来严重的消耗。这在超高并发的环境下是不可想象的，之前的redis特别篇中我已经提到CAP原理。在真实的高并发环境下，如果真的要做取舍一定是取AP，毕竟高可用是最重要的。
        还有另一个问题，在高并发环境下，大量的数据被写入和修改，那么aof文件会变得非常臃肿。有的时候显得很笨拙。例如k1的值为0，你incr k1了一万次，那么也会在aof文件中写入incr k1一万次操作；其实如果能只记录一个set k1 10000，一句也就搞定了，效果一样，精简多了。所以我们引入了redis aof的另外一个概念或者说特性机制，— rewrite重写

---

Rewrite 重写机制

no-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
auto-aof-rewrite-min-size：设置重写的基准值
auto-aof-rewrite-percentage：设置重写的基准值

重写机制是什么：

        AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

bgrewriteaof  #命令用于异步执行一个 AOF（AppendOnly File）文件重写操作。重写会创建一个当前AOF文件的体积优化版本。
#AOF 重写由 Redis 自行触发， bgrewriteaof  仅仅用于手动触发重写操作。

• 重写原理
          AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

• 触发机制
           Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。请见配置文件。默认是，auto-aof-rewrite-percentage 100的意思是超过100%，也就是一倍；auto-aof-rewrite-min-size 64mb是超过64mb。

        这里插一句，假如你到一家新公司，老板把公司吹的天花乱坠，什么技术有多牛，业务量有多大。如果他们使用aof来做redis持久化，这时候，你只要偷偷看一眼他们redis的这个配置项auto-aof-rewrite-min-size，如果是64mb，那么你就应该心领神会了——这个公司要么业务量根本没这么大，要么这个公司的人并不怎么牛。真正大型系统，3gb都是起步，64mb根本实在搞笑。这个配置时观察一个公司水平的一个很好的维度。

---

AOF文件修复方法

        那么如果我们在实际生产中，网络丢包、延迟、病毒、大文件运行失败等等导致aof文件破损。aof文件损坏了，该怎么修复呢？
1.备份待修复的aof文件

cp appendonly.aof appendonly_bak.aof

备份！备份！备份！好习惯！

2.修复

/usr/local/redis/bin/redis-check-aof --fix appendonly.aof

3. 恢复 重启redis然后重新加载

/usr/local/redis/bin/redis-server  redis.conf

优点

1. 每一次修改都同步，文件的完整性会更好。
2. 每秒同步一次，可能会丢失1秒的数据。
3. 从不同步，效率更高。

缺点

1. 相对于数据来说，aof远远大意rdb，修复的速度也比rdb慢。
2. aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同，所以redis默认的配置就是rdb持久化。

---

思考

AOF和RDB是否可以共存

是可以共存的
redis服务可以同时生成aof和rdb文件，说明aof和rdb方式两者可以共存

关于这个我们用配置文件中的注释做个总结：

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.

AOF和RDB谁优先

那么，如果同时存在rdb和aof文件，redis会优先加载谁呢？
       在同时存在rdb和aof文件的情况下，redis会优先选择aof进行数据恢复

总结 (RDB和AOF选哪个)

官网建议

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾。

---

Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。

---

同时开启两种持久化方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据。因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
       建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

---

性能建议

       因为RDB文件只用作后备用途，建议只在Slave(从机)上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
       如果开启 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
       如果不开启 AOF ，仅靠Master-Slave Replication (主从复制)实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。

最后

整个的技术遇到的问题及演化过程如下：

RDB不完整 → AOF ，AOF频繁IO → 主从复制