什么是redis的持久化Redis提供了不同级别的优点

一：什么是Redis Persistence Redis Persistence

Redis 提供不同级别的持久性：

RDB的优势2：Redis的RDB是什么？

在指定的时间间隔内将内存中数据集的快照写入磁盘，行话中就是快照快照。恢复时直接将快照文件读入内存，Redis会单独创建（fork）一个子进程。持久化，数据会先写入。

在一个临时文件中，持久化过程结束后，用这个临时文件替换上一个持久化文件。整个过程中，主进程不进行任何IO操作，保证了极高的性能。如果需要进行大规模的数据恢复，并且对数据恢复的完整性不是很敏感，RDB方法比AOF方法效率更高。RDB 的缺点是最后一次持久化后数据可能会丢失。

三：Redis配置文件redis.conf与RDB配置相关

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save  
#
#   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 ""
# 存 DB 到磁盘：
#
#   格式：save  
#
#   根据给定的时间间隔和写入次数将数据保存到磁盘
#
#   下面的例子的意思是：
#   900 秒内如果至少有 1 个 key 的值变化，则保存
#   300 秒内如果至少有 10 个 key 的值变化，则保存
#   60 秒内如果至少有 10000 个 key 的值变化，则保存
#　　
#   注意：你可以注释掉所有的 save 行来停用保存功能。

#   也可以直接一个空字符串来实现停用：
#   save ""
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.
# 默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，

# 这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘，
# 否则就会没人注意到灾难的发生。
#
# 如果后台保存进程重新启动工作了，redis 也将自动的允许写操作。
#
# 然而你要是安装了靠谱的监控，你可能不希望 redis 这样做，那你就改成 no 好了。
# 如果配置成no 那么表示你不在乎数据的一致性，或者你又其他手段发现合控制。
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.
# 是否在 dump .rdb 数据库的时候使用 LZF 压缩字符串
# 默认都设为 yes
# 如果你希望保存子进程节省点 cpu ，你就设置它为 no ，
# 不过这个数据集可能就会比较大
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.
# 是否校验rdb文件  但是CRC64算法会增大大约10%的性能消耗
rdbchecksum yes
# The filename where to dump the DB
# 设置 dump 文件的默认文件文件名
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.
# 工作目录
# 例如上面的 dbfilename 只指定了文件名，
# 但是它会写入到这个目录下。这个配置项一定是个目录，而不能是文件名。

dir ./

注意，执行flushall之类的commit命令时也会生成一个新的RDB文件，所以备份时执行的RDB文件也是空的。该命令将清除内存中redis的所有数据。执行该命令后，只要redis中配置的快照规则不为空，保存规则就存在。redis 将执行快照操作。不管规则是什么，它们都会被执行。如果未定义快照规则，则不会执行快照操作。

恢复的时候，只要把rdb文件移动到redis安装目录下启动服务，就可以自动恢复了

用户执行 SAVE 或 GBSAVE 命令：

除了让Redis自动做快照外，当我们重启服务或迁移服务器时，我们还需要手动干预备份。Redis 提供了两个命令来完成这个任务

保存命令如下图所示。当执行 save 命令时，Redis 会同步执行一次快照操作，所有来自客户端的请求都会在快照执行过程中被阻塞。当redis内存中有大量数据时，传递这个命令会导致redis长时间没有响应。所以不建议在生产环境中使用该命令，但是推荐使用 bgsave 命令

bgsave 命令如下图所示。bgsave 命令可以在后台异步执行快照操作，服务器可以在拍摄快照的同时继续响应客户端的请求。执行 BGSAVE 后，Redis 会立即返回 ok 开始快照操作。在 redis-cli 终端中，可以通过 LASTSAVE 命令获取上一次成功的快照时间（UNIX 时间戳格式）。

Redis 使用 fork 函数复制当前进程（子进程）的副本。父进程继续接收和处理来自客户端的命令，而子进程开始将内存中的数据写入硬盘上的临时文件。当子进程写完所有数据后，会使用临时文件来替换旧的 RDB 文件。至此，一个快照操作完成。

Redis 在快照过程中不会修改 RDB 文件，只有在快照结束后才会用新文件替换旧文件，这意味着 RDB 文件随时都是完整的。这允许我们通过定期备份 RDB 文件来备份 redis 数据库。RDB文件是压缩的二进制文件，占用的空间会比内存中的数据小，传输更方便。

bgsave 异步执行快照。bgsave写入的数据是redis在for过程中的数据状态。一旦分叉完成，新客户端命令的后续执行将不会反映此快照中数据的更改。

Redis启动后会读取RDB快照文件，并将数据从硬盘加载到内存中。根据数据量和服务器性能，此加载时间会有所不同。

RDB文件的优缺点：

一、优势

RDB是一个非常紧凑的文件，它保存了redis在某个时间点的数据集。该文件非常适合备份和灾难恢复。

在生成RDB文件时，redis主进程会fork()一个子进程来处理所有的save工作，主进程不需要进行任何磁盘IO操作。

在恢复大型数据集时，RDB 比 AOF 更快。

二、缺点

没有办法实现RDB数据的实时持久化/秒级持久化。因为bgsave每次运行都需要进行fork操作创建子进程，频繁执行的成本太高。

每隔一定的时间做一次备份，所以如果redis意外宕机，最后一个快照之后的所有修改都会丢失（数据丢失）。如果数据比较重要，又想把损失降到最低，可以使用AOF方式进行持久化。