Redis持久化
一、介绍
Redis持久化是指将Redis服务器中的数据写入磁盘，以便在服务器重启或发生故障时能够恢复数据。由于Redis是一个基于内存的数据库，如果不进行持久化，服务器一旦重启或者发生故障，内存中的数据就会丢失。
Redis之所以需要持久化是为了保证数据在发生故障或者服务器重启时不会丢失。虽然Redis是一个内存数据库，其快速读写能力使其成为一个强大的缓存工具，但内存中的数据是不稳定的，因为它们会在服务器断电或者重启时丢失。
以下是一些常见的情况，说明了为什么持久化是重要的：
- 保证数据持久性： 持久化允许将内存中的数据保存到硬盘中，使其在重启后仍然可用。这保证了数据的持久性。
- 应对故障和重启： Redis持久化是一种防止数据丢失的措施。如果服务器因为故障或者维护需要重启，持久化可以确保数据的安全。
- 备份和恢复： 持久化提供了一种简单的方法来创建数据备份，并在需要时进行恢复。
Redis提供了两种主要的持久化方式：
- RDB（Redis Database Backup）： RDB是一种快照机制，将Redis的内存数据保存到一个磁盘文件中。这个文件包含了一个特定时刻的数据库状态。RDB适用于周期性的备份，可以通过配置文件设置自动保存的条件。
- AOF（Append-Only File）： AOF是一种持续追加的日志文件，记录了每个写操作的命令。通过重新执行这些命令，可以在服务器重启后还原数据库状态。
使用这两种方式，可以根据应用的特定需求和可用资源来选择合适的持久化方式。
综上所述，持久化是Redis的一个重要功能，它确保了数据在各种情况下的安全性和可靠性，使得Redis可以在关键时刻保持数据的完整性。
官网说明:
二、RDB (Redis Database)
来自官网 - > RDB (Redis Database): RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
1、是什么
RDB持久化是Redis用于将内存中的数据以二进制文件(通常以.rdb作为文件扩展名)的形式写入磁盘的一种机制。它会在指定的时间间隔内对数据库状态进行快照，并将这个快照保存到一个磁盘文件中。这个文件包含了一个特定时刻的数据库状态，可以在需要时用于恢复数据。
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
2、能干嘛
- 数据备份和恢复： RDB允许将Redis的内存数据保存到一个磁盘文件中，创建一个特定时刻的数据库状态的快照。这个快照可以用于在需要时恢复数据，从而保证数据的持久性。
- 快速恢复： 在数据恢复的过程中，相对于AOF持久化方式，RDB可以更快地将数据从磁盘加载回内存，因为它是一个快照机制。
- 节省磁盘空间： RDB文件是一个二进制文件，相对于AOF日志文件来说，它可能会占用更少的磁盘空间，尤其在压缩过程中。
- 备份和数据迁移： RDB文件可以用于创建点对点的备份，也可以方便地将数据迁移到其他服务器。
- 周期性备份： 可以通过配置Redis服务器的持久化策略，设置自动保存RDB快照的条件，以保证数据定期地被备份。
- 避免AOF日志过大： 在使用AOF持久化时，可以利用RDB来压缩AOF日志，减小AOF文件的体积，从而节省磁盘空间。(见后续文章)
3、配置文件
Redis7版本的配置如下
# 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:
#
# 禁用RDB
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
# 在3600秒（一个小时）内，至少有一个键被修改。
# * After 3600 seconds (an hour) if at least 1 change was performed
# 在300秒（5分钟）内，至少有100个键被修改。
# * After 300 seconds (5 minutes) if at least 100 changes were performed
# 在60秒内，至少有10,000个键被修改。
# * 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
4、自动触发RDB备份
可以修改以下配置测试redis自动触发. 本案例:5秒2次修改
修改dump文件保存的路径
# 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 ./
修改dump文件名称
# The filename where to dump the DB
# 修改dump文件名称
dbfilename dump.rdb
5、手动触发RDB备份
1)、save
SAVE是一个阻塞式命令，它会阻塞Redis服务器，直到快照过程完成为止。在执行SAVE期间，Redis将在内存中的数据写入磁盘，并且在完成之前，不会响应其他命令。SAVE命令会在执行完快照后返回"OK"，表示持久化成功。
2)、bgsave
BGSAVE是一个非阻塞式命令，它会在后台异步执行快照操作，不会阻塞Redis服务器的其他操作。这意味着在执行BGSAVE的同时，Redis可以继续处理其他请求。BGSAVE命令会立即返回一个"Background saving started"的响应，表示后台快照已经开始执行。
3)、LASTSAVE
通过LASTSAVE命令获取最后一次成功执行快照的时间
6、优劣势
官方说明:
优势
- RDB是您的REDIS数据的非常紧凑的单文件时间表示。RDB文件非常适合备份。例如，您可能想在最新24小时内每小时每小时存档RDB文件，并每天节省30天的RDB快照。这使您可以轻松地在发生灾难的情况下轻松恢复数据集的不同版本。
- RDB非常适合灾难恢复，是一个可以传输到远数据中心或Amazon S3（可能加密的）的单个紧凑型文件。
- RDB最大程度地提高了REDIS的性能，因为Redis父程进程为了坚持不懈而需要做的唯一工作就是派生一个将完成其余所有工作的孩子。父进程永远不会执行磁盘I/O或类似的磁盘。
- 与AOF相比，RDB允许使用大数据集更快地重新启动。在副本上，
- RDB支持重新启动和故障转移后部分重新同步。
劣势
- 如果您需要最大程度地减少redis停止工作（例如停电后），则RDB不好。您可以在生产RDB的情况下配置不同的保存点（例如，至少五分钟后，100次写入数据集，您可以具有多个保存点）。但是，通常您会每五分钟或更长时间创建每五分钟或更长时间的RDB快照，因此，如果Redis停止工作而没有正确关闭，则应出于任何原因，您应该准备丢失最新的数据分钟。
- RDB经常需要fock()才能使用子过程在磁盘上持续存在。如果数据集很大，fock（）可能会很耗时，并且可能会导致redis停止为客户提供一些毫秒的服务，或者如果数据集非常大，并且CPU性能不佳，则可能会耗时一秒钟。AOF还需要fock（），但较少的频率，您可以调整您想在没有任何耐用性方面重写日志的频率。
总结
优势：
- 快速恢复： 在数据恢复的过程中，相对于AOF持久化方式，RDB可以更快地将数据从磁盘加载回内存，因为它是一个快照机制。
- 节省磁盘空间： RDB文件是一个经过压缩和优化的二进制文件，相对于AOF日志文件来说，它可能会占用更少的磁盘空间。
- 适合备份： RDB文件可以用于创建点对点的备份，方便将数据迁移到其他服务器。
- 周期性备份： 可以通过配置Redis服务器的持久化策略，设置自动保存RDB快照的条件，以保证数据定期地被备份。
- 避免AOF日志过大： 在使用AOF持久化时，可以利用RDB来压缩AOF日志，减小AOF文件的体积，从而节省磁盘空间。
劣势：
- 可能丢失部分数据： 由于RDB是一个定期快照机制，而不是实时记录每个写操作，因此在故障恢复方面可能会丢失一部分数据。
- 不适合高频写入场景： 如果你的应用需要高频写入数据，那么RDB的定期快照可能会对性能产生一定的影响。
7、检查修复RDB文件
redis-check-rdb /path/to/your/dump.rdb
成功的显示
$ redis-check-rdb dump.rdb
RDB looks OK
错误的显示
$ redis-check-rdb dump.rdb
*** Reading the RDB file ***
...
*** ERRORS found in the RDB file ***
...
8、那些情况下会触发RDB快照
- 配置文件中默认的快照配置
- 手动save/bgsave
- 执行flushall/flushdb命令也会产生dump.rdb文件
- 执行shutdown且没有设置开启AOF持久化
- 主从复制,直接点自动触发
9、禁用RDB快照
# 设置禁用RDB
CONFIG SET save ""
# 查看是否生效
CONFIG GET save
10、RDB优化项说明
| save [ ...] | |
|---|---|
| dbfilename dump.rdb | |
| dir ./ | |
| stop-writes-on-bgsave-error yes | 默认yes 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求 |
| rdbcompression yes | 默认yes 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能 |
| rdbchecksum yes | 默认yes 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能 |
| rdb-del-sync-files no | 在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。 |
三、AOF
1、是什么
AOF（Append-Only File）是Redis一种持久化方式，与RDB（Redis Database Backup）相对应。它记录了Redis服务器接收到的每个写操作的命令，将这些命令追加到一个文件中，从而实现了数据的持久化。
每次Redis接收到改变数据集的命令(例如SET)，它都会将其附加到AOF。当你重启Redis时，它会重新播放AOF来重建状态。从Redis 7.0.0开始，Redis使用了多部分AOF机制。也就是说，原始的单个AOF文件被分成基本文件(最多一个)和增量文件(可能有多个)。基本文件表示重写AOF时呈现的数据的初始快照(RDB或AOF格式)。增量文件包含自最后一个基本AOF文件创建以来的增量更改。所有这些文件都放在这里
默认情况下,redis是没有开启AOF的,开启AOF功能需要配置:
# 开启AOF
appendonly yes
# 保存的文件
appendfilename "appendonly.aof"
# 保存的目录
appenddirname "appendonlydir"
# 7版本新特性.文件分为三个
# 基本文件
# - 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.
2、能干嘛
- 实时记录写操作： AOF持久化会实时记录每个写操作的命令，这使得在服务器重启时能够通过重新执行这些命令来还原数据库状态。
- 高可靠性： AOF提供了更加精确和可靠的数据恢复方式，因为它记录了每个写操作，避免了RDB可能存在的数据丢失问题。
- 适用于关键数据： 对于需要最大程度保证数据安全的关键业务数据，AOF是一个比较好的选择。
- 适用于高频写入场景： 在需要高频写入的场景下，AOF相对于RDB可能更为适合，因为它实时记录写操作，避免了定期快照可能会造成的数据丢失。
- 可配置的同步策略： Redis允许你配置AOF的同步方式，包括每个写操作都同步到磁盘（
always）、每秒同步一次（everysec）或者由操作系统决定同步时间（no）。 - AOF重写： 为了避免AOF文件过大，Redis提供了AOF重写机制，可以定期地对AOF文件进行压缩和优化。
3、工作流程
| 1 | Client作为命令的来源，会有多个源头以及源源不断的请求命令。 |
|---|---|
| 2 | 在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。 |
| 3 | AOF缓冲会根据AOF缓冲区*同步文件的三种写回策略*将命令写入磁盘上的AOF文件。 |
| 4 | 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称*AOF重写)*，从而起到AOF文件压缩的目的。 |
| 5 | 当Redis Server 服务器重启的时候会从AOF文件载入数据。 |
4、AOF缓冲区三种写回策略
# aof同步写会策略 同步写回
# appendfsync always
# aof同步写会策略 每秒写回
# appendfsync everysec
# aof同步写会策略 操作系统决定
# appendfsync no
| 配置项 | 写回时机 | 优点 | 缺点 |
|---|---|---|---|
| always | 同步写回 | 可靠性高,数据基本不丢失 | 每个写命令都要落盘,性能影响高 |
| everysec | 每秒写回 | 性能适中 | 宕机时会丢失1秒钟的数据 |
| no | 操作系统控制写回 | 性能高 | 宕机时丢失的数据更多 |
5、修复AOF文件
redis-check-aof --fix
6、AOF重写机制
AOF（Append-Only File）重写是Redis提供的一种机制，用于优化AOF文件的大小，避免它不断增长导致磁盘空间消耗过大。
AOF重写的原理是通过遍历当前内存中的数据库状态，生成一系列的命令来代替已有的写操作。这样可以保留数据的完整性，同时使得新生成的AOF文件更加紧凑。
以下是AOF重写机制的一些特点和优势：
- 减小AOF文件体积： AOF文件随着时间的推移会不断增长，可能导致磁盘空间的占用过大。AOF重写可以创建一个新的AOF文件，其中只包含了当前内存中的数据状态，从而减小了AOF文件的体积。
- 保持数据的完整性： AOF重写是基于内存中的数据库状态生成的新AOF文件，因此可以保证数据的完整性。
- 不会影响Redis的正常运行： AOF重写是在后台进行的，不会影响Redis的正常操作。
- 减少磁盘IO负担： 新生成的AOF文件相对于旧文件更加紧凑，可以减少对磁盘的写入操作，从而减轻了磁盘的IO负担。
重写方式有两种
手动触发:
BGREWRITEAOF
自动触发:
# 自动重写百分比
auto-aof-rewrite-percentage 100
# 自动重写限制大小
auto-aof-rewrite-min-size 64mb
注意 ，同时满足，且的关系才会触发
- 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
- 重写时满足的文件大小
7、AOF优化项配置
| appendonly | 是否开启AOF | appendonly yes |
|---|---|---|
| appendfilename | 文件名称 | "appendonly.aof" |
| appendfsync | 同步方式 | always、everysec、no |
| no-appendfsync-on-rewrite | aof重写期间是否同步 | no-appendfsync-on-rewrite no |
| auto-aof-rewrite-percentage | 重写触发配置、文件重写策略 | auto-aof-rewrite-percentage 100 |
| auto-aof-rewrite-min-size | 重写触发配置、文件重写策略 | auto-aof-rewrite-min-size 64mb |
四、混合模式
# 官方说明
# 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.
1、加载流程
2、开启混合模式
# 前提必须开启aof
# 开启混合方式设置
aof-use-rdb-preamble yes
