首页 / REDIS / Redis数据持久化
Redis数据持久化
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Redis数据持久化,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含9572字,纯文字阅读大概需要14分钟。
内容图文
![Redis数据持久化](/upload/InfoBanner/zyjiaocheng/862/ad996c5a4ed940128357165c23f52cd9.jpg)
文章目录
1.持久化
1.1. 持久化简介
持久化(Persistence
),持久化是将程序数据在持久状态和瞬时状态间转换的机制,即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。
RDB持久化方式
:可以在指定的时间间隔能对数据进行快照存储.
AOF持久化方式
:记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
如果服务器开启了AOF持久化功能。服务器会优先使用AOF文件还原数据。只有关闭了AOF持久化功能,服务器才会使用RDB文件还原数据.
2. RDB持久化
RDB文件是一个经过压缩的二进制文件(默认的文件名:dump.rdb
)
2.1. RDB文件持久化创建与载入
在 Redis持久化时, RDB 程序将当前内存中的数据库状态保存到磁盘文件中, 在 Redis 重启动时, RDB 程序可以通过载入 RDB 文件来还原数据库的状态。
2.2. 触发条件
RDB持久化的触发分为手动触发
和自动触发
两种。
2.2.1.手动触发
save
命令和bgsave
命令都可以生成RDB文件。
SAVE
同步操作,在执行该命令时,服务器会被阻塞,拒绝客户端发送的命令请求
redis> save
save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求。
BGSAVE
异步操作,在执行该命令时,子进程执行保存工作,服务器还可以继续让主线程处理客户端发送的命令请求
redis>bgsave
而bgsave命令会创建一个子进程,由子进程来负责创建RDB文件,父进程(即Redis主进程则继续处理请求。
bgsave命令执行过程中,只有fork子进程时会阻塞服务器,而对于save命令,整个过程都会阻塞服务器,因此save已基本被废弃,线上环境要杜绝save的使用。
2.2.2.自动触发
在自动触发RDB持久化时,Redis也会选择bgsave而不是save来进行持久化。
自动触发最常见的情况是在配置文件中通过save m n
,指定当m秒内发生n次变化时,会触发bgsave。
比如:
/*服务器在900秒之内,对数据库进行了至少1次修改*/
Save 900 1
/*服务器在300秒之内,对数据库进行了至少10次修改*/
Save 300 10
/*服务器在60秒之内,对数据库进行了至少10000次修改*/
Save 60 10000
只要满足其中一个条件就会执行BGSAVE命令
2.2.3.其他自动触发机制
除了save m n 以外,还有一些其他情况会触发bgsave:
●在主从复制场景下,如果从节点执行全量复制操作,则主节点会执行bgsave命令,并将rdb文件发送给从节点。
●执行shutdown
命令时,自动执行rdb持久化。
2.3.RDB 默认配置
################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#在给定的秒数和给定的对数据库的写操作数下,自动持久化操作。
# save <seconds> <changes>
#
save 900 1
save 300 10
save 60 10000
#bgsave发生错误时是否停止写入,一般为yes
stop-writes-on-bgsave-error yes
#持久化时是否使用LZF压缩字符串对象?
rdbcompression yes
#是否对rdb文件进行校验和检验,通常为yes
rdbchecksum yes
# RDB持久化文件名
dbfilename dump.rdb
#持久化文件存储目录
dir ./
3.AOF持久化
3.1.AOF持久化简介
AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态.
RDB持久化是将进程数据写入文件,而AOF持久化,则是将Redis执行的每次写、删除命令记录到单独的日志文件中,查询操作不会记录; 当Redis重启时再次执行AOF文件中的命令来恢复数据。
与RDB相比,AOF的实时性更好,因此已成为主流的持久化方案。
3.2.AOF持久化功能实现
- append命令追加:当AOF持久化功能处于打开状态时,服务器执行完一个写命令会协议格式被执行的命令追加服务器状态的aof_buf缓冲区的末尾。
reids>SET KET VAULE
//协议格式
\r\n$3\r\nSET\r\n$3\r\nKEY\r\n$5\r\nVAULE\r\n
- 文件写入和同步sync:当执行了append命令追加后,服务器会调用
flushAppendOnlyFile
函数是否需要将AOF缓冲区的内容写入和保存到AOF文件
3.3.AOF持久化策略
AOF持久化策略(即缓冲区内容写入和同步sync到AOF中),可以通过配置appendfsync属性来选择AOF持久化策略:
always:将aof_buf缓冲区中的所有内容写入并同步到AOF文件,每次有新命令追加到 AOF 文件时就执行一次 fsync。
everysec(默认):如果上次同步AOF的时间距离现在超过一秒,先将aof_buf缓冲区中的所有内容写入到AOF文件,再次对AOF文件进行同步,且同步操作由一个专门线程负责执行。
no:将aof_buf缓冲区中的所有内容写入到AOF文件,但并不对AOF文件进行同步,何时同步由操作系统(OS)决定。
AOF持久化策略的效率与安全性:
Always
:效率最慢的,但安全性是最安全的,即使出现故障宕机,持久化也只会丢失一个事件 循环的命令数据
everysec
:兼顾速度和安全性,出现宕机也只是丢失一秒钟的命令数据. 每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中
No
:写入最快,但综合起来单次同步是时间是最长的,且出现宕机时会丢失上传同步AOF文件之后的所有命令数据。完全依赖os,性能最好,持久化没保证。
4.AOF重写
4.1.Why
AOF(append only file)对Redis进行持久化是通过保存被执行的写命令来记录数据库状态的,随着服务器运行,AOF文件内容越来越多,载入AOF文件的时间会越来越长,影响Redis服务。
所以有必要对’冗余‘的AOF文件进行优化,即AOF文件重写。
那为什么要进行AOF后台重写?因为Redis单线程特性,AOF重写操作会引入大量写操作,引起stop the world,所以fork出子进程执行AOF后台重写,这样父进程可以继续处理命令请求。
4.2.AOF重写原理
怎么重写?是对旧的AOF文件进行读取、分析后进行优化吗?Redis没有采用,Redis是通过读取服务器当前数据库状态实现该功能的。
举个例子:
对一个animals键执行以下命令:
SADD animals "Cat"
SADD animals "Dog" "Tiger"
SREM animals "Tiger"
为了保存上述状态,AOF需要进行3次命令保存。
AOF重写后只需要读取animals键的所有值,再用SADD animals “Cat” "Dog"
一条命令即可。
从3条减少为1条,减少了文件体积。
4.3.AOF后台重写原理(BGREWRITEAOF命令)
使用子进程(而不是开启一个线程)进行AOF重写虽然可以避免使用锁的情况下,保证数据安全性,但是会带来子进程和父进程一致性问题。
例如在开始重写之后父进程又接收了新的键值对此时子进程是无法知晓的,当子进程重写完成后的数据库和父进程的数据库状态是不一致的。
见下表:
在T7时刻服务器进程有了4个键,而子进程只有1个键,即所谓的漏追加。
为了解决这种不一致性,redis设置了一个AOF重写缓冲区。
在子进程执行AOF重写期间。服务器进程需要执行以下3个动作:
1.执行客户端命令
2.执行后追加到AOF缓冲区
3.执行后追加到AOF重写缓冲区
执行完上述3个操作后可以保证:
- AOF缓冲区内容会定期被写入和同步到AOF文件,对现有AOF文件处理正常进行
- 子进程开始,服务器执行的所有写命令都会进入AOF重写缓冲区
子进程完成AOF重写后,它向父进程发送一个信号,父进程收到信号后会调用一个信号处理函数,该函数把AOF重写缓冲区的命令追加到新AOF文件中然后替换掉现有AOF文件。父进程处理完毕后可以继续接受客户端命令调用,可以看出在AOF后台重写过程中只有这个信号处理函数会阻塞服务器进程。
下表是完整的AOF后台重写过程:
T8 T9执行的任务会阻塞服务器处理命令。
5.AOF持久化默认参数
############################## APPEND ONLY MODE ###############################
#开启AOF持久化方式
appendonly no
#AOF持久化文件名
appendfilename "appendonly.aof"
#每秒把缓冲区的数据fsync到磁盘
appendfsync everysec
# appendfsync no
#是否在执行重写时不同步数据到AOF文件
no-appendfsync-on-rewrite no
# 触发AOF文件执行重写的增长率 aof文件大小比起上次重写时的大小,增长率100%时,重写.
auto-aof-rewrite-percentage 100
#触发AOF文件执行重写的最小size
auto-aof-rewrite-min-size 64mb
#redis在恢复时,会忽略最后一条可能存在问题的指令
aof-load-truncated yes
#正在到处rdb快照的过程中,要不要停止同步aof
no-appendfsync-on-rewrite yes:
#是否打开混合开关
aof-use-rdb-preamble yes
手动执行重写的命令是:
执行重写可以在登录状态下执行,直接输入bgrewriteaof
.
6.持久化方式总结与抉择
6.1.RDB的优点
RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
基于RDB文件紧凑性,便于复制数据到一个远端数据中心,非常适用于灾难恢复.
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能.
与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些.
6.2.RDB的缺点
如果你希望在redis意外停止工作(例如电源中断)的情况下丢失的数据最少的话,那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.
6.3.AOF优点
(1)AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync操作,最多丢失1秒钟的数据。
(2)AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易破损。
(3)AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。
(4)AOF日志文件的命令通过非常可读的方式进行记录,这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据,只要这个时候后台rewrite还没有发生,那么就可以立即拷贝AOF文件,将最后一条flushall命令给删了,然后再将该AOF文件放回去,就可以通过恢复机制,自动恢复所有数据
6.4.AOF缺点
(1)对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大
(2)AOF开启后,支持的写QPS会比RDB支持的写QPS低,因为AOF一般会配置成每秒fsync一次日志文件,当然,每秒一次fsync,性能也还是很高的
7.如何选择使用哪种持久化方式?
一般来说,选择的话,两者加一起才更好.
其他问题说明
注:在dump.rdb过程中,aof如果停止同步,会不会丢失?
答:不会,所有的操作缓存在内存的队列里,dump完成后统一操作.
注:aof重写指得是什么
答:aof重写是指把内存中的数据逆化成命令,写入到.aof日志里,已解决aof日志过大的问题.
注:如果rdb文件,和aof文件都存在,优先用谁来恢复数据?
答:aof
注:两种是否可以同时用?
答:可以,而且推荐这样做.
注:恢复时 rdb和aof哪个恢复的快?
答:rdb快,因为其是数据的内存映射,直接载入到内存,二aof是命令需要逐条执行.
注意点:如果两种持久化方式都开启,则以aof为准,虽然快照方式恢复速度快,但是最终被aof给覆盖,所以两种方式都开启时,以aof为准.
内容总结
以上是互联网集市为您收集整理的Redis数据持久化全部内容,希望文章能够帮你解决Redis数据持久化所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。