Redis持久化机制
Redis持久化机制
RDB
RDB
是一种快照存储持久化方式,具体就是将Redis
某一时刻的内存数据保存到硬盘的文件当中,默认保存的文件名为dump.rdb
,而在Redis
服务器启动时,会重新加载dump.rdb
文件的数据到内存当中恢复数据。
手动触发
save
# 同步数据到磁盘上
> save
当客户端向服务器发送save命令请求进行持久化时,服务器会阻塞save命令之后的其他客户端的请求,直到数据同步完成。
bgsave
# 异步保存数据集到磁盘上
> bgsave
当客户端发服务发出bgsave
命令时,Redis
服务器主进程会forks
一个子进程来数据同步问题,在将数据保存到rdb
文件之后,子进程会退出。
主进程在
forks
进程时会停止接收其他命令。
服务器配置自动触发
配置文件redis.conf
指定如下的选项:
# 900s内至少达到一条写命令
save 900 1
# 300s内至少达至10条写命令
save 300 10
# 60s内至少达到10000条写命令
save 60 10000
加载配置文件
# 启动服务器加载配置文件
redis-server redis.conf
这种通过服务器配置文件触发RDB
的方式,与bgsave
命令类似,达到触发条件时,会forks
一个子进程进行数据同步,不过最好不要通过这方式来触发RDB
持久化,因为设置触发的时间太短,则容易频繁写入rdb
文件,影响服务器性能,时间设置太长则会造成数据丢失。
rdb文件
前面介绍了三种让服务器生成rdb
文件的方式,无论是由主进程生成还是子进程来生成,其过程如下:
- 生成临时
rdb
文件,并写入数据。 - 完成数据写入,用临时文代替代正式
rdb
文件。 - 删除原来的
db
文件。
RDB
默认生成的文件名为dump.rdb
,当然,我可以通过配置文件进行更加详细配置,比如在单机下启动多个redis
服务器进程时,可以通过端口号配置不同的rdb
名称,如下所示:
# 是否压缩rdb文件
rdbcompression yes
# rdb文件的名称
dbfilename redis-6379.rdb
# rdb文件保存目录
dir ~/redis/
AOF
与RDB
存储某个时刻的快照不同,AOF
持久化方式会记录客户端对服务器的每一次写操作命令,并将这些写操作以Redis
协议追加保存到以后缀为aof
文件末尾,在Redis
服务器重启时,会加载并运行aof
文件的命令,以达到恢复数据的目的。
开启AOF持久化方式
Redis
默认不开启AOF
持久化方式,我们可以在配置文件中开启并进行更加详细的配置,如下面的redis.conf
文件:
# 开启aof机制
appendonly yes
# aof文件名
appendfilename "appendonly.aof"
# 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或no
appendfsync always
# 默认不重写aof文件
no-appendfsync-on-rewrite no
# 保存目录
dir ~/redis/
写入策略
我们可以通过appendfsync
选项指定写入策略,有三个选项:
appendfsync always
# appendfsync everysec
# appendfsync no
always
这表示每当有写操作发生时,Redis都会立即将aof_buf中的内容写入磁盘。这意味着写入操作是同步进行的,由主服务器线程直接控制,这提供了最高的数据安全性,但可能会影响到Redis的性能,因为它等待磁盘I/O完成。
everysec
appendfsync
的默认写入策略,每秒写入一次aof
文件,因此,最多可能会丢失1s的数据。这是默认设置,意味着Redis每秒会自动将aof_buf
中的内容写入磁盘一次。在这个模式下,写入操作仍然是由主服务器线程触发,但是它使用了操作系统的页缓存机制,因此在大多数情况下,实际的磁盘I/O会在后台异步完成,不会显著影响Redis的响应时间。
no
在这种模式下,写入aof_buf
的操作仍然由主服务器线程控制,但是将缓冲区内容写入磁盘的同步则完全交给了操作系统,由操作系统决定何时真正将数据刷新到磁盘。这种方式提供了最佳的性能,但牺牲了数据的持久性。
AOF文件重写
AOF
将客户端的每一个写操作都追加到aof
文件末尾,比如对一个key
多次执行incr
命令,这时候,aof
保存每一次命令到aof
文件中,aof
文件会变得非常大。
incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000
aof文件太大,加载aof文件恢复数据时,就会非常慢,为了解决这个问题,Redis支持aof文件重写,通过重写aof,可以生成一个恢复当前数据的最少命令集,比如上面的例子中那么多条命令,可以重写为:
set num 100000
aof文件是一个二进制文件,并不是像上面的例子一样,直接保存每个命令,而使用Redis自己的格式。
自动重写
通过在redis.conf
配置文件中的选项no-appendfsync-on-rewrite
可以设置是否开启重写,这种方式会在每次fsync
时都重写,影响服务器性以,因此默认值为no,不推荐使用。
# 默认不重写aof文件
no-appendfsync-on-rewrite no
手动重写
客户端向服务器发送bgrewriteaof
命令。
# 让服务器异步重写追加aof文件命令
> bgrewriteaof
修复AOF文件
写入aof
日志文件时,如果Redis
服务器宕机,则aof
日志文件文件会出格式错误,在重启Redis
服务器时,Redis
服务器会拒绝载入这个aof
文件,可以通过以下步骤修复aof
并恢复数据。
- 备份现在aof文件,以防万一。
- 使用
redis-check-aof -fix file.aof
命令修复aof
文件。 - 重启Redis服务器,加载已经修复的aof文件,恢复数据。
混合持久化
重启Redis
时,我们很少使用rdb
来恢复内存状态,因为会丢失大量数据。我们通常使用AOF
日志重放,但是重放AOF
日志性能相对rdb
来说要慢很多,这样在Redis
实例很大的情况下,启动需要花费很长的时间。
Redis 4.0
为了解决这个问题,带来了一个新的持久化选项——混合持久化。AOF
在重写(aof
文件里可能有太多没用指令,所以aof
会定期根据内存的最新数据生成aof
文件)时将重写这一刻之前的内存rdb
快照文件的内容和增量的 AOF
修改内存数据的命令日志文件存在一起,都写入新的aof
文件,新的文件一开始不叫appendonly.aof
,等到重写完新的AOF
文件才会进行改名,原子的覆盖原有的AOF
文件,完成新旧两个AOF
文件的替换;AOF
根据配置规则在后台自动重写,也可以人为执行命令bgrewriteaof
重写AOF
。 于是在 Redis
重启的时候,可以先加载 rdb
的内容,然后再重放增量 AOF
日志就可以完全替代之前的 AOF
全量文件重放,重启效率因此大幅得到提升。
#redis 4.0引入
# 是否开启混合持久化
aof-use-rdb-preamble yes
原文地址:https://blog.csdn.net/qq10250507350/article/details/140308582
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!