本文深入探讨Redis的持久化机制，包括RDB快照和AOF持久化。RDB通过快照保存数据，适用于全量恢复，但可能丢失最近数据；AOF记录写操作日志，确保数据安全，文件体积可能较大。建议根据业务需求选择合适的持久化策略。
Redis持久化
所谓的持久化就是保持我们的数据不丢失，将数据通常通常保存在我们的硬盘中。在Redis中持久化的方式有两种，一种是快照持久化，一种是AOF持久化，各有各的有缺点，在项目中我们得根据实际的情况来选择具体的持久化方式。
一、Redis持久化之快照（RDB）
1.概念
快照持久化也叫RDB持久化。就是通过拍摄快照的方式来实现持久化，将某个时间的内存数据存储在一个rdb文件中。在redis服务重新启动的时候会加载rdb文件中的数据
2.配置快照持久化
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 ./ #快照文件存储的位置
3.验证快照效果
①、进入安装目录，如果有dump.rdb文件就删除。
②、启动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
③、在我们的安装目录下有生成了一个dump.rdb文件，这个就是我们的快照备份文件。
④、再次启动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"
⑤、关闭退出
[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)
关闭退出后删除dump.rdb文件，启动后发现数据没有了
4.快照持久化的原理
①、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
③、根据配置文件默认快照
save 900 1 #900秒内至少有1个key被更改就执行快照
save 300 10 #300内描述至少有10个key被更改就执行快照
save 60 10000 #60秒内至少有10000个key被更改就执行快照
④、shutdown命令
当我们只想shutdown命令的时候。服务器会自动发送一条save命令来完成备份操作后关闭服务器。所以我们操作不满足前面三种情况的时候关闭服务器后，再次打开我们的数据也不会丢失。
⑤、sync命令
当在主从环境中，从节点要同步主节点的数据的时候会发送一条sync命令来开发一次复制。此时主节点会发送一条bgsave命令来fork一个新的线程来完成快照并在bgsave命令操作结束后将快照文件发送给从节点来完成主从节点的数据的同步。
5.快照持久化的优缺点
优点：
1.RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合做备份。你可以设定一个时间点对RDB文件进行归档，这样就可以能在需要的时候很轻易的吧数据恢复到不同的版本。
2.RDB很适合用于灾备。单文件很方便就能传输到远程服务器上。
3.RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O的操作
4.比起AOF，在数据量大的情况下，RDB的启动速度更快。
缺点：
1.RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。
2.RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会发费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时候甚至会到1秒。
6.如何禁止快照持久化?
1.在redis.conf配置文件中注释掉所有的save配置
2.在最后一条save配置追加空命令。
save ""
二、Redis持久化之AOF
AOF持久化概念
与快照持久化通过直接保存redis的键值对数据不同，AOF持久化时通过保存redis执行的写命令来记录Redis的内存数据。理论上说，只要我们保存了所以可能修改Redis内存数据的命令（也就是写命令），那么根据这些保存的写命令，我们可以重新恢复Redis的内存状态。AOF持久化正是利用这个原理来实现数据的持久化使数据恢复的。
1.开启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
2.关闭快照（RDB）持久化
修改如下配置：
save ""
#save 900 1
#save 300 10
#save 60 10000
3.验证
重启服务
执行简单的命令操作
我们可以看到append.aof文件中存储的内容就是我们执行的命令
4.AOF持久化备份的注意点
1.appendfsync的取值有三个，分别是everysec，always和no，在这里我们推荐使用everysec，不推荐使用always。因为always会严重影响服务器的性能
2.everysec最坏的情况也就只会丢失1秒的数据，影响在可控范围之内。
5.AOF的重写与压缩
由于 Redis 会不断地将被执行的命令记录到 AOF 文件里面，所以随着 Redis 不断运行，AOF 文件的体积会越来越大。另外，如果 AOF 文件的体积很大，那么还原操作所需要的时间也会非常地长。
为了解决 AOF 文件越来越大的问题，用户可以向 Redis 发送 BGREWRITEAOF 命令，这个命令会移除 AOF 文件中冗余的命令来重写 AOF 文件，使 AOF 文件的体积变得尽可能地小。
BGREWRITEAOF 的工作原理和快照持久化命令 BGSAVE 的工作原理类似，Redis 会创建一个子进程来负责对 AOF 文件进行重写。
值得注意的是，进行 AOF 文件重写时，如果原来的 AOF 文件体积已经非常大，那么重写 AOF 并删除旧 AOF 文件的过程将会对 Redis 的性能造成较大的影响。
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
为此，Redis 提供auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个配置选项来对 AOF 重写进行配置。auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个配置选项的含义可以参考 redis.conf 配置中的详细说明，具体来说，auto-aof-rewrite-percentage配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写，而auto-aof-rewrite-min-size则配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。只有这两个配置的条件都达到时，才会进行 AOF 重写
6.AOF的优缺点
优点：
AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。
缺点：
对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。
虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。
持久化的一些使用建议：
1.如果redis仅仅是用来做为缓存服务器的话，我们可以不使用任何的持久化。
2.一般情况下我们会将两种持久化的方式都开启。redis优先加载AOF文件来回复数据。RDB的好处是快速。
3.在主从节点中，RDB作为我们的备份数据，只在salve(从节点)上启动，同步时间可以设置的长一点，只留(save 900 1)这条规则就可以了。
4.开启AOF的情况下，主从同步是时候必然会带来IO的性能影响，此时我们可以调大auto-aof-rewrite-min-size的值，比如5GB。来减少IO的频率
5.不开启AOF的情况下，可以节省IO的性能影响，这是主从建通过RDB持久化同步，但如果主从都挂掉，影响较大~
扫一扫
1503
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
