- 持久化就是把内存的数据写到磁盘中，防止服务宕机导致内存数据丢失。
- Redis支持两种方式的持久化，一种是RDB的方式，一种是AOF的方式。前者会根据指定的规则定时将内存中的数据存储在硬盘上，而后者在每次执行完命令后将命令记录下来。一般将两者结合使用。
RDB
是什么
Redis 会单独创建一个子进程（fork）来进行持久化，先将数据写入到一个临时文件中，待持久化过程完成后，再将这个临时文件内容覆盖到 dump.rdb
[图片上传失败...(image-963a1a-1729567055873)]
Fork
- Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
- 在 Linux 程序中，fork () 会产生一个和父进程完全相同的子进程，但子进程在此后都会 exec 系统调用，出于效率考虑，Linux 中引入了 “写时复制技术”
exec
exec()系统调用是一种Unix系统编程中的重要功能，它可以让一个正在运行的程序替换另一个程序的代码和数据段，从而使新的程序替代当前的程序继续执行下去。exec()函数家族包括多种不同的函数，如execl(), execlp(), execle(), execvp() 和 execv() 等等
写时复制技术
- 假设父线程或者子线程想要修改共享的内存区域，内核就会创建一份副本，供父线程/子线程可以自由的修改副本，不会影响对象的进程状态，修改完成之后，会将副本覆盖原共享的内存区域
- 例如：java 的 CopyOnWriteArrayList
public boolean add(E e) {
// 全局锁
final ReentrantLock lock = this.lock;
// 锁定，谁都不可以修改 源数组，但是不影响读
lock.lock();
try {
// 拿到 源数组
Object[] elements = getArray();
int len = elements.length;
// 拷贝源数组，并且数组空间加1
Object[] newElements = Arrays.copyOf(elements, len + 1);
// 设置新增
newElements[len] = e;
// 替换 源数组
setArray(newElements);
return true;
} finally {
lock.unlock();
}
}
触发方式
手动触发
-
bgsave
- fork 父线程的方式
-
save
- 阻塞主进程，直到生成新的RDB文件；执行save命令期间，Redis不能处理其他命令
自动触发
- 在 redis.conf 配置文件中 SNAPSHOTTING 下配置save参数
- save 900 1：每隔900s(15min)，如果有超过1个key发生了变化，就写一份新的RDB文件
配置
- dump 文件名字 在 redis.conf 中配置文件名称，默认为 dump.rdb
[图片上传失败...(image-e16dca-1729567055873)]
- rdb 文件的保存路径可以修改。默认为 Redis 启动时命令行所在的目录下
[图片上传失败...(image-9f6eb5-1729567055873)]
- stop-writes-on-bgsave-error： 即当 redis 无法写入磁盘，关闭 redis 的写入操作
[图片上传失败...(image-c77d59-1729567055873)]
- *rdbcompression： *持久化的文件是否进行压缩存储
[图片上传失败...(image-187eca-1729567055873)]
- rdbchecksum： *完整性的检查，即数据是否完整性、准确性
[图片上传失败...(image-239b6b-1729567055873)]
-
save
- 表示写操作的次数
- 格式：save 秒 写操作次数
[图片上传失败...(image-74a5ec-1729567055873)]
优点
- Redis 加载 RDB 恢复数据远远快于 AOF 的方式
- 使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 Redis 的高性能
缺点
-
RDB方式数据无法做到实时持久化。因为
BGSAVE每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本比较高 - RDB 文件使用特定二进制格式保存，Redis 版本升级过程中有多个格式的 RDB 版本，存在老版本 Redis 无法兼容新版 RDB 格式的问题
AOF
- 默认不开启
- AOF 文件的保存路径，同 RDB 的路径一致
- 以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来 (读操作不记录)， 只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF 和 RDB 同时开启，redis 听谁的？
- AOF 和 RDB 同时开启，系统默认读取 AOF 的数据（数据不会存在丢失）。
配置
- 开启 AOF，将 no 改为 yes
[图片上传失败...(image-9d33ef-1729567055873)]
- 文件名字
[图片上传失败...(image-884720-1729567055873)]
- AOF 同步频率设置
[图片上传失败...(image-2d8646-1729567055873)]
-
appendfsync always
- 始终同步，每次 Redis 的写入都会立刻记入日志
- 性能较差但数据完整性比较好
-
appendfsync everysec
- 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
-
appendfsync no
- Redis 不主动进行同步，把同步时机交给操作系统。
-
Rewrite 压缩
- 当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof
[图片上传失败...(image-94333e-1729567055873)]
AOF 重写
问题
随着Redis执行的写命令越来越多，AOF日志的文件大小会越来越大，会带来以下问题：
- 系统本身对文件大小有限制，无法保存过大的文件
- 当文件过大时，往后面追加内容的性能就会变差
- 当文件过大时，通过其进行数据恢复时，过程会比较慢
AOF 重写
AOF Rewrite 的原理是，主进程fork一个子进程，对当前内存中的数据进行遍历，转换成一系列的redis操作指令，并序列化到一个新的AOF日志中，然后把序列化操作期间新收到的操作指令追加到新的AOF文件中，追加完毕后就立即替换旧的AOF文件
优点
- AOF可以更好的保护数据不丢失，可以配置 AOF 每秒执行一次fsync操作，如果Redis进程挂掉，最多丢失1秒的数据
- 可读的日志文本，通过操作 AOF 稳健，可以处理误操作
缺点
- 比起 RDB 占用更多的磁盘空间
- 恢复备份速度要慢
- 每次读写都同步的话，有一定的性能压力；
- 存在个别 Bug，造成不能恢复
RDB 和 AOF 怎么选择
- 官方推荐两个都启用。
- 如果对数据不敏感，可以选单独用 RDB。
- 不建议单独用 AOF，因为可能会出现 Bug。
- 如果只是做纯内存缓存，可以都不用
语雀文档：https://www.yuque.com/heyyall/summary/gq40cg5i4aprhyd5
CSDN: https://blog.csdn.net/a2497_282263/article/details/134222031
稀土掘金：https://juejin.cn/post/7428154067388104754
