Redis持久化

Redis持久化 AOF RDB 大白话理解

一图解释

RDB

在指定的时间间隔,执行数据集的时间点快照

配置文件

stop-writes-on-bgsave-error	默认yes, 你不在乎数据不一致或者有其他手段发现和控制这种不一致,在快照写入失败时,也能确保redis继续接受新的写请求
rdbcompression	默认yes,对于存储到磁盘中的快照,可以设置是否进行压缩存储. 如果是的话,redis会采用LZF算法进行压缩,如果不想消耗CPU来进行压缩的话,可以设置关闭此功能
rdbchecksum	默认yes,在存储快照后,还可以让redis使用CRC64算法进行数据校验,会多消耗10%的性能消耗,建议关闭此功能
rdb-del-sync-files	默认no,在没有持久性的情况下删除复制中使用的RDB文件启用,禁用
save	多少秒之内有多少次修改,触发rdb
dbfilename	rdb文件保存名称
dir	rdb保存路径

redis6.2以上 , 可以写在一行
        save 3600 1 300 100 60 3000
redis6.0.16以下
        save 3600 1
        save 300 100
        …

手动触发

• save
  会阻塞当前redis服务器,直到持久化工作完成,线上禁止使用
• bgsave
  Redis会在后台异步进行快照操作,不阻塞快照同时还可以相应客户端请求,
  该出发方式会fork一个紫禁城复制持久化过程

lastsave 获取最后一次执行save/bgsave的时间

优势/劣势

优势

• 适合大规模的数据恢复
• 按照业务定时备份
• 对数据完整性和一致性要求不高
• RDB文件在内存中的加载速度比AOF要快的多

劣势

• 在一定间隔时间做备份期间,如果redis意外down掉的话 就会丢失 期间的数据
• 内存数据的全量同步,数据量过大影响I/O影响服务器性能
• RDB依赖于主进程的fork,会膨胀到两倍,服务器请求瞬间延迟

修复dump文件

AOF

用日志的形式来记录每个写操作

默认关闭 开启需要设置: appendonly yes

AOF持久化工作流程

1. Client作为命令的来源,会有多个源头以及源源不断的请求命令.
2. 在这些命令到达Redis Server 以后并不是直接写入AOF文件,会将其这些命令先放入AOF缓存中进行保存.这里的AOF缓冲区实际上是内存中的一片区域,存在的目的是当这些命令达到一定量之后再写入磁盘,避免配饭的磁盘IO操作
3. AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件.
4. 随着写入AOF内容的增加为避免文件膨胀,会根据规则进行命令的合并(AOF重写),从而起到AOF文件压缩的目的.
5. 当Redis Server 服务器重启的时候会从AOF文件载入数据.

AOF缓冲区三种写回策略

Always	同步写回,每个写命令执行完立即同步的将日志写回磁盘
everysec	每秒写回,每个命令执行完,先将日志写入到AOF文件的内存缓冲区,每个1秒写入到AOF文件中
no	由操作系统决定何时写入到AOF磁盘

配置文件

配置指令	配置含义	配置实例
appendonly	是否开启aof	appendonly yes
appendfilename	aof文件名称	appendfilename “appendonly.aof”
appendfsync	同步方式	everysec/always/no
no-appendfsync-on-rewrite	aof重写期间是否同步	no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage	重写触发配置	auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size	文件重写策略	auto-aof-rewrite-min-size 64mb|

aof文件-保存路径

• redis6
  • AOF和RDB保存位置一样,通过redis.conf的dir配置
• redis7
  • dir配置的路径+appenddirname配置

aof文件-保存名称

• redis6
  • 有且仅有一个文件
• **redis7 **Multi Part AOF的设计
  • MP-AOF实现

• 在增量文件中写入,文件大小到达重写出发配置而且文件重写策略触发重写保存进基本文件中

修复AOF文件

故意乱写正常的AOF文件,恢复就会error

异常修复命令:redis-check-aof --fix xxx/xxx/xxx.aof

AOF重写机制

启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集

触发机制

• 自动触发
  满足配置文件中的选项后,Redis会记录上次重写时的AOF大小,
  默认配置是当AOF文件大小是上次rewrite后大小的一倍而且大于64M时
• 手动触发
  bgrewriteaof 命令

重写原理

1. 在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2. 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3. 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4. 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5. 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

RDB-AOF混合持久化

同时启用RDB和AOF,redis重启时会优先加载AOF文件来恢复初始的数据

纯缓存模式

同时关闭RDB和AOF

• 禁用rdb save ""
• 禁用aof appendonly no