redis - 持久化机制

redis 持久化机制

内存同步到磁盘。

RDB：根据指定的规则，定时将内存中的数据存储到磁盘上
AOF：每次执行命令后，将命令本身记录下来

RDB （快照）

RDB 的持久化方式通过快照完成，是redis 默认的持久化方式。

配置:

save <seconds> <changes>  # 

save 300 100
save 60 1000

在时间范围内，被更改的键的个数大于 changes时，触发快照生成，自动将内存中的数据生成一份副本存储在磁盘中。

生成快照的方式汇总：

1、根据配置规则进行自动快照
2、用户执行 save 或 gbsave 命令
3、执行 flushall 命令
4、执行复制时

根据配置规则进行自动快照

修改 redis.conf 文件
修改文件存储路径
- dir /data/program/redis
其他相关配置
- dbfilename: 文件名称
  
  rdbcompression：开启压缩节省存储空间，单会消耗 cpu。默认开启
  
  rdbchecksum：使用CRC64 算法继续宁数据校验，但会增加心性能消耗。
如果要关闭 RDB的持久化机制，配置如下
- save ""
  
  save 900 1

用户执行 save 或 bgsave命令

1、save命令

执行 save 命令时，会阻塞所有来自客户端的请求。不建议是使用

2、bgsave 命令

后台异步进行快照操作，同时服务还可以继续进行客户端请求的响应。

在 redis-cli 终端，通过命令可以获取最近一次成功执行快照的时间 LASTSAVE

执行原理：

redis 使用 fork 函数复制当前进程的副本（子进程）
父进程继续接受并处理i客户端的请求，子进程开始将内存中的数据写入磁盘的临时文件中
当子进程写入玩所有数据后，用临时文件替换旧的 RDB文件

注意：

redis 在进行快照的过程中不会修改 RDB文件；

RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，有利于传输。

bgsave是异步执行快照，写入的数据就是 fork进程时 redis的数据状态，一旦完成fork，后续的新的客户按命令对数据产生的变更都不会反映到本次快照。

执行 flushall 命令

清空 redis 在内存中的所有数据。只要 redis中配置了 RDB 快照规则，redis就会执行一次快照操作。

执行复制时

主从模式下，redis在复制初始化的时候自动快照（不管是否配置了快照规则）。

RDB文件的优劣势

优势

1 、RDB 是一个非常紧凑的文件，他保存了 redis在某个时间点上的数据集，这种文件非常适合用于进行备份和灾难恢复
2、生成 RDB文件时，redis 主进程会 fork 一个子进程进行快照的操作，主进程不需要进行任何磁盘IO
3、RDB在恢复大数据集的速度比 AOF 的恢复速度要快

劣势

1、RDB 方式数据 无法做到实时持久化/秒级持久化。
2、一定时间间隔做一次备份，所有会存在一段时间（最后一次备份后）的数据丢失

AOF模式

redis 默认不开启。 AOF采用日志的形式来记录每个 写操作【？？】，并追加到文件中。

持久化到磁盘

基于操作系统的缓存机制，写数据是进入到系统的 硬盘缓存。默认是基于操作系统，每 30秒执行一次同步操作，将硬盘缓存内容真正写入到硬盘。

redis.conf 中可以配置同步机制，写入AOF文件后主动要求系统将数据同步到硬盘中。

AOF 持久化策略
appendfsync everysec 默认， 每秒执行 一次， 会丢失1s 的数据
其他策略：
	no：不执行 fsync，由操作系统同步
	always 表示每次 写入都执行 fsync， 效率低

rewrite

重写机制。当 AOF文件的大小超过设置的阈值时，Redis 会启动 AOF文件的内容压缩，指标六可以恢复数据的最小指令集

bgrewriteaof   主动 触发 重写

AOF文件的重写并表示对原文件进行重新整理，而是直接读取服务器中现有的键值对，然后用一条命令代替记录这个键值对的多条命令，生成一个新的文件去替换原来 AOF文件。（当前的内存间的键值对省生成一条指令记录到AOF文件中）

重写触发机制

auto-aof-rewrite-percentage   默认100。 表示 当前的AO文件大小超过 上一次重写的AOF文件大小的百分之多少时 触发重写。
auto-aof-rewrite-min-size 默认64M。 限制了允许 重写的最小AOF文件大小。

重写流程：

主进程会 fork 一个子进程进行 AOF 重写，这个重写过程类似于快照的方式，全量遍历内存中的数据，然后逐个写入到aof文件中
在 fork 子进程过程中，服务端仍然对外提供服务。再次过程中，主进程的数据更新操作，会缓存到 aof_rewrite_buf 中，当子进程重写完成后，会把缓存中的数据追加到 aof 文件中
当所有的数全部追加到新的 aof文件后，把新的aof 文件重命名正式的文件名，此后所有的操作都直接写入到新的 aof 文件
如果在 rewrite过程中出现故障，不会影响原来的aof文件的正常工作。只有rewrite 完成后，才会进行文件的切换