持久化

用户9187

9月21日修改

RDB

默认开启

什么时候触发？

1.
命令触发， save 、 bgsave、flushall​

2.
通常在服务退出时会触发，调用 save​

3.
周期函数检测达到策略阈值会触发，调用 bgsave​

4.
主从全量复制发送 RDB 文件​

策略默认阈值

代码块

save 900 1  # 900秒（15分钟）内至少有1个键被修改时，触发一次持久化​
save 300 10 # 300秒（5分钟）内至少有10个键被修改时，触发一次持久化​
save 60 10000 # 60秒（1分钟）内至少有10000个键被修改时，触发一次持久化​

持久化过程

当周期函数检测达到策略阈值时，会 fork 一个子进程。 这个子进程通过复制页表的方式与主进程共享内存，并开始将数据写入到临时的 RDB 文件​

在这个过程中主进程可能会有读写操作，当有写操作时，主进程会将共享内存复制一份（即写时复制 copy and write），用于自身进行数据修改， 保证与子进程的持久化过程使用的内存隔离，这样不会影响子进程进行 RDB 持久化​

当子进程的 RDB 持久化过程完成以后，子线程会被销毁且使用的内存空间也会被销毁。​

注意，RDB 持久化的过程中，主进程所做的修改是不会被子进程写入到RDB文件中的​

AOF

AOF 是通过记录所有写操作命令来实现数据持久化的。AOF 文件包含了 Redis 服务启动以来执行的所有写操作命令，按顺序记录。当 Redis 重启时，它会通过重新执行 AOF 文件中的命令来恢复数据。​

也体现了日志即事实的思想

主要特点

1. 更高的数据安全性：

AOF 能够提供更高的数据安全性。你可以通过配置 AOF 持久化策略来确定写操作命令何时同步到磁盘。​

2. 可读性：

AOF 文件是以 Redis 命令的格式（逻辑日志）保存的，具有良好的可读性，这使得调试和分析问题更加方便。​

3. 日志重写：

随着时间的推移，AOF 文件会变得越来越大。Redis 提供了日志重写机制，通过创建新的 AOF 文件来压缩旧的日志文件，从而减少文件大小。​

通过配置文件开启 AOF

代码块

appendonly yes

三种刷盘策略

Redis 提供了三种刷盘策略（即将 AOF 缓冲写入磁盘），可以通过配置 appendfsync 参数来设置：​

        •        appendfsync always：每次写操作都会立即同步到磁盘，最安全但性能最差。​

        •        appendfsync everysec：每秒钟同步一次，平衡了性能和安全性。​

        •        appendfsync no：不主动同步，由操作系统决定何时进行同步，性能最好但最不安全。​

官方推荐第二种，默认也是第二种

PS：从这里结合 MySQL 的 redo 日志刷盘策略， MySQL 默认选择的是方式一。因此，MySQL 选择了一致性，Redis 平衡了性能，抛弃了部分一致性​

持久化过程

每次有写入操作时，会将写入命令记录到 AOF 缓冲区，根据策略进行如下操作：​

若appendfsync=always，则立即写入磁盘，这个过程是同步阻塞的

若appendfsync=everysec，则由主进程异步执行的，主进程定期（每秒）将 AOF 缓存写入到磁盘​

若appendfsync=no，不做刷盘处理，交给操作系统的文件系统缓冲机制自行刷盘​

持久化​