Redis持久化之快照(RDB)

通过前面文章的介绍,大家对于redis的基本操作应该比较了解了。本文主要介绍下redis持久化方式中的快照持久化


Redis持久化

所谓的持久化就是保持我们的数据不丢失,将数据通常保存在我们的硬盘中。在Redis中持久化的方式有两种,一种是快照持久化,一种是AOF持久化,各有各的优缺点,在项目中我们得根据实际的情况来选择具体的持久化方式。本文主要介绍快照持久化,下篇文章介绍AOF持久化

快照持久化

也叫RDB持久化方式。就是通过拍摄快照的方式来实现持久化,将某个时间的内存数据存储在一个rdb文件中。在redis服务重新启动的时候会加载rdb文件中的数据。

配置快照持久化

redis中的快照持久化默认是开启的,在redis.conf配置文件中有相关的配置选项

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1   #900秒内至少有1个key被更改就执行快照
save 300 10  #300内描述至少有10个key被更改就执行快照
save 60 10000  #60秒内至少有10000个key被更改就执行快照

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes #拍摄快照失败是否继续执行写命令

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes #是否对快照文件进行压缩

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes #是否进行数据校验

# The filename where to dump the DB
dbfilename dump.rdb #快照文件存储的名称
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./ #快照文件存储的位置

参数

默认值

说明

save

900 1

900秒内至少有1个key被更改就执行快照

save

300 10

300内描述至少有10个key被更改就执行快照

save

60 10000

60秒内至少有10000个key被更改就执行快照

stop-writes-on-bgsave-error

yes

拍摄快照失败是否继续执行写命令

rdbcompression

yes

是否对快照文件进行压缩

rdbchecksum

yes

是否数据校验

dbfilename

dump.rdb

快照文件存储的名称

dir

./

快照文件存储的位置

验证快照效果

1.进入安装目录,如果有dump.rdb文件就删除。

2.启动redis,然后添加几个数据,然后关闭redis并退出。如下

[root@hadoop-node01 redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name aaa
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> incr age
(integer) 19
127.0.0.1:6379> shutdown
not connected> exit

3.在我们的安装目录下有生成了一个dump.rdb文件,这个就是我们的快照备份文件。

4.再次启动redis,进入发现原来的数据还在,这是因为redis启动的时候加载了备份文件中的数据。

[root@hadoop-node01 redis-5.0.3]# src/redis-server redis.conf 
1211:C 13 Feb 2019 01:27:22.668 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1211:C 13 Feb 2019 01:27:22.668 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1211, just started
1211:C 13 Feb 2019 01:27:22.668 # Configuration loaded
[root@hadoop-node01 redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> get name
"aaa"
127.0.0.1:6379> get age
"19"
127.0.0.1:6379> keys *
1) "name"
2) "age"

5.关闭退出

关闭退出后删除dump.rdb文件,启动后发现数据没有了

[root@hadoop-node01 redis-5.0.3]# src/redis-server redis.conf 
1218:C 13 Feb 2019 01:29:01.336 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1218:C 13 Feb 2019 01:29:01.336 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1218, just started
1218:C 13 Feb 2019 01:29:01.336 # Configuration loaded
[root@hadoop-node01 redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> keys *
(empty list or set)

快照持久化原理

1.save命令

在redis运行中,我们可以显示的发送一条save命令来拍摄快照。save命令是阻塞命令,也就是当服务器接收了一条save命令之后就会开始拍摄快照,在此期间不会再去处理其他的请求,其他请求会被挂起直到备份结束

2.bgsave命令

bgsave命令也是立即拍摄快照,有别于save命令,bgsave并不是一条阻塞命令,而是fork一个子线程,然后这个子线程负责备份操作。而父进程继续处理客户端的请求,这样就不会造成阻塞了。

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> bgsave
Background saving started

3.根据配置文件默认快照

save 900 1   #900秒内至少有1个key被更改就执行快照
save 300 10  #300内描述至少有10个key被更改就执行快照
save 60 10000  #60秒内至少有10000个key被更改就执行快照

4.shutdown命令

当我们只想shutdown命令的时候。服务器会自动发送一条save命令来完成快照操作。并在完成备份操作后关闭服务器。所以我们当我们的操作不满足前面三种情况的时候关闭服务器后,再次打开我们的数据也不会丢失。

5.sync命令

当在主从环境中,从节点要同步主节点的数据的时候会发送一条sync命令来开发一次复制。此时主节点会发送一条bgsave命令来fork一个新的线程来完成快照并在bgsave命令操作结束后将快照文件发送给从节点来完成主从节点的数据的同步。

优缺点

优点

RDB文件是一个很简洁的单文件,它保存了某个时间点的Redis数据,很适合用于做备份。你可以设定一个时间点对RDB文件进行归档,这样就能在需要的时候很轻易的把数据恢复到不同的版本。 RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。 RDB的性能很好,需要进行持久化时,主进程会fork一个子进程出来,然后把持久化的工作交给子进程,自己不会有相关的I/O操作。 比起AOF,在数据量比较大的情况下,RDB的启动速度更快。

缺点

RDB容易造成数据的丢失。假设每5分钟保存一次快照,如果Redis因为某些原因不能正常工作,那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。 RDB使用fork()产生子进程进行数据的持久化,如果数据比较大的话可能就会花费点时间,造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候,停止服务的时间甚至会到1秒。

如何禁用快照持久化

1.在redis.conf配置文件中注释掉所有的save配置 2.在最后一条save配置追加吃命令

save ""

~好了本文到此为止,下篇文章介绍AOF持久化 更多资料欢迎参考官网手册

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏性能与架构

架构设计原则 - 高并发

实际常用:应用无状态,配置文件有状态,例如,不同的机房读取不同的配置文件,通过配置中心指定。

13750
来自专栏Zchannel

RediSQL 0.8.0 发布 将查询结果写入流中

RediSQL 0.8.0 发布了,RediSQL 是一个 Redis 模块,为 Redis 提供完整的 SQL 功能。RediSQL 支持所有 Redis 数...

10420
来自专栏我是攻城师

为什么单线程Redis性能也很出色

高性能的服务器,不一定是多线程实现的,也就是说多线程不一定比单线程效率高,这得分具体的情况。以redis为例,核心处理请求的线程只有一个,所以我们常常理解其仅仅...

24930
来自专栏Linyb极客之路

springcloud用redis做session共享出现类反序列化失败问题

前段时间项目组打算把公司的一个老项目当做现有系统的子模块,现有系统的技术框架主要是采用springcloud,用redis来做session共享。老项目的用户鉴...

1.3K20
来自专栏chenssy

Redis 分布式锁进化史解读+缺陷分析

近两年来微服务变得越来越热门,越来越多的应用部署在分布式环境中,在分布式环境中,数据一致性是一直以来需要关注并且去解决的问题,分布式锁也就成为了一种广泛使用的技...

26530
来自专栏微信公众号:Java团长

做了5年Java开发,你必须重视这一点

做了3~5年左右Java开发,你已经积累了不少项目经验,扩宽了技术广度,也许已发力成为团队管理者。到了这个阶段,大家却常有这种感受:感觉自己卡在瓶颈进步缓慢,技...

15360
来自专栏大数据成神之路

16-Flink-Redis-Sink

流式计算中,我们经常有一些场景是消费Kafka数据,进行处理,然后存储到其他的数据库或者缓存或者重新发送回其他的消息队列中。

71530
来自专栏Linyb极客之路

数据服务开发经验

有状态服务或者说数据服务,上线遇到问题很棘手,回滚无济于事;而且数据加载通常都很慢,部署时间长;最终导致不敢修改代码,谨小慎微;服务质量也是能忍就忍,不愿意深度...

18340
来自专栏IT云清

分布式锁系列--04关于分布式锁的选型分析02

2.按顺序依次向N个Redis节点执行获取锁的操作。这个获取操作跟前面基于单Redis节点的获取锁的过程相同,包含随机字符串my_random_value,也包...

8130
来自专栏Java架构

2019金三银四你准备好了没,这些Java后端面试知识点掌握了吗?

3、HashMap,HashTable,ConcurrentHashMap的区别。

17030

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励