Redis-9-快照持久化

发表于 | 分类于

述

redis的持久化有两种方式,分别是快照持久化和AOF,具体使用哪种,需要结合项目的实际情况选择, 下面就先看一下快照持久化.

快照持久化, 就是说,redis在某个时间点上,对内存中的数据创建一个副本文件,副本文件中的数据在redis重启时会被自动加载.

配置方式

redis中,快照持久化是默认开启的,在redis.conf中,相关的配置主要有如下几项: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

save 900 1
save 300 10
save 60 10000

# 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 ./

注释删掉,就是以下几项:

1
2
3
4
5
6
7
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error: yes
rdbcompression yes
dbfilename dump.rdb
dir ./

配置解析

  • save: 前三个save的配置分别表示,900秒内至少一个键被更改则进行快照,300秒内至少10个键被更改则进行快照,60秒内至少10000个键被更改则进行快照
  • stop-writes-on-bgsave-error: 表示在快照创建出错后,是否继续执行写命令
  • rdbcompression: 表示是否对快照文件进行压缩
  • dbfilename: 表示生成的快照文件的名字
  • dir: 表示生成的文件的目录

快照持久化,默认就是开启的,在redis的文件夹下,就可以看到这个快照文件,如下:
image

如果把这个文件删掉的话,我们之前存的那些key就都没有了

快照持久化的几种方式

上面初步了解了快照持久化,那么他是怎么运行的,运行的时机是什么,来详细看一下:

第一种方式

在redis运行过程中,我们可以向redis发送一个save命令来创建一个快照, save是一个阻塞命令,也就是说,redis在接收到save命令之后,就开始创建快照,在快照创建完毕之前,其他的请求过来将会被挂起,这个命令用的不是很多,使用如下:

1
2
172.16.12.3:6379> save
OK

第二种方式

在redis运行过程中,可以通过bgsave命令去创建快照,这个命令不同于save命令的是bgsave会fork一个子进程然后由子进程去创建快照,父进程继续处理客户端的请求,这样就不会导致客户端命令阻塞了, 简单来说就是后台去创建快照,命令如下:

1
2
172.16.12.3:6379> bgsave
Background saving started

第三种方式

根据redis.conf的配置去执行快照持久化,就比如默认配置,如下:

1
2
3
save 900 1
save 300 10
save 60 10000

当配置文件中的条件满足的时候,redis就会自动触发命令进行备份,就比如第一个配置900秒内,有一个key被操作了,就执行快照持久化, 这个配置可以根据自己的实际需求去配置

第四种方式

还有一种情况会触发save命令,就是我们在执行shutdown命令的时候,也就是关闭redis服务的时候,也会执行一个save命令,进行备份的操作,并且在备份完成后将服务关闭

第五种方式

还有一种特殊情况会触发bgsave命令,就是在主从备份的时候,当从机连接上主机后,会发送一条sync命令来开始一次复制操作,此时主机会开始一次bgsave操作,并且在bgsave操作结束之后,向从机发送快照数据实现数据同步

缺点

快照持久化存在一些缺点,比如说save命令会发生阻塞,bgsave虽然不会阻塞,但是fork一个子进程又要耗费资源,在一些极端情况下,fork子进程的时间甚至超过数据备份的时间

定期的持久化也会让我们存在数据丢失的风险,最坏的情况我们可能丢失掉最近一次备份到当下的数据,具体丢失多久的数据,要看我们项目的承受能力,我们可以根据项目的承受能力配饰save参数.