redis——持久化

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

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。理解掌握持久化机制对于Redis运维非常重要！

RGB

是什么

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

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

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

rdb 保存的是dump.rdb文件。相关配置在配置文件的位置 - 在redis.conf搜寻### SNAPSHOTTING ###

1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进 程，如RDB/AOF子进程，如果存在bgsave命令直接返回。

2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通 过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒

3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。

4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后 对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间，对应info统计的rdb_last_save_time选项。

5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence下的rdb_*相关选项。

RDB文件的处理

配置文件

RDB文件保存在dir配置指定的目录下，文件名通过dbfilename指定。

命令

可以通过执行

config set dir 目录

config set dbfilename 文件名

当下次运行时RDB文件会保存到新目录

如何触发RGB

命令方式

  • SAVE：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用

  • BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间

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

配置文件方式

SNAPSHOTTING部分

1）在redis.conf配置文件快照模块中，有save m n。表示m秒内数据集存在n次修改 时，自动触发bgsave。

2）执行debug reload命令重新加载Redis时，也会自动触发save操作。

3）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。bgsave是主流的触发RDB持久化方式

#快照名
dbfilename dump.rdb

#生成快照规则
save 120 10 # 120秒内修改10次则触发RDB

快照文件恢复数据

将备份文件 (dump.rdb) 移动到 redis 安装目录/usr/local/bin，启动redis服务时会自动检测到

  • 命令CONFIG GET dir获取目录位置

RGB优缺点

优点：

  • RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据 快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
  • Redis加载RDB恢复数据远远快于AOF的方式

缺点：

  • RDB方式数据没办法做到实时持久化（秒级持久化）。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
  • RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式 的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。
  • 一定间隔时间做一次备份，所以如果redis意外挂掉，不满足生成快照文件的规则，就可能会丢失最后一次快照后的所有修改

AOF

是什么

AOF（append only file）持久化：以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。目前已经是Redis持久化的主流方式。

配置

位置：在redis.conf文件中的APPEND ONLY MODE模块

  • 启动：appendonly yes，默认不开启
  • AOF文件名：通过appendfilename配置设置，默认文件名是appendonly.aof
  • 保存路径同RDB持久化方式，通过dir配置指定，获取配置路径命令：config get dir
  • 恢复损坏的AOF文件，运行redis-check-aof aof文件
  • 持久化配置appendfsync
    • always ：每次有数据修改发生时都会写入AOF文件，性能差。
    • everysec： 每秒钟同步一次，该策略为AOF的缺省策略。
    • no： 从不同步。高效但是数据不会被持久化。

如何恢复数据

正常恢复：

修改默认的appendonly no，改为yes 。将有数据的aof文件复制一份保存到对应目录，dir配置保存路径，config get dir查看路径。

异常恢复：

修复命令redis-check-aof --fix appendonly.aof

工作流程

AOF的工作流程操作：

  1. 命令写入 （append）
  2. 文件同步（sync）
  3. 文件重写（rewrite）
  4. 重启加载 （load）

1 - 所有的写入命令会追加到aof_buf（缓冲区）中。

2 - AOF缓冲区根据对应的策略向硬盘做同步操作。

AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如 果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负 载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡

3 - 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

重写后的AOF文件为什么可以变小？有如下原因：

  1. 进程内已经超时的数据不再写入文件。
  2. 旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
  3. 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

4 - AOF重写过程可以手动触发和自动触发

  • 手动触发：直接调用bgrewriteaof命令。
  • 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
    • auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认 为64MB。
    • auto-aof-rewrite-percentage：代表当前AOF文件空间 (aof_current_size)和上一次重写后AOF文件空间（aof_base_size）的比值。

img

补充：

1）AOF持久化开启且存在AOF文件时，优先加载AOF文件

2）AOF关闭或者AOF文件不存在时，加载RDB文件

3）加载AOF/RDB文件成功后，Redis启动成功。

4）AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

总结

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式

  • 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF 文件保存的数据集要比RDB文件保存的数据集要完整。
  • RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有 AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

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