redis7.x 持久化之RDB

Redis的持久化包括RDB和AOF两种方式。RDB是将某一时刻的所有数据快照保存到磁盘,常用于全量备份。配置RDB保存策略如5秒内数据修改2次即触发保存,文件保存在指定目录。在数据清除后,可以通过备份文件恢复数据,确保服务重启后数据不丢失。

一 redis持久化

1.1 redis持久化

redis的持久化分为RDB和AOF持久化。

二 redis持久化RDB

2.1 RDB的作用

rdb:是redis database的简写,将一定时段的数据写入到磁盘文件中。再次启动重新加载文件写入到内存中。

2.2 RDB保存策略配置

2.2.1 保存策略配置

5秒2次修改触发保存策略

 2.2.2 保存路径配置

新建一个保存rdb文件的目录

[root@localhost export]# pwd
/root/export
[root@localhost export]# mkdir -p  myredis-data

2.2.3 保存路径配置

1.配置文件的路径

2.配置文件名

 2.2.4 重启查看配置

[root@localhost myredis]# redis-server /myredis/redis.conf
[root@localhost myredis]# ps -ef|grep redis
root      32736      1  0 11:04 ?        00:00:00 redis-server *:6379
root      32777   5776  0 11:05 pts/0    00:00:00 grep --color=auto redis

进入客户端

 2.3 RDB的自动刷新

1.触发5秒内修改2次

 2.查看文件目录,已生成文件目录 

 3.备份脚本

[root@localhost myredis-data]# cp myredis-dump.rdb myredis-dump.rdb_bck
[root@localhost myredis-data]# ls
myredis-dump.rdb  myredis-dump.rdb_bck
4.模拟清除数据,关闭服务

127.0.0.1:6379> flushall
OK
127.0.0.1:6379> shutdown
not connected> 
5.删除旧缓存文件,使用宕机之前的备份文件

[root@localhost myredis-data]# rm -rf myredis-dump.rdb
[root@localhost myredis-data]# cp myredis-dump.rdb_bck myredis-dump.rdb
[root@localhost myredis-data]# ls
myredis-dump.rdb  myredis-dump.rdb_bck

6.重启服务

[root@localhost myredis-data]# redis-server /myredis/redis.conf

7.客户端查看数据

[root@localhost ~]# redis-cli -a 123456 -p 6379 --raw
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> keys *
k3
k5
k34
k6
kb
k2
ka
k4
127.0.0.1:6379> keys *
k3
k5
k34
k6
kb
k2
ka
k4
127.0.0.1:6379> 

<think>好的,我现在要解决用户关于Redis 6.x持久化操作是由主线程还是子线程执行的问题。首先,我需要回忆一下Redis持久化机制,特别是RDB和AOF两种方式。 根据引用中的内容,用户提到了RDB持久化可以通过save和bgsave命令触发。其中,save命令由主线程执行,会导致阻塞,而bgsave会fork子进程来处理,避免主线程阻塞。这点在引用2中有明确说明。那问题来了,Redis 6.x的持久化操作是否还遵循这个机制呢? 接下来,关于AOF持久化。通常,AOF的写入是由主线程完成的,但fsync(同步到磁盘)操作可以根据配置策略不同,可能由主线程或后台线程处理。例如,appendfsync everysec可能会使用后台线程进行fsync。不过,用户提到的引用4中提到了Redis 6.x的持久化优化,是否在AOF处理上有变化呢? 用户的问题集中在Redis 6.x版本,而引用1提到Redis 6.x引入了多线程,主要是优化网络IO,但持久化操作可能还是由主线程或子进程处理。因为Redis的多线程模型主要处理网络请求,而持久化操作如RDB和AOF可能仍然沿用之前的机制,即bgsave用子进程,AOF根据策略不同可能由主线程或后台线程处理。 需要确认的是,Redis 6.x是否在持久化方面引入了多线程处理。根据已知信息,持久化的主要操作如RDB的生成和AOF的写入可能还是单线程或子进程处理,而主线程负责处理命令。因此,用户的问题答案应该是:RDB的bgsave由子进程执行,AOF的写入由主线程完成,但fsync可能由后台线程处理。同时,引用4提到了持久化状态的监控命令,可以检查RDB和AOF的状态。 总结起来,Redis 6.x中,RDB持久化通过bgsave命令使用子进程,而AOF的日志写入由主线程处理,但同步操作可能由后台线程执行,这样主线程不会被阻塞。需要引用中的内容来支持这些结论,例如引用2和引用4中的内容。</think>### Redis 6.x持久化操作的线程模型 在Redis 6.x中,**持久化操作的具体执行线程取决于持久化类型和触发方式**: --- #### **1. RDB持久化** - **手动触发**: - **`save`命令**:由主线程直接执行RDB文件生成,**会阻塞主线程**,导致服务不可用[^2]。 - **`bgsave`命令**:主线程通过`fork()`创建**子进程**完成RDB文件写入,**主线程不阻塞**[^2]。 - **自动触发**(例如根据`save`配置规则): - 与`bgsave`逻辑相同,通过**子进程**执行,避免主线程阻塞[^2]。 --- #### **2. AOF持久化** - **AOF日志写入**:由主线程完成(追加到内存缓冲区)[^4]。 - **AOF同步策略**: - **`appendfsync always`**:主线程同步刷盘,**高安全但性能差**。 - **`appendfsync everysec`**:后台线程异步刷盘(Redis 6.x优化后由独立线程处理),**平衡性能与安全**[^4]。 - **`appendfsync no`**:由操作系统控制,主线程不参与。 --- #### **3. Redis 6.x的多线程优化** - **网络I/O多线程**:Redis 6.x的「多线程」仅用于处理网络请求(读写Socket),**持久化操作仍由主线程或子进程/线程完成**[^1]。 - **后台线程**:AOF的`fsync`操作可能由后台线程执行(如`everysec`模式),减少主线程压力[^4]。 --- ### **性能影响与监控** - **阻塞风险**:主线程仅在`save`命令或`appendfsync always`模式下可能阻塞。 - **监控命令**: ```bash redis-cli info persistence # 查看rdb_last_bgsave_status和aof_last_write_status状态[^4] ``` --- 相关问题
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值