Redis（三）持久化

RDB（Redis Database）

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

自动触发

RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照

指定的时间间隔内将内存中的数据集写入磁盘，恢复时直接从磁盘中读回到内存中

• Snapshot内存快照保存备份时全量快照
• RDB保存的是dump.rdb文件

保存频率

Redis7和6.0有较大区别
Redis6.0.16 redis.conf

Redis7.0 redis.conf

修改dump文件保存路径

修改文件保存名称

dump恢复

• 备份文件(dump.rdb)移动到 redis 安装目录并启动服务即可
• 使用 flushdb / flushall 同样会产生dump文件但是是空的
• 物理恢复：必须服务和备份分机分离。（不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储）
  以防生产机物理损坏后备份文件也挂了。

手动触发

Redis提供两个命令save、bgsave

生产上只能用bgsave：save执行过程中会阻塞当前Redis Server 直到持久化工作完成，Redis 不能处理其他命令，线上禁止使用

save

bgsave

Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程

• fork： github中的fork；操作系统：在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。
• lastsave命令可获得最后一次执行快照时间

优劣

优点

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

缺点

1. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
2. 内存数据全量同步，如果数据量太大会导致 I/O 严重影响服务器性能
3. RDB依赖主进程fork，在更大的数据集中，可能导致服务器请求的瞬时延迟，fork的时候内存中的数据被克隆，大约导致两倍膨胀

数据丢失案例：

• 使用kill -9模拟意外down
• Redis重启恢复查看数据是否丢失

检查修复dump文件

redis-check-rdb dump6379.rdb

会触发RDB快照的情况

1. 配置文件中默认的快照配置
2. 手动 save / bgsave 命令
3. 执行 flushdb / flushall 命令，但里面是空的
4. 执行shutdown且没有设置开启AOF持久化
5. 主从复制，主节点自动触发

禁用快照

动态停止

redis-cli config set save ""

快照禁用
redis.conf

Redis优化配置项

redis.conf
配置文件Snapshotting模块

1. save
2. dbfilename
3. dir
4. stop-writes-on-bgsave-error

stop-writes-on-bgsave-error yes
# 默认yes
# 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，
# 也能确保redis继续接受新的写请求

5. rdbcompression

rdbcompression yes
# 默认yes对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
# 如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

6. rdbchecksum

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

7. rdb-del-sync-files

rdb-del-sync-files no
# rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。
# 默认情况下no，此选项是禁用的。

总结

AOF（Append Only File）

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下，redis是没有开启AOF(append only file)的。
开启AOF功能需要设置配置：appendonly yes?

保存文件类型

appendonly.aof文件

AOF持久化工作流程

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

缓冲区回写频率

redis.conf

回写策略：

1. Always
2. everysec
3. no
   

AOF配置/启动/修复/恢复

配置文件说明

开启AOF

配置回写策略
默认每秒
文件保存路径
redis7

保存文件名称

正常恢复

配置
设置yes修改默认appendonly，改为yes
启动
重新启动

异常恢复

异常备份，例如网络波动，异常宕机

redis-check-aof --fix

优势

劣势

AOF重写机制

启动AOF文件的内容压缩，只保留可以恢复的最小指令集，自动触发和手动触发

默认配置

注意 ，同时满足，且的关系才会触发
1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
2 重写时满足的文件大小
总结

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

小总结

AOF+RDB混合

官方建议

数据恢复加载流程

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件未尾。
  
• 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。不建议只使用AOF，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。

推荐方式RDB和AOF混合
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据

1. 开启混合方式设置

设置aof-use-rdb-preamble的值为 yes   yes表示开启，设置为no表示禁用

2. RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写

纯缓存模式

同时关闭RDB和AOF