【redis】redis持久化
1、简介
两种持久化方式
（1）RDB（Redis DataBase）：内存中数据直接写入文件中
（2）AOF（Append Of File）：以追加的行为把内容写入文件中
2、RDB
（1）概念：
指定的时间间隔内讲内存中的数据集快照写入磁盘，它恢复时可以将快照文件直接读到内存里
（2）RDB持久化流程：
Redis会单独创建fork一个子进程来进行持久化，先将数据写入一个临时文件中，待持久化过程结束后，再用这个临时文件替换上次持久化的文件，RDB方式比AOF文件更加高效，缺点是最后一次持久化的数据可能丢失。
（3）Fork：
写时复制技术：新进程的所有数据（变量、环境变量、程序计数器等）数值都有原进程一致。
Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。
阻塞只发生在fork阶段，一般时间很短。
RDB依赖于主进程fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。
fork的时候，内存中的数据备克隆了一份，大致2倍的膨胀性，需要考虑。
（4）redis.conf配置内RDB相关配置（SNAPSHOTTING内配置）
rdb文件名：dbfilename dump.rdb
文件产生的路径，默认值(启动程序的位置)：dir ./
快照的时间间隔：
# save 3600 1
# save 300 100
# save 60 10000
3、AOF
（1）概念：
以日志形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数。
优点：备份机制更稳健，丢失数据概率更低，通过操作AOF文件可以处理误操作
缺点：比RDB占用更多磁盘，恢复备份速度慢，每次读写都同步的话有性能压力
（2）AOF持久化流程
客户端在请求写命令时会被append追加到AOF缓冲区内
AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
（2）AOF持久化流程
客户端在请求写命令时会被append追加到AOF缓冲区内
AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
AOF文件rewrite重写
AOF（Append Only File）是 Redis 中一种持久化数据的方式。
当 Redis 将数据写入内存后，会将数据写入 AOF 文件中，以便在 Redis 重启时恢复数据。
AOF 文件包含了一系列 Redis 命令，这些命令记录了 Redis 服务器所执行的所有操作。
由于 AOF 文件会不断增长，所以 Redis 提供了 AOF 重写（rewrite）机制来优化 AOF 文件，减少文件大小。
AOF 重写是通过读取内存中的数据并将其写入新的 AOF 文件来实现的。
重写过程中，Redis 会将一些命令合并成一个命令，以减少 AOF 文件的大小。
AOF 重写的触发条件有两个：
手动触发：可以通过执行 BGREWRITEAOF 命令手动触发 AOF 重写。
自动触发：当 AOF 文件的大小超过了配置文件中指定的阈值时，Redis 会自动触发 AOF 重写。
AOF 重写的过程如下：
Redis 在后台创建一个子进程。
子进程开始遍历 Redis 的所有键值对，并将其转换为一系列命令。
子进程将这些命令写入新的 AOF 文件中。
子进程完成后，将新的 AOF 文件重命名为原来的 AOF 文件，覆盖原来的 AOF 文件。
Redis 继续将新的命令写入新的 AOF 文件中。
需要注意的是，AOF 重写是一个耗时的操作，可能会占用大量的 CPU 和内存资源。
为了避免影响 Redis 的性能，可以通过配置 AOF 重写的触发条件和间隔时间来控制 AOF 重写的频率。
总之，AOF 重写是 Redis 中一种优化 AOF 文件的机制，可以减少 AOF 文件的大小，提高 Redis 的性能和稳定性。
（3） redis.conf关于AOF相关配置：
开启AOF默认：，默认不开启no，开启需要修改为yes
appendonly no
AOF生成文件名：默认为appendonly.aof，生成的路径同RDB
appendfilename "appendonly.aof"
保存文件生成，同时开启AOF与RDB时，系统会使用AOF保存数据：
当AOF文件损坏，可通过如下命令执行文件修复：
redis-check-aof --fix appendonly.aof
AOF同步频率设置
设置始终同步：appendfsync always，性能较差，但是数据完整性好
每秒同步：appendfsync everysec
把同步时机交给操作系统：appendfsync no
# appendfsync always
appendfsync everysec
# appendfsync no
rewrite压缩
当AOF文件大小超过所设定的阈值时（>=64M*2），Redis会启动AOF的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof开启此功能。
使用fork子进程将原来文件重写，把rdb的快照已二进制形式附在新的aof头部，作为已有的历史数据据，替换原有的流水账操作。
no-appendfsync-on-rewrite no
参考
Redis持久化：RDB和AOF
https://mp.weixin.qq.com/s/IaJrBwUuJt_DFjIynIzF5g
Redis 持久化方式介绍 RDB+AOF，混合持久化
https://mp.weixin.qq.com/s/oKXR5-iLJcEqBYj8P36LyA
redis6.x使用指导完整版
https://www.cnblogs.com/mrwhite2020/p/14727548.html
喜欢的朋友记得点赞、收藏、关注哦！！！