Redis持久化机制（RDB原理和AOF原理）

勿以浮沙筑高台

---

Redis持久化机制

因为Redis是一种内存数据库，内存数据库总存在服务器崩盘等不可抗力元素，数据无法保存的情况下，因此我们需要一种持久化机制来保存我们的数据。

在Redis中有2种持久化机制:
RDB：在指定的时间间隔能对你的数据进行当前的状态即快照进行存储。

AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

接下来讲解一下持久化的配置

RDB

RDB配置

在我们redis安装目录下有个 redis.windows-service.conf 文件。这里面记录了一些redis的配置文件。在配置文件中，有以下这些关键参数设置

# 时间策略

# 表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
save 900 1   

# 表示300s内有10条写入，就产生快照
save 300 10

#表示60内有10000条写入，就产生快照
save 60 10000

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir ./

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

RDB演示实例

将Save改成：

# 900s内发生5个写入，产生一次快照
save  900  5

写入key

127.0.0.1:6379> set name 111
OK
127.0.0.1:6379> set name 2
OK
127.0.0.1:6379> set name 1113
OK
127.0.0.1:6379>

停止redis服务，重新启动

C:\Users\Administrator>net stop redis

Redis 服务已成功停止。


C:\Users\Administrator>net start redis
Redis 服务正在启动 .
Redis 服务已经启动成功。

查看keys

127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379>

keys为空，说明没有进行快照

下面进行写入超过5个key，然后重复上面操作进行查看

127.0.0.1:6379> keys *
1) "name6"
2) "name4"
3) "name"
4) "name5"
5) "name2"
6) "name3"

这次keys存在说明产生了快照

RDB原理解析

手动参数RDB文件的方法bgsave

步骤解析

1. 判断负进程中是否有其他子线程进行判断，为了防止2个线程对一个RDB文件操作，导致文件内容不是最新的。这里面的判断是分布式锁，判断这个锁节点是否存在，如果存在则执行，如果不存在就不执行。
2. 触发持久化，主线程调用rdbSaveBackgroud方法，创建子进程。
3. 主线程响应用户操作
4. 子线程创建RDB文件
5. 子线程通知主线程创建文件完毕。

小结：

1. RDB是快照文件，保存的是当时某个状态的节点状态，不是完整流程。
2. RDB创建过程时，通过锁，保证原子性。

AOF

AOF记录每次对服务器写的操作，当用户重启时重新执行这些操作

AOF操作配置

# 是否开启aof
appendonly yes
# 文件名称
appendfilename "appendonly.aof"
# 同步方式
appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置条件
# 当记录100条时重写数据
auto-aof-rewrite-percentage 100
# 当文件size大小到达64MB时重写
auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理
aof-load-truncated yes
# 文件重写策略
aof-rewrite-incremental-fsync yes

同步方式有三种

1. always：把每个写命令都立即同步到aof，很慢，但是很安全
2. everysec：每秒同步一次，是折中方案
3. no：redis不处理交给OS（操作系统）来处理，非常快，但是也最不安全

AOF演示实例

开启AOF

appendonly yes
appendfsync everysec

执行Set操作

127.0.0.1:6379> set name 1
OK
127.0.0.1:6379> set name2 3
OK

打开AOF记录文件，appendonly.aof，查看记录了我们每一步的操作

什么是重写操作

在AOF中有个配置操作是减少文件大小的重写操作。具体操作是将相同的步骤合并为一个操作。
手动执行重写操作指令bgrewriteaof，查看文件appendonly.aof，已经压缩成了一小节字符了，这就是重写操作。

AOF原理解析

1. 检查子进程，还是分布式锁进行检查
2. fork创建子进程，进行重写操作
3. 主线程响应User操作，并将操作记录到2个缓存区。1个缓存区的数据等待重写操作的完成。另一个缓存区的数据直接写入AOF文件。
4. 重写操作完成，将缓存区的数据写入AOF文件，并覆盖掉旧的AOF文件。

为什么要写入2个缓存区？
为了防止重写操作失败，比如重写的时候线程冲突之类的不可预料的问题。写入2个缓存区，旧AOF文件也记录了User操作，进一步保证了安全。