Redis7持久化（四）

5.1 总体介绍

官网地址

5.1.1 为什么需要持久化

Redis为了保证效率，数据缓存在了内存中，但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中，以保证数据的持久化。

5.2 持化双雄

5.2.1 RDB持久化

5.2.1.1 RDB介绍

1. RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。
2. 实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
3. 恢复数据时再将硬盘快照文件直接读到内存中
4. Redis的数据存在内存中，保存快照时执行的是全量快照，也就是说把内存中的数据全部记录到磁盘中，一锅端
5. Rdb保存的是dump.rdb文件

5.2.1.2 配置文件（6 vs 7）

Redis6.0.16以下


Redis6.2以及Redis7.0.0

5.2.1.3 案例演示

自动触发
Redis7版本，按照redis.conf文件里配置

save<seconds> <changes>

本次案例每5秒修改2次

修改dump文件保存路径
默认保存如下图：
自定义修改的路径且可以进入redis里用CONFIG GET dir获取目录


修改dump文件名称
触发备份

第一种情况


从上图可以看出，set k1的时候并没有dump文件产生，当5秒内set两次的时候，产生了dump文件

第二种情况

如何恢复

1. 将备份文件（dump.rdb）文件移动到redis安装目录并启动服务即可

2. 备份成功后故意flushdb清空redis查看是否可以恢复数据
   
   执行flushall/flushdb命令后一样会产生dump.rdb文件，但是里面的内容是空的，没有任何意义

3. 物理恢复的时候，redis服务与备份分开存放，避免生产机物理损坏后备份文件也挂了

手动触发
Redis提供了两个命令来进行手动备份文件**（save、bgsave）**

4. save ：save 时只管保存，其它不管，全部阻塞。手动保存，不建议。
5. bgsave：Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。 该方式会fork一个子进程，由子进程复制持久化的过程，这个操作是在后台进行，允许主进程同时修改数据
6. 可以通过 lastsave 命令获取最后一次成功执行快照的时间。
7. fork是什么（在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。）

5.2.1.5 备份执行原理

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

Fork

• Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
• 在 Linux 程序中，fork ()会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 “写时复制技术”。
• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。
  

5.2.1.5 优势与劣势

优势


小总结

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

劣势


小总结

1. 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。快照之间的数据会丢失
2. 内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
3. RDB依赖于主进程的fork，在更大的数据集中，会导致服务请求的瞬间延迟，Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑。

备份丢失案例

从上图看出，第一步查看没有dump文件生成，进行第二步存入k1和k2，第三步能看到dunm文件，说明备份成功，接着存k3，k3存入的时候，能够在内存中看到k3已经存入成功了，接着准备存k4，在存k4的时候突然服务down机了，此时没有执行两次操作没有进行备份，再重新启动服务，查看k3，发现没有k3的数据
以下是模拟redis服务down机

如何检查修复dump文件

哪些情况会触发RDB快照

• 配置文件默认的快照配置
• 手动save/bgsave命令执行
• 执行flushall/flushdb也会生成rdb文件，但是内容是空的，否则下次加载还是有数据
• 执行shoudown且没有设置AOF持久化
• 主从复制时，主节点自动触发

如何禁用快照

• 动态停止 RDB：redis-cli config set save “”#save 后给空值，表示禁用保存策略。
• 快照禁用（配置文件）
  RDB优化配置项详解

配置文件SNAPSHOTTING模块

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

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

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

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

总结

5.2.2 AOF持久化

5.2.2.1 AOF介绍

1. 以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来 (读操作不记录)， 只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2. 默认情况下，redis未开启AOF持久化功能，如需开启需要在配置文件配置：appendonly yes
3. AOF保存的是appendonly.aof文件

5.2.2.2 AOF持久化流程

5.2.2.3 三种写回策略

1. appendfsync always：始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好。
2. appendfsync everysec：每秒同步，每秒记入AOF文件缓冲区一次，如果宕机，本秒的数据可能丢失。
3. appendfsync no：redis 不主动进行同步，每次命令执行完，只是先把日志写到AOF内存的缓冲区，把同步时机（什么时候同步）交给操作系统。
   

5.2.2.4 配置文件（6 vs 7）

保存路径

redis6
AOF 文件的保存路径，同 RDB 的路径一致。都是通过redis.conf配置文件的dir配置

redis7


最终路径：dir + appenddirname

保存名称

redis6
有且仅有一个
redis7

5.2.2.5 案例演示

开启AOF持久化：修改默认的 appendonly no，改为 yes

正常恢复

恢复1
写操作完成，生成AOF文件到指定目录

然后重新启动，数据恢复

恢复2

• 写入数据进redis生成aof文件，然后flushdb+shundown服务器，会新生成dump和aof的空文件

• 备份之前有数据的aof.bak,然后删除有数据的aof文件

• 然后重新启动redis服务，会发现数据是空的

• 然后将之前备份的bak文件改成aof，删除空的aof文件，会发现数据恢复成功
  
  
  异常恢复

• 故意乱写aof文件，弄成错误的aof文件

vim /myredis/appendonlydir/appendonly.aof.1.incr.aof

• 然后重新启动redis服务，会发现启动报错
  
• 异常修复命令

redis-check-aof–fix

重启ok

5.2.2.6 优势与劣势

优势

更好的保护数据不丢失，性能高，可做紧急恢复

劣势

5.2.2.7 AOF重写机制

是什么

1. 由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
2. 为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集或者可以手动使用命令 bgrewriteaof 来重新。
   触发机制
   
   注意 ，同时满足，且的关系才会触发
   1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍，例如：文件达到 70MB 开始重写，降到 50MB，下次什么时候开始重写？100MB
   2 重写时满足的文件大小

自动触发

满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

手动触发

客户端向服务端发送bgrewriteaof命令

案例说明

比如有个key ，一开始你 set k1 v1，然后改成 set k1 v2，最后改成 set k1 v3
如果不重写，那么这3条语句都在aof文件中，内容占空间不说启动的时候都要执行一遍，共计3条命令；
但是，我们实际效果只需要set k1 v3这一条，所以，开启重写后，只需要保存set k1 v3就可以了只需要保留最后一次修改值，相当于给aof文件瘦身减肥，性能更好。AOF重写不仅降低了文件的占用空间，同时更小的AOF也可以更快地被Redis加载。

3. 开启aof持久化操作
4. 重写峰值修改为1k
   
5. 将rdb持久化关闭
   
6. 删除之前的所有aof和dunmp文件
7. 完成上述操作，重启redis，set一个数据查看是否正常
   
   
   查看文件内容
   继续存k1，数据一直增加直到超出1k
   
   重写触发
   
   以下是第二种情况：
   客户端向服务端发送bgrewriteaof命令
   
   总结
   
   重写原理

1、bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof 在运行，如果有，则等待该命令结束后再继续执行；
2、 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞；
3.、子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失；
4、 子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件；
5.、使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写。

5.2.2.8 AOF优化配置项详解

配置文件APPEND ONLY MODE模块

总结

5.3 AOF-RDB混合持久化

两种持久化可以同时开启，但是同时开启的时候，重启redis只会加载aof文件，不会加载rdb文件，因为在通常情况下AOF文件数据比RDB文件数据更加完整，但是AOF文件时刻变化，不好做备份数据库，所有需要留着RDB文件做备份数据库作为一个万一的手段

推荐方式

结合了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持久化
• 禁用RDB和AOF持久化仍然可以通过命令的方式生成对应的持久化文件