第九章Redis持久化

第九章Redis之持久化之 RDB

9.1总体介绍

官网介绍：http://www.redis.io

Redis 提供了 2个不同形式的持久化方式。
⚫ RDB（Redis DataBase）
⚫ AOF（Append Of File）

9.2RDB（Redis DataBase）

9.2.1RDB是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的 Snapshot 快
照，它恢复时是将快照文件直接读到内存里

9.2.2备份是如何执行的

Redis 会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件
中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程
中，主进程是不进行任何 IO 操作的，这就确保了极高的性能 如果需要进行大规模数
据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB方式要比 AOF方式更加
的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。

9.2.3 Fork

⚫ Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、
程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进
程
⚫ 在 Linux 程序中，fork()会产 生一个和父进程完全相同的子进程，但子进程在此后多
会 exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
⚫ 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要
发生变化时，才会将父进程的内容复制一份给子进程。

9.2.4RDB 持久化流程

9.2.5 dump.rdb 文件

在 redis.conf 中配置文件名称，默认为 dump.rdb

我这是在/etc/redis.conf下面

9.2.6配置位置

rdb 文件的保存路径，也可以修改。默认为 Redis 启动时命令行所在的目录下

9.2.7配置文件中默认的快照配置

9.2.8Save

格式：save 秒钟 写操作次数
RDB 是整个内存的压缩过的 Snapshot，RDB的数据结构，可以配置复合的快照触发条
件，
默认是 1 分钟内改了 1 万次，或 5 分钟内改了 10 次，或 15 分钟内改了 1 次。
禁用
不设置 save 指令，或者给 save 传入空字符串

9.2.9rdb 的备份

先通过 config get dir 查询 rdb文件的目录
将*.rdb 的文件拷贝到别的地方
rdb 的恢复
◆ 关闭 Redis
◆ 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
◆ 启动 Redis, 备份数据会直接加载

9.2.10优势

⚫ 适合大规模的数据恢复
⚫ 对数据完整性和一致性要求不高更适合使用
⚫ 节省磁盘空间
⚫ 恢复速度快

9.2.11 劣势

⚫ Fork 的时候，内存中的数据被克隆了一份，大致 2倍的膨胀性需要考虑
⚫ 虽然 Redis 在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消
耗性能。
⚫ 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，
就会丢失最后一次快照后的所有修改。

9.2.12小总结

9.3AOF（Append Only File）

9.3.1AOF是什么

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

9.3.2AOF持久化流程

（1）客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
（2）AOF 缓冲区根据 AOF 持久化策略[always,everysec,no]将操作 sync 同步到磁盘的AOF 文件中；
（3）AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重 写，压缩
AOF 文件容量；
（4）Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的

9.3.3AOF默认不开启

可以在 redis.conf 中配置文件名称，默认为 appendonly.aof
AOF 文件的保存路径，同 RDB的路径一致。

9.3.4AOF和RDB同时开启，redis 听谁的？

AOF 和 RDB 同时开启，系统默认取 AOF 的数据（数据不会存在丢失）

9.3.5AOF同步频率设置

appendfsync always
始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no
redis 不主动进行同步，把同步时机交给操作系统。

9.5.6Rewrite 压缩

1 是什么：
AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当
AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩， 只保留
可以恢复数据的最小指令集.可以使用命令 bgrewriteaof
2 重写原理，如何实现重写
AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写(也是先写临时文件最
后再 rename)，redis4.0 版本后的重写，是指上就是把 rdb 的快照，以二级制的形式附
在新的 aof 头部，作为已有的历史数据，替换掉原来的流水账操作。
no-appendfsync-on-rewrite：
如果 no-appendfsync-on-rewrite=yes ,不写入 aof 文件只写入缓存，用户请求不会阻
塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高
性能）
如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重
写操作，可能会发生阻塞。（数据安全，但是性能降低）
触发机制，何时重写Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定 Redis 要满足一定条件才会进行重写。
auto-aof-rewrite-percentage：设置重写的基准值，文件达到 100%时开始重写（文件
是原来重写后文件的 2 倍时触发）
auto-aof-rewrite-min-size：设置重写的基准值，最小文件 64MB。达到这个值开始重
写。
例如：文件达到 70MB 开始重写，降到 50MB，下次什么时候开始重写？100MB
系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为 base_size,
如果 Redis 的 AOF 当前大小>= base_size +base_size*100% (默认)且当前大
小>=64mb(默认)的情况下，Redis 会对 AOF 进行重写。
3、重写流程
（1）bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果
有，则等待该命令结束后再继续执行。
（2）主进程 fork 出子进程执行重写操作，保证主进程不会阻塞。
（3）子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓
冲区和 aof_rewrite_buf 重写缓冲区保证原 AOF 文件完整以及新 AOF 文件生成期间的
新的数据修改动作不会丢失。
（4）1).子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。2).主
进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件。
（5）使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写。

9.5.7优势

9.5.8劣势

9.5.9小总结

9.4总结

官方推荐两个都启用。
如果对数据不敏感，可以选单独用 RDB。
不建议单独用 AOF，因为可能会出现 Bug。
如果只是做纯内存缓存，可以都不用。

⚫ RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储
⚫ AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
命令来恢复原始的数据,AOF 命令以 redis 协议追加保存每次写的操作到文件末尾.
⚫ Redis 还能对 AOF 文件进行后台重写,使得 AOF 文件的体积不至于过大
⚫ 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何
持久化方式.
⚫ 同时开启两种持久化方式
⚫ 在这种情况下,当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据, 因为在
通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整.
⚫ RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件。那要不要只
使用 AOF 呢？
⚫ 建议不要，因为 RDB 更适合用于备份数据库(AOF在不断变化不好备份)， 快速重
启，而且不会有 AOF可能潜在的 bug，留着作为一个万一的手段。
⚫ 性能建议