Redis持久化机制理解

Redis持久化机制

一、RDB快照方式持久化

1. Redis可以通过获取存储在内存里面的数据在 某一时间点 的副本。生成快照。对快照进行备份。可以将快照快速的复制到其他服务器。创建具有相同数据的其他服务器副本。也可以存在留在本地。以便服务器重启时，快速恢复数据。（主从结构）

2. 在 redis.conf 配置文件里SNAPSHOTTING默认有如下配置。

• 自动触发

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发bgsave命令创建快照。

• 手动触发：

  save：阻塞主进程，直到生成新的RDB文件；执行save命令期间，Redis不能处理其他命令。
  bgsave：异步生成RDB文件，fork子进程去生成新的RDB文件，主进程不阻塞。

redis提供了两个命令来进行创建快照

• save:同步保存。会阻塞Redis主线程io

• bgsave: fork()产生一个子进程【多进程COW(Copy On Write)机制】，快照持久化完全交给子进程来处理，父进程继续处理客户端的读写请求.(默认选项)

3. 需要注意的是当进行持久化时。子进程几乎瞬间就会将父进程的里面的全量数据复制一份到内存中。如此时父进程有修改/删除操作。子进程则不会进行复制。

二、AOF持久化

AOF(Append-only file)日志存储的是redis服务器的顺序指令序列，即对内存中数据进行修改的指令记录。

1. AOF持久化简单过程

• 命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。
• 文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数（系统调用），write将数据写入到了系统内核缓冲区之后直接返回了（延迟写）。注意！！！此时并没有同步到磁盘。
• 文件同步（fsync）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
• 文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
• 重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

---

• 参考
  著作权归Guide所有
  原文链接：https://javaguide.cn/database/redis/redis-persistence.html#%E4%BB%80%E4%B9%88%E6%98%AF-aof-%E6%8C%81%E4%B9%85%E5%8C%96

2. AOF持久化策略

#1、AOF持久策略：fsync的策略，默认为everysec
appendfsync everysec
# everysec：每秒fsync一次，如果Redis宕机，1秒内的指令丢失。
# no：redis不主动fsync，完全交由操作系统决定
# always：1条指令fsync一次，保证数据一条不丢失

fsync用于强制刷新系统内核缓冲区（同步到到磁盘），确保写磁盘操作结束才会返回。

三、redis4后新增了混合持久化

混合持久化。将RDB文件的内容和增量的AOF日志文件存在一起，这里的AOF日志不再是全量 的日志，而是RDB久化开始 到 RDB持久化结束的这段时间发生的增量AOF日志，通常这部分AOF日志很小。

四、RDB和AOF优缺点

1. RDB生成速度快，经过压缩的二进制文件。体积小。可以作为数据备份，灾难恢复。 且解析速度快。但是容易丢失的数据。造成数据不完备。

2. AOF文件生成较慢。但是数据基本不会丢失。需要将数据转化为操作指令。文件体积较大。并且在恢复数据过程中需要一行一行解析指令。速度较慢。

3. 对于Redis 保存的数据保存完善程度要求不高，可以选择使用 RDB。如果保存的数据要求安全性比较高的话，建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化。

`粗略记录自己的一些理解。感谢阅读。