【Redis】--持久化机制

由于redis的数据主要存储在内存中，内存数据是容易丢失的，一旦服务器进程退出或机器重启，内存数据就会丢失。
为了兼顾内存高性能和数据的持久安全性，redis引入了持久化机制，持久化机制会定期或在特定情况下将内存的数据以某种形式保存在磁盘中，这样，即使服务器重启，也可以从硬盘中恢复数据，保证数据持久性。
redis提供了两种持久化方式RDB和AOF

一、 RDB

rdb全称Redis Database Backup file（Redis数据备份文件)，rdb是以快照方式存储数据的，将某一瞬间的内存数据以二进制方式存储在磁盘文件中，记录实际数据，在数据恢复时，直接将rdb文件数据读取到内存中即可。

1.执行时机

• 执行save
• 执行bgsave
• Redis停机时
• 触发rdb条件时

(1).执行save命令

再执行save后,主线程直接生成rdb文件，其他命令都会被阻塞。

(2).执行bgsave命令

在执行bgsave后 ,会开启一个子进程来执行rdb，主线程可以持续处理用户请求，不受影响。

(3)停机时

redis再停机时执行一次save命令，实现数据持久化。

(4)触发RDB条件

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

save 900 1
save 300 10
save 60 10000

第一个指在900秒内，至少有一个key被修改，会执行bgsave命令，其他同理。

2.bgsave原理(copy-on-write写时复制技术)

主进程通过fork()一个子进程，利用操作系统的写时复制(copy-on-write)机制。由子进程负责将某一时刻的内存数据快照异步写入磁盘，主进程继续提供服务。

1）.共享阶段：主进程通过fork()创建一个子进程后，子进程获得主进程的完成内存映射，两者共享相同的数据页。
2）.分离阶段：子进程会遍历内存数据，将数据序列化写入rdb文件中.
此时，主进程可以正常处理客户端请求。
3）.复制时机：当主线程需要修改某一个数据页，操作系统会将这页数据创建一个副本，主进程修改副本中的数据。
4）最终结果：子进程继续将fork那一瞬间的数据写入到rdb文件中,用新的rdb文件替换旧的rdb文件。主进程在数据副本上进行修改，继续为客户端提供服务。

3.rdb的缺点

• rdb文件执行间隔时间长，两次rdb之间会有数据丢失风险.
• bgsave方式fork子进程时间长，save方式将内存数据写入磁盘时间长，其他命令会被阻塞.

二、AOF

AOF全称为Append Only File（追加文件），redis在每一次进行写命令时，会将该命令以追加的方式写入到aof文件中,当redis重启时，会执行aof文件中命令,将数据写入到文件中。

1.aof同步策略

由于直接将命令写入到磁盘中，非常慢，redis使用了缓冲技术，redis在执行完写命令时，先将命令写入到aof缓冲区中，再根据同步策略，确定何时写入到aof文件中。
aof提供了三种同步机制：

• always：每次执行写命令时会直接将命令写入到aof文件中.
• Everysec：每次执行写命令时，先将命令写入到aof缓冲区中，然后每隔一秒钟将缓冲区中的数据写入到aof文件中。
• no:有操作系统决定何时将缓冲区数据写入aof文件中。

2.aof重写机制

由于aof记录的是命令，体积会非常大，并且对于同一个key，可能会执行多次写命令，只有最后一次写操作有意义，就可以将前面的命令覆盖掉。
通过执行rewriteaof命令，可以让aof文件执行重写功能，用最小的命令达到相同的效果.
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb

3.aof优缺点

优点:

• 数据更安全：通过不同的 appendfsync 策略，最多丢失1秒的数据。
• 可读性高：AOF文件是文本格式，可以轻松查看和修改（例如误操作后，可以手动删除最后一条命令来恢复）。

缺点:

• 文件体积通常比RDB大。
• 数据恢复速度比RDB慢，因为要重新执行所有命令。
• 在重写完成前，如果宕机，会丢失重写缓冲区中的数据（但概率很低）。
• 性能相对RDB略低，尤其是在 always 策略下。

三、RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。