Redis学习笔记-Redis持久化

1. Redis持久化

redis持久化策略就是，redis通过RDB或者AOF、以及两者组合使用来将数据写入磁盘的策略

1.1 RDB

1.1.1 是什么

在指定的时间间隔，执行数据集的时间点快照，简单来说就根据一定的时间来往硬盘写数据

1.1.2 能做什么

再指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将磁盘中快照文件直接读回到内存

保存备份时执行的是全量快照，也就是把内存中的所有数据都记录下来

保存的是cump.rdb文件

redis7以前配置文件的执行策略为 900秒内被修改一次，300秒内被修改10次，60秒内被10000次

redis7以后为 save 3600 1 300 100 60 10000

1.1.3 Redis手动生成RDB文件

Save命令：在主程序中执行会阻塞房钱的Redis服务器，知道持久化工作完成，在此期间Redis不能处理其他命令（请慎用，非常刑）

BGSAVE命令：Redis会在后台异步的进行快照操作，不会阻塞其他命令，该触发方式会fork一个子进程有子进程复制持久化过程。

fork()：再Linux系统中，fork()会产生一个和父进程完全相同的子进程，但是多会exec系统调用，处于效率考虑，尽量避免膨胀

lastsave：此命令会获取到最后一次成功执行快照操作的时间戳，通过‘ date -d @*****‘ 命令聚能将获取到的时间戳转换成人话

1.1.4 RDB的优点

• 适合大规模的数据恢复

• 可以按照业务定时备份

• 对数据的完整性和一致性不严格

• RDB文件在内存中加载速度比AOF快

1.1.5 RDB的缺点

• 在一定时间间隔做一次备份，如果redis意外down掉，那么从当前开始到最近一次快照时的数据就会丢失

• 内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器的性能

• RDB依赖于主进程的fork，在更大的数据集中部分，这可能导致服务请求的瞬间延迟。

• fork的时候内存中的数据会被克隆一份，大概两倍的膨胀性，需要考虑

1.1.6 RDB文件修复命令

1.1.7 什么操作会触发快照操作

• 触发配置文件中的默认的快照配置

• 手动执行save/bgsave命令

• 执行flushall/flushdb命令也会产生dump.rdb文件，但是文中为空，没有任何意义

• 执行shutdown且没有设置开启AOF持久化时

• 主从复制时，主节点自动触发

1.1.8 禁用RDB

命令行方法：redis-cli config set save “”

配置文件：

1.1.9 配置文件优化

save <secounds> <secounds> 设置快照操作执行的条件

dbfilename 设置rdb文件保存时的文件名

stop-writes-on-bgsave-error 默认为yes ,表示在快照写入失败时,redis是否继续接收新的写请求

rbdcompression 默认为yes,表示是否将存储到磁盘的中的快照进行压缩

rdbchecksum 默认为yes,表示是否采用CRC64算法来进行数据校验，但是会增加10%的性能消耗

rdb-del-sync-files 在没有持久性的情况下删除复制中的RDB文件

1.2 AOF

1.2.1 是什么

以日志形式来记录每个写操作，将redis执行过的所有写操作都记下来，只能追加文件但是不可以修改文件，redis启动时会读取该文件重新构建数据。（redis重启时会将日志文件中的指令都执行一遍）

AOF保存的是appendonly.aof文件

1.2.2 AOF的运行机制

1：Client作为命令的来源，他有多个源头和源源不断的命令

2：这些命令到达redis-server后并不会直接写入AOF文件中，而是进入AOF的缓冲区，缓存区存在的目的是经这些命令达到一定的量之后再写入磁盘，避免频繁的IO操作

3：AOF会根据缓冲区的三种回写策略将命令写入磁盘上的AOF文件

4：随着鞋服的AOF内容的增加，为了避免文件膨胀，会根据规则进行命令的合并，从而起到文件压缩的目的

5：当redis server服务器重启时会从AOF文件载入数据

1.2.3 三种回写机制（在配置文件中修改）

Always：同步写回，每个写命令执行完立刻同步的将这个命令写回磁盘

Everysec：每秒写回，每个命令执行完，先把日志写到内存缓冲区，每隔一秒把缓冲区内的内容写入磁盘（默认使用每秒写回策略）

No：操作系统控制写回，每个命令执行结束，先把日志文件写到缓冲区，由操作系统决定什么时候写回磁盘

1.2.4 AOF功能配置开启

1.2.4.1 开启AOF

2. 设置他的写回策略

1.2.4.2 文件的保存路径

1.2.4.3 文件的保存名称

redis7以前 只有一个文件

redis7以后变成了一到三个文件

• base基本文件（appendonly.aof.1.base.rdb）：由子进程通过重写产生只有一个

• incr增量文件（appendonly.aof.1.incr.aof）：再AOFRW开始执行是被创建，该文件可能存在多个

• manifest清单文件（appendonly.aof.manifest）：每次AOFRW成功完成，本次操作之前对应的base和incr aof都会变为history，history类型的aof会被redis自动删除

1.2.5 异常修复命令

redis-check-aof --fix [文件名]

修复有异常文件时，需要修复incr增量文件，redis-check-aof --fix appendonly.aof.1.incr.aof

1.2.6 优缺点

优点：更好的保护数据从不丢失、性能高、可做紧急恢复

缺点：相同的数据集的数据而言aof文件远大于RDB文件，恢复速度慢

aof运行效率慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

1.2.7 重写机制

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

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

手动触发：客户端向服务器发送bgrewriteaof命令

触发重写机制后文件名称变化：

重写原理：

1. 再重写开始前，redis会创建一个子进程，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩进一个临时的文件

2. 同时，主进程会将接收到的写指令一边累计到缓冲区中，一边继续写入到现有的AOF文件中，这样做是为了保证原有的AIF文件的可用性，避免出现意外

3. 当子进程完成重写后，会给父进程发一个信号，父进程手打信号后就会将内存中的缓存的写指令追加到新的AOF文件中

4. 追加结束后，redis会用心地AOF文件代替旧的AOF文件，之后再有写指令，都会写到这个AOF文件中

5. 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库用命令的方式重写了一个aof文件

总结：AOF文件重写并不是对原文件进行整理，而是直接读取服务器现有的键值对，然后生成一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换掉原来的AOF文件

1.2.8 常用配置项

1.3 RDB和AOF混合使用

1. 开启混合方式的设置

设置aof-user-rdb-preamble的值为 yes

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

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足活手动触发重写策略时，将最新的数据存储为新的RDB记录。重启服务时会从RDB和AOF两部分恢复数据，既保证可数据完整性，又提高了恢复数据的性能。（混合持久化方式生成的文件一部分是RDB格式，一部分是AOF格式）

1.4 纯缓存模式

同时关闭RDB和AOF

• save “”禁用rdb；禁用rdb持久化模式下，我们仍然可以使用save、bgsave命令生成rdb文件

• appendonly no 禁用aof；禁用情况下，我们依然可以使用bgrewriteaof命令生成aof文件