Redis 持久化机制(快照、AOF)
Redis 是 内存数据库,但是它也能够将存储的数据保存在硬盘上,这是由于它的持久化机制。
Redis 官方提供了两种不同的持久化方法来将数据存储到硬盘里面分别是:
- 快照 (Snapshot)
- AOF (Append Only File) 只追加日志文件
快照 (Snapshot)
这种方式可以将某一时刻的所有数据都写入硬盘中,这也是Redis 的默认开启持久化方式,保存的文件是以 .rdb
形式结尾的文件,因此这种方式也称之为 RDB方式。
快照生成方式:
- 客户端方式:
BGSAVE
和SAVE
指令 - 服务器配置自动触发
- 服务器
SHUTDOWN
自动触发
1. 客户端方式之 BGSAVE(多线程执行)
客户端可以使用 BGSAVE
命令来创建一个快照,当接收到客户端的 BGSAVE
命令时,Redis 会调用 fork
来创建一个子进程,然后子进程负责将快照写入磁盘中,而父进程则继续处理命令请求。
fork:当一个进程创建子进程的时候,底层的操作系统会创建该进程的一个副本,在类unix系统中创建子进程的操作会进行优化:在刚开始的时候,父子进程共享相同内存,直到父进程或子进程对内存进行了写之后,对被写入的内存的共享才会结束服务。
2. 客户端方式之 SAVE(单线程执行)
客户端还可以使用 SAVE
命令来创建一个快照,接收到 SAVE
命令的 Redis服务器在快照创建完毕之前将不再响应任何其他的命令;
注意:SAVE
命令并不常用,使用 SAVE
命令在快照创建完毕之前,Redis处于阻塞状态,无法对外服务。
3. 服务器配置方式之 配置快照触发条件
如果用户在 redis.conf 中设置了 save 配置选项,Redis 会在 save 选项条件满足之后自动触发一次 BGSAVE
命令;如果设置多个 save 配置选项,当任意一个 save 配置选项条件满足,Redis 也会触发一次 BGSAVE
命令。
save 900 1 表示 900s 内,执行了 1次 数据库操作则自动创建快照,以此类推。
4. 服务器接收客户端 SHUTDOWN 指令
当 Redis 通过 SHUTDOWN
指令接收到关闭服务器的请求时,会执行一个 SAVE
命令,阻塞所有的客户端,不再执行客户端执行发送的任何命令,并且在 SAVE
命令执行完毕之后关闭服务器。
配置文件中配置生成快照名称和位置
配置文件中可以修改生成快照名称以及快照保存位置:
# 生成快照名字, 默认为 dump.rdb
dbfilename dump.rdb
# 快照保存位置, 默认保存在 redis-cli 同级目录
dir ./
只追加日志文件 AOF (Append Only File)
在 Redis 的默认配置中 AOF持久化机制是没有开启的,需要在配置中开启;
# 开启 AOF持久化
appendonly yes
# 生成的日志文件名称
appendfilename "appendonly.aof"
# aof日志文件路径与快照保存位置设置的是同一个
dir ./
AOF 有 3 种 日志追加频率:
- always 【谨慎使用】
- everysec 【推荐】
- no【不推荐】
1.always【谨慎使用】
- 说明:每个 redis写命令 都要同步写入硬盘,严重降低 redis 速度;
- 解释:如果用户使用了 always 选项,那么每个 redis 写命令都会被写入硬盘,从而将发生系统崩溃时出现的数据丢失减到最少;遗憾的是,因为这种同步策略需要对硬盘进行大量的写入操作,所以 redis 处理命令的速度会受到硬盘性能的限制;
- 注意:转盘式硬盘(机械硬盘)在这种频率下200左右个命令/s;固态硬盘(SSD) 几百万个命令/s;
- 警告:使用SSD用户请谨慎使用 always 选项,这种模式不断写入少量数据的做法有可能会引发严重的 写入放大 问题,导致将固态硬盘的寿命从原来的几年降低为几个月。
2.everysec【推荐】
- 说明:每秒 执行一次同步显式的将多个写命令同步到磁盘;
- 解释:为了兼顾数据安全和写入性能,可以使用 everysec 选项,让 redis 每秒一次的频率对AOF文件进行同步;redis 每秒同步一次AOF文件时性能和不使用任何持久化特性时的性能相差无几,而通过每秒同步一次AOF文件,redis可以保证,即使系统崩溃,用户最多丢失一秒之内产生的数据。
3.no【不推荐】
- 说明:由操作系统决定何时同步;
- 解释:使用 no 选项,将完全有操作系统决定什么时候同步AOF日志文件,这个选项不会对 redis 性能带来影响,但是系统崩溃时,会丢失不定数量的数据,另外如果用户硬盘处理写入操作不够快的话,当缓冲区被等待写入硬盘数据填满时,redis 会处于阻塞状态,并导致 redis 的处理命令请求的速度变慢。
配置文件中修改同步频率
# appendfsync always
appendfsync everysec
# appendfsync no
AOF文件重写机制
AOF带来的问题
AOF的方式也同时带来了另一个问题:持久化文件会变的越来越大。
例如我们调用 incr test
命令 100 次,文件中必须保存全部的 100 条命令,其实有 99 条都是多余的,因为要恢复数据库的状态其实文件中保存一条 set test 100
就够了。为了压缩 AOF 的持久化文件,Redis 提供了 AOF重写(ReWriter)机制。
AOF 重写机制 在一定程度下减少 aof 文件的体积。
触发重写方式有两种:
1. 客户端方式 触发重写
执行 BGREWRITEAOF
命令,这种方式不会阻塞 redis 的服务;
2. 服务器配置方式 自动触发
配置 redis.conf 中的 auto-aof-rewrite-percentage 选项:
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
如果开启了 AOF持久化,以上配置代表:当AOF文件体积大于 64M,并且AOF文件的体积比上一次重写之后体积大了 100%(1倍) 时,自动触发重写。 如果重写过于频繁,可以考虑将 auto-aof-rewrite-percentage 设置的更大。
重写原理
注意:重写 aof文件 的操作,并没有读取旧的 aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof文件,替换原有的文件,这点和快照有点类似。
重写流程:
- redis 调用
fork
,现在有父子两个进程,子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令; - 父进程继续处理 client 请求,除了把写命令写入到原来的 aof文件 中,同时 把收到的写命令缓存起来,这样就能保证如果子进程重写失败的话并不会出问题。
- 当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程,然后父进程把缓存的写命令也写入到临时文件。
- 现在父进程可以使用临时文件替换老的 aof文件,并重命名,后面收到的写命令也开始往新的 aof文件 中追加。
Redis 持久化总结
两种持久化方案既可以同时使用,又可以单独使用,在某种情况下也可以都不使用,具体使用那种持久化方案取决于用户的数据和应用决定。
无论使用 AOF 还是 快照机制持久化,将数据持久化到硬盘都是有必要的,除了持久化外,用户还应该对持久化的文件进行备份(最好备份在多个不同地方)。