Redis的两种持久化方式

为什么需要持久化？

Redis 是一种内存数据库，所有数据都是保存在内存中的，内存中的数据重启之后就会消失，所以为了重启或者意外退出之后能恢复之前的数据，Redis 实现了两种持久化机制

两种持久化机制

RDB

全名 Redis DataBase，默认开启的持久化机制

如果在指定的时间间隔内，执行了指定次数的写操作，则会触发RDB，将内存中的数据写入到磁盘中。即在指定目录下生成一个 dump.rdb 文件。Redis 重启会通过加载 dump.rdb 文件恢复数据。

dump.rdb 的存放路径在 redis 配置文件 redis.conf（默认路径：/etc/redis.conf ）中的 dir 字段指定（默认为：/var/lib/redis）

两种触发方式：

  • 手动：在 redis 的命令行中执行 save 或 bgsave
    • save：会阻塞当前的 Redis 服务器，直到 RDB 执行完
    • bgsave：会 fork 一个子进程来执行，只会阻塞一个执行 fork 的时间，很短
  • 自动：在配置文件中设置让 Redis 每隔多长时间、数据量达到了多少，就自动开始 bgsave
# /etc/redis.conf 中 RDB 相关配置
save 900 1		# 每 15 分钟，只要有一个 key 变化了，就 bgsave
save 300 10		# 每 5 分钟，...十个 key ...
save 60 10000	# 每分钟，...一万个 key ...

bgsave 指令运作流程

bgsave命令运作流程

AOF

全名 Append Only File，默认关闭

以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的，AOF 的主要作用是解决了数据持久化的实时性。

Redis 目前默认是不开启 AOF 的，若要开启，需要在配置文件中配置 appendonly yes。

# /etc/redis.conf 中 AOF 相关配置
appendonly no	# 是否开启 AOF，如果开启了，Redis 启动的时候就会优先加载AOF
appendfilename "appendonly.aof"	# 文件名，在 `/var/lib/redis` 下

# 三种缓冲区同步策略
# appendfsync always	# 命令写到缓冲区后就调用 fsync 同步到硬盘文件
appendfsync everysec	# 由专门线程每秒钟 fsync 一次
# appendfsync no			# 不调用 fsync，让操作系统决定什么时候同步，周期不可控，通常最长 30s

AOF 运作流程

AOF 运作流程

AOF 重写机制

随着命令不断写入，文件会越来越大，这时就会进行重写，可以使 AOF 文件变小：

  1. 进程内已经超时的数据可以不再写入；
  2. 旧的 AOF 文件内含有无效的命令，比如某个 key 添加完又删除了，等同于两条无效命令；某个 key 的值多次修改 ，除了最后一次，其余的都为无效命令；
  3. 多条命令可以合并为一条，比如给链表、集合添加元素

AOF 重写降低了文件大小，加载效率也会更高。

  重写触发方式

  1. 手动触发：调用 bgrewriteaof 命令
  2. 自动触发

触发的时机 = 当前AOF大小 > auto-aof-rewrite-min-size &&（当前AOF大小-上次重写后的大小）/上次重写后AOF的大小>=auto-aof-rewrite-percentage

# /etc/redis.conf 自动重写出发时机的配置项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

  重写运作流程

AOF重写运作流程

二者比较

比较RDBAOF
效率更高更低
数据安全性更低，分钟级别更高，秒级或者实时
文件格式压缩的二进制文件，有版本兼容性问题文本格式，以日志方式记录每次写操作，可读性高，可以直接修改
文件大小更小，加载快更大，加载慢，不过有重写机制，使文件变小

同时开启怎么办

有 AOF 则加载 AOF，否则，加载 RDB

image-20190713112732662