首页 / REDIS / redis-持久化(1)
redis-持久化(1)
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了redis-持久化(1),小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含4426字,纯文字阅读大概需要7分钟。
内容图文
![redis-持久化(1)](/upload/InfoBanner/zyjiaocheng/868/bfb524dea36d40a9aaff3490bc104997.jpg)
持久化即备份,这是单机高可用的策略之一,有了备份,就可以在Redis故障通过备份进行恢复。redis持久化主要有RDB和AOF。
-
RDB
RDB(Redis DataBase),基于策略定时将redis内存中的数据保存到硬盘。需要时可以通过这个备份文件进行恢复。
-
AOF
AOF(Append Only File),是把每次redis执行的命令记录到日志文件中(类似于MySql的Bin log),当Redis启动时可以通过执行log中的命令来恢复数据
一、RDB
1.1 触发机制
save命令:阻塞当前redis服务器,直到RDB过程完成,服务器在阻塞期间不能处理如何客户端请求,原则上save命令已经废弃。
bgsave命令:会fork一个子进程,RDB的持久化由这个子进程来完成,阻塞只发生在fork阶段,耗时较短,子进程执行rdb期间redis服务器不会阻塞,正常处理客户端请求。
自动触发机制:在redis.conf 配置:
save m n
代表如果在m秒内存在n次的修改时,则执行bgsave命令
1.2 流程说明
- 执行bgsave命令,redis父进程判断如果当前存在正在执行的子进程,则直接返回,比如AOF或者RDB子进程。
- 父进程fork一个子进程,fork过程父进程是阻塞,无法响应客户端请求
- fork结束后,bgsave返回“background saving started”信息,并且不再阻塞父进程,父进程可以继续响应客户端请求。
- 子进程根据父进程的内存快照创建RDB文件,完成后对原有文件进行原子替换。
- 子进程发送信号给父进程表示RDB完成
1.3 RDB优缺点
优点
- RDB是一个压缩的二进制文件,代表Redis在某个时间点上的数据快照,适合备份,全量复制等场景
- Redis加载RDB恢复数据远远快于AOF
缺点
- RDB无法做到实时持久化
- 兼容性问题,新版本的redis可能无法兼容老版本的RDB
为了解决实时持久化问题,redis引入了AOF。
二、AOF
2.1 开启AOF
AOF默认是关闭的,通过如下命令开启:
appendonly yes
2.2 AOF流程
AOF工作基本流程:
- 命令写入(append):redis所有的写入命令会追加到aof_buf(缓冲区)中
- 文件同步(sync):AOF缓冲区根据对应的策略向硬盘做同步操作
- 文件重写(rewrite):随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的
- 重启加载(load):redis启动后可以加载AOF文件进行数据恢复。
命令写入
对于每一条redis写入命令,在AOF中会追加一条文本,文本格式是redis文本协议格式(RESP),直接采用协议格式,以来兼容性和可读性高,二来避免了二次处理的开销。
如果直接把命令写入硬盘会影响到redis的性能。先写入aof_buf,然后后期通过同步策略写入硬盘,避免直接的IO影响到redis的性能。
文件同步
redis提供了多种AOF缓冲区文件同步策略,同步策略分别使用了操作系统的wirte函数和fsync函数,说明如下:
write: 会触发延迟写(delayed write)操作,为了性能,linux在内核提供了页缓冲区用来提高硬盘的IO性能,write操作在写入系统缓冲区后直接返回,后期同步硬盘操作依赖于操作系统调度(比如按时,或者缓冲区慢等)。如果在同步前出现系统宕机故障,缓冲区的数据会丢失。
fsync: 强制操作系统将缓冲区的操作同步到硬盘。
由appendfsync参数控制:
可配置的值 | 说明 |
---|---|
always | 命令写入buf后调用系统调用fsync同步AOF文件,fsync完成后线程返回 |
no | 命令写入buf后调用系统调用write操作,后续fsync同步操作由操作系统来完成,一般为30秒一次。 |
everysec | 命令写入buf后调用系统调用write操作,后续fsync同步操作专门线程每一秒调用一次。 |
everysec是always和no的折中,是性能和安全性的这种,是redis默认的配置,也是比较推荐的配置。
文件重写
文件重写就是把Redis进程里面的最新数据转化为写命令然后同步到aof文件的过程,通过重写不但可以减小aof文件的体积,从而进一步提高aof文件在恢复过程中的加载速度。
由以下原因可以通过aof重写减少aof文件的体积:
- 旧的apf包含过期的数据不再写入aof,比如 set k1 aaa,这条命令已经过期,但是已经在aof文件中存在,通过重写这条命令将移除aof文件。
- 旧的aof中存在无效的命令,比如set k1 111,set k1 222,aof中存在两条命令,其实第一条已经失效,通过重写,可以变成一条。
- 多条命令命令合并。
触发机制:
-
手动触发:执行bgrewriteaof命令
-
自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机:
-
auto-aof-rewrite-min-size:表示运行aof重写时文件的最小体积,默认为64MB
-
auto-aof-rewrite-percentage:表示当前aof文件的size(aof_current_size)和上一次重写后aof文件的size(aof_base_size)的比值。
只有当以上两个条件同时满足时,才会触发自动aof
-
aof重写流程:
- 执行aof重写请求
- 父进程fork一个子进程,开销等同于bgsave时候fork的过程
- aof缓冲区写入
- fork结束后,主进程继续响应客户端请求,所有修改命令都会写入aof_buf,后续基于appendfsync策略写入硬盘
- 由于fork操作运用写时复制技术,子进程只能共享fork操作时的的内存数据。在执行bgrewrite期间,主进程依然在响应命令,redis用aof_rewrite_buf来保存这部分数据,防止在新的aof文件生成期间丢失这部分数据。
- 写入新的AOF,子进程基于fork后的aof_buf(快照)生成新的aof文件
- 后续操作
- 子进程发送信号通知父进程aof生成完成,父进程更新相关统计信息
- 父进程把aof_rewrite_buf的数据写入到新的aof文件
- 使用最新的aof文件替换老文件,完成最终的AOF重写。
三、重启加载流程
- 优先加载AOF
- AOF关闭时加载RDB
- 加载成功后redis才能成功启动
- 加载失败,则redis启动失败
内容总结
以上是互联网集市为您收集整理的redis-持久化(1)全部内容,希望文章能够帮你解决redis-持久化(1)所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。