Redis02-持久化策略

目录

RDB（Redis DataBase Backup file）

RDB执行原理

AOF（Append-Only File）

RDB和AOF对比

---

Redis支持多种持久化方式，以确保数据在内存中持久存储，以便在Redis服务器重启时数据不会丢失。Redis中持久化的两种主要实现方式：RDB和AOF。

RDB（Redis DataBase Backup file）

RDB是Redis的快照持久化方式，它会在指定的时间间隔内生成数据快照并将其保存到磁盘上的一个文件中。RDB文件包含了数据库的数据和键的过期时间信息。RDB持久化是一个点对点的持久化方式，它适用于数据快照的定期备份，以及在Redis服务重启时快速恢复数据。

RDB持久化可以通过配置文件设置，允许管理员指定快照的保存频率和文件名。RDB文件通常以二进制格式存储，可以通过SAVE或BGSAVE命令手动触发持久化。

[root@10 ~]# redis-cli -h 127.0.0.1 -p 6379 -a 'password' #用密码方式连接
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> save  #由Redis主进程执行RDB，会阻塞所有命令
OK
127.0.0.1:6379> bgsave  #开启子进程执行RDB，避免主线程受影响
Background saving started
127.0.0.1:6379> 

Redis内部有触发RDB的机制，在redis.conf文件中：

# Save the DB to disk.
#
# save <seconds> <changes>
#
# Redis will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# 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 key changed
#   * After 300 seconds (5 minutes) if at least 100 keys changed
#   * After 60 seconds if at least 10000 keys changed
#
# You can set these explicitly by uncommenting the three following lines.
#
# save 3600 1
# save 300 100
# save 60 10000

说明一下：

# save "" 这是禁用RDB
save 3600 1 # 表示每小时有至少1个key发生变化，就执行bgsave
save 300 100 # 表示每5分钟有至少100个key发生变化，就执行bgsave
save 60 10000 # 表示每1分钟有至少10000个key发生变化，就执行bgsave

RDB执行原理

1. Redis使用fork函数复制一份当前进程(父进程)的副本(子进程)。

2. 父进程接收处理客户端命令，子进程将内存中的数据写入硬盘中的临时文件。

3. 当子进程写入完所有数据后，使用临时文件替换旧的RDB文件，至此一次快照操作完成。

需要注意的是：

• 页表：记录虚拟地址与物理地址的映射关系（操作系统：用户空间程序只能访问虚拟内存，而不是直接操作物理内存）。

• Fork采用的是一种copy-on-write的策略，目的是防止数组脏写：

  • 父进程读数据时共享读取

  • 父进程写数据是拷贝副本单独写操作

• 在最近一次RDB和下一次RDB间隔期间出现Redis服务宕机，是会丢失这批数据的。

Redis启动后会读取RDB文件，文件是压缩过的二进制格式。占用空间小，利于传输和恢复。读取的时间根据服务器性能、数据结构、数据量大小会有不同差异。通常一个记录1000万个字符串类型键、大小为1GB的快照文件载入内存需要花费20-30秒。

RDB实现持久化，一旦出现异常退出，恢复的时候只能恢复到最近一次RDB的节点数据。如果数据比较重要，希望将损失降到最小，那么可以使用AOF进行持久化。

AOF（Append-Only File）

AOF是Redis的追加日志持久化方式，它将每个写操作（包括SET、INCR等）追加到一个日志文件中，以记录数据库操作的历史。AOF文件包含了一系列命令，它们可以用于重建数据库状态。

AOF持久化可以通过配置文件设置，可以选择以同步（fsync）或异步（no fsync）方式将操作追加到AOF文件中。同步方式可以保证数据的完整性，但通常会降低性能。异步方式则更快，但在发生故障时可能会导致数据丢失。

AOF默认是关闭的，在redis.conf文件进行设置：

# 是否开启AOF，默认是no
appendonly yes 
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率(也叫刷盘策略)是可以通过redis.conf配置的：

# appendfsync always 表示每执行一次写命令，立即记录到AOF文件 
appendfsync everysec # 推荐的，也是默认的每秒刷盘策略
# appendfsync no 表示写命令执行完先放到AOF缓冲区，由操作系统决定何时将缓冲区内容写入磁盘

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

由于AOF记录的是写命令，文件比RDB大的多。而且AOF会记录对同一个key的多次操作，但只有最后一次写操作才有意义。我们可以通过bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的结果。

AOF也会在触发阈值时自动重写AOF文件。阈值可以在redis.cof配置：

# AOF文件比上次增长超过多少百分比触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积达到多少触发重写
auto-aof-rewrite-min-size 64mb

RDB和AOF对比

** **	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

两者各有优缺点，而实际的项目中往往是结合一起使用的，以提供更可靠的数据保护。在Redis重启时，会优先使用AOF日志文件来恢复数据，因为AOF记录了更详细的操作历史。如果AOF文件不存在或损坏，Redis可以使用RDB文件来进行数据恢复。