5、Redis持久化

RDB（默认）

在指定的时间间隔，执行数据集的时间点快照

在指定的时间间隔，执行数据集的时间点快照
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。

这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
将内存数据全部保存到磁盘dump.rdb文加中

触发机制

save的规则满足的条件下，会自动触发rdb规则
执行flushall命令，也会触发我们的rdb规则
退出redis，也会产生rdb文件

优点

适合大规模的数据恢复
按照业务定时备份
对数据完整性和一致性要求不高
RDB 文件在内存中的加载速度比AOF快得多

缺点

在一定间隔时间做一次备份，如果redis意外down机，就会丢掉最近一次快照到down机时的数据
内存数量的全量同步，如果数据量过大会导致IO严重影响服务器性能
RDB依赖于主进程的 fork ，在更大的数据集中，这可能会导致服务器请求的瞬间延迟
fork 的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑
触发案例演示

1、自动触发
Redis7版本，按照redis.conf里配置的save

扫描二维码关注公众号，回复： 15544870 查看本文章

vim /myredis/redis.conf
.....
################################ SNAPSHOTTING  ################################

# Save the DB to disk.
#
# save <seconds> <changes> [<seconds> <changes> ...]
#
# Redis will save the DB if the given number of seconds elapsed and it
# surpassed the given number of write operations against the DB.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 change was performed
#   * After 300 seconds (5 minutes) if at least 100 changes were performed
#   * After 60 seconds if at least 10000 changes were performed
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000
# 修改此处
#save 3600 1 300 100 60 100  // 3600秒 修改一次  100秒 修改60次  60秒 修改10000次 触发保存
save 5 2 # 5秒2次修改

....

修改dump文件保存路径，dump文件名称

vim /myredis/redis.conf

...
# 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 ./
dir /myredis/dumpfiles
....
....
# The filename where to dump the DB
# dump文件名称
dbfilename dump6379.rdb
.....

触发备份

# 创建保存rdb目录
mkdir -p /myredis/dumpfiles


### 重启redis服务
redis-cli -a 123456 shutdown  #停止服务
redis-server /myredis/redis.conf #启动服务

[root@VM-4-17-centos bin]# redis-cli -a 123456 -p 6379 
127.0.0.1:6379> config get dir
1) "dir"
2) "/myredis/dumpfiles"
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK

# 查看dumpfile文件大小是否有变化
ls -l /myredis/dumpfiles/

备份恢复

物理恢复，一定服务和备份分机隔离，各自存储

2、手动触发
Redis提供了两个命令来生成RDB文件分别是save和bgsave

Save
在主线程中执行会阻塞redis服务器，直到持久化工作完成才能处理其他命令， 线上禁止使用
BGSAVE（默认）
Redis 会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发过程会 fork 一个子进程由子进程复制持久化过程
lastsave 命令可以获取最后一次成功执行快照的时间

127.0.0.1:6379> set k1 v1 
OK
127.0.0.1:6379> set k2 v2
OK
# 手动触发
127.0.0.1:6379> BGSAVE
Background saving started

检查修复dump.rdb文件

#修复: redis-check-rdb 文件名
cd /usr/local/bin

redis-check-rdb dump6379.rdb

哪些情况会触发RDB快照

配置文件中默认的快照配置
手动 save/bgsave 命令
执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
执行 shutdown 且没有设置开启 AOF 持久化
主从复制时，主节点自动触发
如何禁用快照

动态所有停止 RDB 保存规则的方法:

# 命令方式
redis-cli config set save ""

# 修改配置方式
vim /myredis/redis.conf
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# 去掉注释，快照就禁用了
save ""

RDB优化配置项详解

vim /myredis/redis.conf
......
# 配置文件SNAPSHOTTING模块
# 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.
# 默认yes，如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求
stop-writes-on-bgsave-error yes

# Compress string objects using LZF when dump .rdb databases?
# By default compression is enabled 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.
# 默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
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.
# 默认yes，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
rdbchecksum yes


# An alternative (and sometimes better) way to obtain the same effect is
# to use diskless replication on both master and replicas instances. However
# in the case of replicas, diskless is not always an option.
# rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。
rdb-del-sync-files no
.......

AOF
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下，redis是没有开启AOF的
开启AOF 功能需要设置配置 ： appendonly yes
Aof保存的是appendonly.aof文件

AOF持久化工作流程

1、Client作为命令的来源，会有多个源头以及源源不断的请求命令。

2、在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。

3、AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件

4、随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。

5、当Redis Server 服务器重启的时候会从AOF文件载入数据。

AOF 缓冲区三种写回策略

三种写回策略（appendfsync）

always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
no 操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

恢复案例演示
配置文件说明

vim /myredis/redis.conf

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.
# 默认是no关闭，设置成yes开启
appendonly yes

#######aof保存路径，dir + appenddirname
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
# 修改保存路径
# dir ./
dir /myredis

# For convenience, Redis stores all persistent append-only files in a dedicated
# directory. The name of the directory is determined by the appenddirname
# configuration parameter.
appenddirname "appendonlydir"


#######aof文件保存名称
# 基本文件
# - appendonly.aof.1.base.rdb as a base file.
# 增量文件
# - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
# 清单文件
# - appendonly.aof.manifest as a manifest file.

appendfilename "appendonly.aof"

1、正常恢复
启动设置yes，修改默认的appendonly no,改为yes

vim /myredis/redis.conf

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.
# 默认是no关闭，设置成yes开启
appendonly yes

写操作继续，生成aof文件到指定的目录

redis-cli -a 123456
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k3 v1
OK


cd /myredis && ll
cd appendonlydir/ && ll

恢复1：重启redis然后重新加载，结果OK

# 停止redis
ps -ef | grep redis | grep -v grep|awk '{
    
    print $2}'|xargs kill -9

# 启动redis
cd /usr/local/bin

redis-server /myredis/redis.conf

恢复2：

写入数据进redis,然后flushdb+shutdown服务器

redis-cli -a 123456
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k3 v1
OK
127.0.0.1:6379> flushdb

# 停止服务
redis-cli shutdown

备份新生成的aof.bak,然后删除dump/aof再看恢复

cd /myredis
cp -r appendonlydir appendonlydir_bak
rm -rf appendonlydir
rm -rf dump6378.rdb

#重启redis
redis-server /myredis/redis.conf

redis-cli -a 123456
127.0.0.1:6379> keys *
(empty array)

停止服务器，拿出我们的备份修改后再重新启动服务器看看

# 停止服务
redis-cli shutdown

cd /myredis
mv appendonlydir_bak appendonlydir 

redis-server /myredis/redis.conf

redis-cli -a 123456
127.0.0.1:6379> keys *
(empty array)

2、异常恢复

故意乱写正常的AOF文件，模拟网络闪断文件写error

vim /myredis/appendonlydir/appendonly.aof.1.incr.aof

......
asdjfaldngaklfjgqqiwpoiopqwtopqr

重启Redis之后就会进行AOF文件的载入，发现启动都不行

redis-server /myredis/redis.conf

redis-cli -a 123456
Warning: Using a password with'a' or'-u' option on the command
line interface may not be safe.
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>
not connected>
not connected> lsof-i:6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> quit

异常修复

#进行修复 redis-check-aof --fix aof文件
redis-check-aof --fix /myredis/appendonlydir/appendonly.aof.1.incr.aof

优势

更好的保护数据不丢失、性能高、可做紧急恢复

劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
AOF重写机制
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

触发机制

自动触发

满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

手动触发

客户端向服务器发送bgrewriteaof命令

案例说明
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

前期配置准备

vim /myredis/redis.conf
........
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.
# 默认是no关闭，设置成yes开启
appendonly yes

........
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
auto-aof-rewrite-percentage 100
# 重写峰值修改为1k，默认64mb
auto-aof-rewrite-min-size 1k
........

# Redis can create append-only base files in either RDB or AOF formats. Using
# the RDB format is always faster and more efficient, and disabling it is only
# supported for backward compatibility purposes.
# 关闭混合，设置为no
aof-use-rdb-preamble no

自动触发案例01

完成上述正确配置，重启redis服务器执行setk1v1查看aof文件是否正常

#重启redis
redis-server /myredis/redis.conf

redis-cli -a 123456
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 v1
OK

ls -l /myredis/appendonlydir/

k1不停111111暴涨

redis-cli -a 123456
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 111111111111111111111111111111111111111111111111111111111111111
OK
127.0.0.1:6379> set k1 111111111111111111111111111111111111111111111111111111111111111
OK
127.0.0.1:6379> set k1 111111111111111111111111111111111111111111111111111111111111111
OK

重写触发

# 文件慢慢变大，到峰值后启动重写机制
ls -l /myredis/appendonlydir/

手动触发案例02

客户端向服务器发送bgrewriteaof命令

127.0.0.1:6379> set k1 v1
ok
127.0.0.1:6379> bgrewriteaof

重写原理
在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

RDB-AOF混合持久化

数据恢复顺序和加载流程
共存听AOF的

怎么选？用那个？

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件未尾
同时开启两种持久化方式
当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
那要不要只使用AOF呢
安特雷兹建议不要
因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段

RDB+AOF混合方式
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

开启混合方式设置

设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写

纯缓存模式
同时关闭RDB + AOF

save “”
禁用rdb
禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
appendonly no
禁用aof
禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件