redis学习03

Redis持久化

RDB（Redis DataBase）

RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。
  实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
Redis的数据都是存在内存中，保存备份的时候RDB使用的是全量快照的方式，也就是说，把内存中所有的数据都保存在磁盘中。
配置：
1.自动触发：
Redis7版本中按照redis.conf里配置的save
  例如：配置五秒两次修改

save 5 2

配置dump.rdb文件的保存路径：
  配置文件中默认为：

dir ./

可以自定义为自己设置的路径，通过config get dir命令来获取目录

config get dir 

修改dump.rdb文件名称：
  修改配置文件：
    例如：

dbfilename dump6379.rdb

如何恢复：
将备份文件移动到redis安装目录并启动服务即可
  物理恢复，一定服务和备份分机隔离
备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，
以防生产机物理损坏后备份文件也挂了。

2.手动触发：
Redis提供了两个命今来生成RDB文件分别是save和bgsave
SAVE
  在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用
BGSAVE(默认)
  Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程
  Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据
fork
  在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。
LASTSAVE
在linux系统中可以用lastsave命令获取最后一次成功执行快照的时间

优点：
  RDB 是 Redis 数据的一个非常紧凑的单文件时间点表示。RDB 文件非常适合备份。例如，您可能希望在最近的 24 小时内每小时归档一次 RDB 文件，并在30 天内每天保存一个RDB 快照。这使您可以在发生灾难时轻松恢复不同版本的数据集。
  RDB 非常适合灾难恢复，它是一个可以传输到远程数据中心或Amazon S3 (可能已加密)的压缩文件。
  RDB 最大限度地提高了 Redis 的性能，因为 Redis 父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘 I/0 或类似操作。与AOF 相比，RDB 允许使用大数据集更快地重启
  在副本上，RDB 支持重启和故障转移后的部分重新同步。（官网解释）
总结：

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

缺点：
  如果您需要在 Redis 停止工作时(例如断电后)将数据丢失的能性降到最低，那么 RDB并不好。您可以配置生成 RDB 的不同保存点(例如，在对数据集至少5 分钟和100 次写入之后，您可以有多个保存点)。但是，您通常会每五分钟或更长时间创建一次 RDB 快照，因此，如果 Redis 由于任何原因在没有正确关闭的情况下停止工作，您应该准备好丢失最新分钟的数据。
  RDB 需要经常 fork0以便使用子进程在磁盘上持久化，如果数据集很大，fork0 可能会很耗时，并且如果数据集很大并且 CPU 性能不是很好，可能会导致 Redis 停止为客户端服务几毫秒甚至一秒钟。AOF 也需要 fork0 但频率较低，您可以调整要重写日志的频率，而不需要对持久性进行任何权衡。（官网介绍）
总结：
1. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
2. 内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
3. RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟fork的时候内存中的数据被克隆了-份，大致2倍的膨胀性，需要考虑
触发RDB快照的情况：
1. 配置文件中的默认快照方式
2. 手动save/bgsave方式
3. 执行shutdown且没有设置AOF持久化
4. 主从复制，主节点自动触发
禁用快照：
1. 动态所有停RDB保存规则的方法：

redis-cli config set save ""

2.快照禁用
配置文件中设置

save ""

AOF(Append Only File)

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下redis是没有开启AOF的。开启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秒把缓冲区中的内容写入磁盘
No
操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
总结：

配置项	写回时机	优点	缺点
Always	同步写回	可靠性高，数据基本不丢失	每个写命令都要落盘，性能影响较大
Everysec	每秒写回	性能适中	宕机时丢失1秒内的数据
No	操作系统控制的写回	性能好	宕机时丢失数据较多

AOF配置：
开启AOF：

appendnoly yes

配置保存路径：
dir + appenddirname

dir /路径
appenddirname  "名字"

恢复：
正常恢复：

1. 重启redis 然后重新加载
   异常恢复：
   修改AOF文件命令：

redis-check-aof --fix 

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

1. 相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于AOF
2. AOF运行效率要慢于RDB,每秒同步策略效率较好，不同步效率和rdb相同

AOF重写机制：
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集
触发机制：
自动触发：
满足配置文件中的选项后，Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#注意 ，同时满足，且的关系才会触发
#1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
#2 重写时满足的文件大小

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

RDB和AOF混合持久化

在同时开启RDB和AOF混合持久化时，重启时只会加载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
#仍然可以使用save 和 bgsave生成rdb文件
save ""
#禁用AOF
#仍然可以使用bgrewriteaof生成aof文件
appendony no