Redis：持久化篇

1、什么是 Redis 的持久化

• rdb和aof

2、RDB（Redis DataBase）：

一、RDB是什么?

• 在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的：Snapshot快照，它恢复时是将快照文件直接读到内存里
• Redis会单首创建（fork拷贝）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。好比：第一次存储5条数据到dump.rdb文件中，5分钟后，第二次存储20到条dump.rdb文件中，就把第一次的覆盖了。
• 整个过程当中，主进程是不进行任何IO操做的，这就确保了极高的性能。若是须要进行大规模数据的恢复，且对于数据恢复的完整性不是很是敏感， 那RDB方式要比AOF方式更加的高效。
• RDB的缺点：最后一次持久化后的数据可能丢失。好比：服务器恰好炸了。

二、Fork

Fork的做用：复制一个与当前进程同样的进程。新进程的全部数据（变量、环境变量、程序计数器等） 数值都和原进程一致，可是是一个全新的进程，并做为原进程的子进程。

三、RDB 保存的是 dump.rdb文件。

四、配置位置：redis.conf 的 SNAPSHOTTING

五、配置详解：

在磁盘上保存数据的命令：save <seconds> <changes>

如下状况3选1，将会触发数据库保存：

• 900秒（15分钟）内，若是至少增删改了1个key，触发数据库保存，会产生dump.rdb文件，默默地保存到磁盘中。
• 300秒（5分钟）内，若是至少改变了10个key，触发数据库保存，会产生dump.rdb文件，默默地保存到磁盘中。
• 60秒内，若是至少改变了10000个key，触发数据库保存，会产生dump.rdb文件，默默地保存到磁盘中。

手动当即保存：

• set key value -> save

不保存：

• 注释掉上面的配置便可。

注意：

• 执行ShutDown，至关于MySQL的commit，会当即生成dump.rdb文件。此时，若是以前执行FLUSHALL，把数据库清空，此时既清空又提交，生成的dump.rdb是空的文件。因此，恢复的文件也是空的。

恢复：

• 远程服务器已备份的数据拷贝到生产机器，命名为：dump.rdb便可。

stop-writes-on-bgsave-error：后台save出错，那么就中止写入，出错就刹车。

rdbcompression：是否启用压缩算法，默认开启。

rdbchecksum：用于数据校验。

六、如何触发RDB快照（3种方式）

• 配置文件中默认的快照配置（3种策略）
• 命令save或者bgsave。Save：save时只管保存，其它无论，所有阻塞。BGSAVE：Redis会在后台异步进行快照操做，快照同时还能够响应客户端请求。能够经过：lastsave，获取最后一次成功执行快照的时间
• 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无心义

七、RDB优点和劣势：

• 优点：适合大规模的数据恢复；对数据完整性和一致性要求不高
• 劣势：在必定间隔时间作一次备份，因此若是redis意外down掉的话，就会丢失最后一次快照后的全部修改的时候；内存中的数据被克隆了一份，大体2倍的膨胀性须要考虑。

八、如何中止：

• 动态全部中止RDB保存规则的方法：redis-cli config set save ""

3、AOF（Append Only File）

一、AOF是什么?

• 是记录操做者的全部写操做，数据恢复的时候，把全部写操做执行一遍。
• 以日志的形式来记录每一个写操做，将Redis执行过的全部写指令记录下来(读操做不记录)，只许追加文件但不能够改写文件，redis重启的话就根据日志文件的内容，将写指令从头至尾执行一次以完成数据的恢复工做。

二、AOF 保存的是 appendonly.aof文件

三、配置的位置：redis.conf 的 APPEND ONLY MODE

四、配置详解：

appendfsync ：同步写的策略，有三种

• always：同步持久化，每次发生数据变动会被当即记录到磁盘，性能较差，但数据完整性比较好
• everysec：出厂默认推荐，异步操做，每秒记录，若是一秒内宕机，有数据丢失
• no：从不一样步

默认AOF文件名：appendonly.aof

AOF启动，修复，恢复：

一、启动 AOF

AOF持久化存储方式默认关闭，设置yes就是启动持久化

二、修复 AOF

若是我在上面文件的后面，模拟文件损坏的场景，可否成功启动redis？同时存在rdb 和aof ，二者可否共存，能的话优先加载谁？

模拟：

启动：

第一问：启动失败；

第二问：能够共存；

第三问：优先加载 aof 文件，由于 rdb 文件是正常的，aof 文件是损坏的，加载失败的缘由是 aof 文件损坏，因此得出：优先加载 aof 文件

三、如何修复 aof 文件？

输入命令：redis-check-aof --fix appendonly.aof

Rewrite(AOF文件自我瘦身)：

一、是什么？

• AOF采用文件追加的方式，文件会愈来愈大，为避免出现此种状况：新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会自动开启AOF文件的内容压缩，只保留能够恢复数据的最小指令集，可使用 bgrewriteaof 。

二、重写原理：

• AOF文件持续增加而过大时，会fork出一条新进程来将文件重写。重写aof文件的操做，并无读取旧的aof文件，而是将整个内存中的数据库内容用命令方式重写了一个新的aof文件，这点和快照有点相似。

三、触发条件:

• redis会记录上次重写时的AOF大小，默认配置：是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M时触发，高并发系统绝对不止64mb。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
复制代码

AOF优点和劣势：

• 优点：能够灵活设置同步写的策略；数据比较完整
• 劣势：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；aof运行效率要慢于rdb，每秒同步策略效率较好，不一样步效率和rdb相同

4、RDB or AOF

• 同时开启两种持久化方式：在这种状况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据。
• 由于在一般状况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
• RDB的数据不实时，同时使用二者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？建议不要，由于RDB更适合用于备份数据库(AOF在不断变化很差备份)。

5、面试：

一、什么是持久化？

• rdb和aof

二、若是dump.rdb和appendonly.aof能够共存，同时存在的状况下，会先加载谁？

• 优先加载appendonly.aof