Redis持久化快照两种方式

Redis持久化

所谓的持久化就是保持咱们的数据不丢失，将数据一般保存在咱们的硬盘中。在Redis中持久化的方式有两种，一种是快照持久化，一种是AOF持久化，各有各的优缺点，在项目中咱们得根据实际的状况来选择具体的持久化方式

快照持久化(RDB)

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

配置持久化快照

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 /opt/redis-5.0.3#快照文件存储的位置

参数	默认值	说明
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.db文件就删除

2.启动redis,而后添加几个数据,而后关闭redis退出

[root@root 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@root 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@root 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@root 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@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> keys *
(empty list or set)

快照持久化原理

save命令:

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

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

4.shutdown命令

当咱们只想shutdown命令的时候。服务器会自动发送一条save命令来完成快照操做。并在完成备份操做后关闭服务器。因此咱们当咱们的操做不知足前面三种状况的时候关闭服务器后，再次打开咱们的数据也不会丢失。

5.sync命令

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

优缺点

优势

RDB文件保存了某个时间点的redis数据,适合备份,你能够设定一个时间点对RDB文件进行归档，这样就能在须要的时候很轻易的把数据恢复到不一样的版本。 RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。在数据量比较打的状况下,RDB启动速度快.

缺点

RDB容易形成数据丢失,若是设置3分钟保存一次,若是redis由于一些缘由不能正常工做,那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。

如何禁用快照持久化

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

save ""

AOF持久化

与快照持久化经过直接保存 Redis 的键值对数据不一样，AOF 持久化是经过保存 Redis 执行的写命令来记录 Redis 的内存数据。理论上说，只要咱们保存了全部可能修改 Redis 内存数据的命令（也就是写命令），那么根据这些保存的写命令，咱们能够从新恢复 Redis 的内存状态。AOF 持久化正是利用这个原理来实现数据的持久化与数据的恢复的

开启AOF

在redis中aof默认是关闭的,咱们须要修改配置文件开启aof

AOF相关的配置

appendonly yes
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

参数	值	说明
appendonly	yes	是否开启AOF持久化
appendfilename	“appendonly.aof”	存储的文件的名称
appendfsync	everysec	同步频率everysec 每隔一秒钟持久化一次always 每执行一条命令持久化一次 no 持久化的时机交给操做系统处理
no-appendfsync-on-rewrite	no	执行压缩时是否执行同步操做
auto-aof-rewrite-percentage	100	当前AOF文件超过上次AOF文件的百分比后才进行持久化操做
auto-aof-rewrite-min-size	64mb	自定执行AOF操做文件最小的大小要达到的大小

关闭快照持久化

save ""
#save 900 1
#save 300 10
#save 60 10000

验证,重启服务

执行简单的命令操做 咱们能够看到append.aof文件中存储的内容就是咱们执行的命令

AOF持久化备份的注意点

1.appendfsync的取值有三个，分别是everysec，always和no，在这里咱们推荐使用everysec，不推荐使用always。由于always会严重影响服务器的性能 2.everysec最坏的状况也就只会丢失1秒的数据，影响在可控范围以内。

优缺点

优势

AOF 持久化的方法提供了多种的同步频率，即便使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。 AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，若是咱们不当心错用了 FLUSHALL 命令，在重写还没进行时，咱们能够手工将最后的 FLUSHALL 命令去掉，而后再使用 AOF 来恢复数据。

缺点

虽然 AOF 提供了多种同步的频率，默认状况下，每秒同步一次的频率也具备较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。 RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，所以从理论上说，RDB 比 AOF 方式更健壮

持久化的一些使用建议

1.若是redis仅仅是用来作为缓存服务器的话，咱们能够不使用任何的持久化。 2.通常状况下咱们会将两种持久化的方式都开启。redis优先加载AOF文件来回复数据。RDB的好处是快速。 3.在主从节点中，RDB做为咱们的备份数据，只在salve(从节点)上启动，同步时间能够设置的长一点，只留(save 900 1)这条规则就能够了。