一、持久化简介
面对写入时候,可能会出现一些意外的情况,比方说断电,这个时候就需要恢复数据。
所谓持久化,就是利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的机制。
持久化的目的:防止数据意外丢失,确保数据的安全性。
保存数据一般有两种形式:
二、RDB
2.1 RDB启动的方式
2.1.1 save 命令及工作原理
手动执行一次保存操作。当前快照保存在*.rdb文件中。
save相关配置:
配置 | 说明 |
dbfilename dump.rdb | 可以设置本地数据库文件名,默认dump.rdb |
dir | 存储.rdb文件的路径 |
rdbcompression yes | 设置存储至本地数据库时是否需要压缩数据,默认yes,采用LRF压缩 |
rdbchecksum yes | 设置是否需要进行RDB文件格式校验,该校验过程在读写文件过程都会进行, 通常设置默认开启,否则可能有数据损坏风险 |
save指令的工作原理:
redis是单线程工作的,当有一堆指令过来的时候,按照序列执行。
假如执行到save指令的时候,执行时间很长,那么会阻塞当前Redis服务器,直到当前RDB过程完成为止,又可能会造成长时间的阻塞,一般不建议线上使用。
2.1.2 bgsave命令及工作原理
问题:数据量过大的时候,单线程执行方式效率过低如何处理?
解决:bgsave 指令:手动启动后台保存操作,但不是立即执行
bgsave的工作原理:客户端发送指令给redis后,redis返回启动后台保存开始,然后自己调用fork函数生成子进程来完成这个保存操作,保存成功后返回消息给redis。
bgsave是对save阻塞做出的优化,redis内部所有涉及到RDB操作都采用bgsave的方式来完成。
bgsave还有一个配置需要关注下:
stop-writes-on-bgsave-error yes -------意思是后台存储过程中如果出现错误现象,是否停止保存操作;通常建议开启。
2.1.3 自动执行--save配置
问题:前两种方式都是通过手工执行命令的方式,那能不能自动执行呢?如果可以,多久执行一次呢?因为不知道数据产生了多少变化。
解决:conf文件配置:save seconds changes
作用:满足限定时间范围内key的变化数量达到指定数量即进行持久化。如果指定时间没有达到指令数量超时了,会重新计时,这里也是快照的思想。
参数:seconds : 监控时间范围 changes:监控key变化量
举例:save 1000 1 1000秒有一个变化就保存
save 60 1000 一分钟有1000个变化就保存
save配置的工作原理:
2.1.4 几种方式的对比
由于save配置后台使用的也是bgsave,因此我们对比save和bgsave即可。
方式 | save | bgsave |
读写 | 同步 | 异步 |
阻塞客户端指令 | 是 | 否 |
额外消耗内存 | 否 | 是 |
启动新进程 | 否 | 是 |
2.1.5 RDB的优缺点
优点:
缺点:
这一篇就先到这里,下一篇来说AOF。