Redis持久化

Redis持久化之 RDB

1.是什么

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

2.备份是如何执行的

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

RDB 的缺点是最后一次持久化后的数据可能丢失。

3.  Fork

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

4. RDB 持久化流程

 

 

 

 

5.  dump.rdb  文件

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

 

 

 

配置位置

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

 

 

 

注意： ./ 是相对目录 

6.如何触发 RDB 

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

 

 格式：save 秒钟 写操作次数

默认是 1 分钟内改了 1 万次，或 5分钟内改了10  次，或 15分钟 内改了 1 次触发持久化。

如何禁用save?

不设置 save 指令，或者给 save 传入空字符串

6.2命令  save VS bgsave

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。
bgsave：Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
可以通过 lastsave 命令获取最后一次成功执行快照的时间

6.3 flushall  命令

执行 flushall 命令，也会产生 dump.rdb文件，但里面是空的，无意义

6.4 stop-writes-on-bgsave-error

当 Redis 无法写入磁盘的话，直接关掉 Redis的写操作。推荐 yes.

6.5 rdbcompression  压缩文件 

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用LZF 算法进行压缩。

如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能。推荐 yes. 

6.6 rdbchecksum 检查完整性

 在存储快照后，还可以让 redis 使用 CRC64算法来进行数据校验，但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。推荐 yes

7. rdb  的备份

先通过 config get dir 查询 rdb文件的目录，将*.rdb 的文件拷贝到别的地方

rdb 的恢复

• 关闭 Redis
• 把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
• 启动 Redis, 备份数据会直接加载 

8.如何停止RDB

动态停止 RDB：redis-cli config set save ""（save 后给空值，表示禁用保存策略）

9.优势

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

10.劣势

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

11.总结

 

Redis之持久化之 AOF

1. 是什么

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

2. AOF  持久化流程

（1）客户端的请求写命令会被 append 追加到 AOF 缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF 文件容量；

（4）Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的；

3.   AOF  默认不开启

可以在 redis.conf 中配置文件名称，默认为 appendonly.aof

AOF 文件的保存路径，同 RDB的路径一致。

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

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

5. AOF  启动/ 修复/ 恢复

  AOF 的备份机制和性能虽然和 RDB不同, 但是备份和恢复的操作同 RDB一样，都是拷贝备份文件，需要恢复时再拷贝到 Redis 工作目录下，启动系统即加载。

正常恢复

•   修改默认的 appendonly no，改为 yes
•   将有数据的 aof 文件复制一份保存到对应目录(查看目录：config get dir)                                          
• 重启 redis 然后重新加载

 异常恢复

•   修改默认的 appendonly no，改为 yes
•   如遇到 AOF 文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof 进行恢复被写坏的 AOF 文件
• 重启 redis，然后重新加载

6. AOF  同步频率设置

appendfsync always
始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no
redis 不主动进行同步，把同步时机交给操作系统。

7.优势

•  备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作 AOF 稳健，可以处理误操作。

8.劣势

•   比起 RDB 占用更多的磁盘空间。
•   恢复备份速度要慢。
•   每次读写都同步的话，有一定的性能压力。
•   存在个别 Bug，造成恢复不能。

 9.总结

RDB与AOF 总结(Which one)

1.  用哪个好

官方推荐两个都启用。

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

2.官网建议

•  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%大小时重写可以改到适当的数值。

混合持久化

RDB 和 AOF 持久化各有利弊，RDB 可能会导致一定时间内的数据丢失，而 AOF 由于文件较大则会影响 Redis 的启动速度，为了能同时使用 RDB 和 AOF 各种的优点，Redis 4.0 之后新增了混合持久化的方式。

在开启混合持久化的情况下，AOF 重写时会把 Redis 的持久化数据，以 RDB 的格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式化追加的文件的末尾。

 

通过修改 Redis 配置文件开启

在 Redis 的根路径下找到 redis.conf 文件，把配置文件中的 aof-use-rdb-preamble no 改为 aof-use-rdb-preamble yes 如下图所示：

数据恢复和源码解析

混合持久化的数据恢复和 AOF 持久化过程是一样的，只需要把 appendonly.aof 放到 Redis 的根目录，在 Redis 启动时，只要开启了 AOF 持久化，Redis 就会自动加载并恢复数据。 Redis 启动信息如下图所示：

混合持久化优点：

• 混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF 的优点，有减低了大量数据丢失的风险。

混合持久化缺点：

• AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
• 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。