Redis持久化机制

Redis 的持久化指的是将内存中的数据持久化到磁盘上，以便在 Redis 服务器重启或宕机时能够恢复数据。Redis 支持两种持久化方式：RDB 和 AOF。

RDB 持久化

RDB全称Redis Database Backup file (Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中.当Redis实例故障重启后，从磁盘读取快照文件，恢复数据，快照文件称为RDB文件，默认是保存在当前运行目录。

redis-cli
save #由Redis主进程来执行RDB，会阻塞所有命令

bgsave #开启子进程执行RDB，避免主进程受到影响

RDB 持久化方式分为两个部分：Snapshot 和 Save。其中 Snapshot 是指 Redis 的内存数据集，而 Save 则是将 Snapshot 持久化到硬盘上（即将内存数据快照写到 RDB 文件中）。以下是 RDB 持久化的流程：

以上就是 Redis RDB 持久化方式的原理和流程。需要注意的是，RDB 持久化方式虽然可以保证数据不丢失，但在进行持久化操作时，会将整个内存数据集写入磁盘，可能会占用大量的磁盘空间和带来一定的性能损耗。因此，在实际应用中，需要根据具体情况选择合适的持久化方式。

RDB触发机制

Redis内部由触发RDB的机制，可以在redis.confi文件中找到，格式如下：

需要注意的是，是每隔XX秒，进行一次比较，如果设置的规则是 60 秒 key 要大于 2个被修改。
则第一个60 秒检查一次，下一个60秒从头开始 继续计算时间，依次类推

引入相关问题

那么RDB这个触发机制会导致数据丢失的可能，例如此时设置的规则是 60秒进行一次保存，此时在这60秒中内redis宕机了那么就会产生数据丢失的可能。那么解决措施是什么？也就是混合持久化机制

RDB指定文件存储位置

RDB的其他配置也可以在redis.conf 文件中设置

#是否压缩，建议不开启，压缩会消耗cpu，磁盘的话不值钱
rdbcompression yes

#RDB文件名称
dbfilename dump.rdb

#文件保存的路径目录
dir ./

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

RDB的备份

我们在redis.conf文件中已经知道默认的存储文件是当前目录下的 dump.rdb 文件，那么我们可以通过命令的方式将文件进行备份

2、将*.rdb的文件拷贝到别的地方

3、rdb的恢复

• 关闭Redis
• 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
• 启动Redis, 备份数据会直接加载

RDB执行流程

fork采用的是copy-on-write技术:

• 当主进程执行读操作时，访问共享内存
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作

RDB总结

优点

• RDB快照文件是一个紧凑压缩的二进制文件，非常使用用于备份，全量复制等场景。开发中可以按照每6小时执行一次bgsave备份，用于容灾备份。
• Redis加载RDB恢复数据远远快于AOF方式
• 节省空间
• 修复快

缺点

• RDB无法做到实时持久化/秒级持久化，每次bgsave时都需要fork子进程，频繁执行有时间成本。
• RDB快照文件不同版本格式不一样，容易引起兼容问题。
• 在备份周期在一定时间做一次备份，最后一次持久化后出现宕机，容易数据丢失。

AOF 持久化

AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件

AOF三种策略

在Redis中，AOF默认是关闭的，并且提供了三种不同的策略方式，在redis.conf配置文件中进行设置

三种策略方式：

#表示每执行一次写命令，立即记录到AOF文件
appendfsync always

#写命令执行完先放入aof缓冲区，然后表示每个1秒将缓冲区数据写到AOF文件，默认方案
appendfsync everysec

#写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfync no

执行流程

AOF重写

因为AOF是记录命令，AOF文件会比RDB文件大的多，而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。

重写流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）

• 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
• 主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

总结

Redis 混合持久化

　重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小.于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。