6.4 如何选用持久化方式

6.4.1 对比两种持久化方式

AOF可以设置一秒写一次持久化文件,所以相对RDB而言,这种方式能更好地记录内存数据,从而能更好地达到持久化的效果,且AOF是以"在文件末尾追加"的方式写入数据,所以性能较好.不过AOF持久化的文件一般会大于RDB快照,所以用AOF恢复数据时速度会比RDB要慢

在某些个别场景里,Redis服务器在重启时无法加载AOF持久化文件,从而导致无法恢复数据,这种情况虽然出现的概率很小,但是一旦出现,或许就是灾难性的

---

某些场景是指:

1. AOF文件损坏:

   • 如果Redis或宿主机突然崩溃,如电源故障,这可能会导致AOF文件的某些部分不完整或损坏

   • 如果磁盘已满或发生其他文件系统错误,可能会导致AOF文件写入不完整

2. AOF格式版本不兼容:

   • 如果你尝试使用一个较新版本的Redis加载一个由较旧版本的Redis创建的AOF文件,可能会遇到兼容性问题

3. 文件系统权限问题:

   • 如果Redis进程没有适当的权限来读取AOF文件或其所在的目录,它将无法加载该文件

4. 配置问题:

   • 如果Redis的配置文件中的appendonly选项被设置为no,那么Redis将不会加载AOF文件,即使它存在

   • appendfilename或dir配置可能指向了错误的AOF文件或目录

5. AOF文件过大:

   • 如果AOF文件非常大,Redis在启动时可能需要较长时间来加载它.虽然这并不是一个真正的"无法加载"的情况,但在实际操作中可能会被误解为加载失败

6. 硬件问题:

   • 磁盘故障、损坏的RAM或其他硬件问题可能会影响AOF文件的完整性和可读性

7. 外部因素:

   • 如果有外部进程(例如备份或监控工具)锁定了AOF文件,这可能会干扰Redis读取文件

8. AOF文件内部的命令错误:

   • 在某些情况下,AOF文件中的命令可能会引起Redis启动时的错误.例如,一个命令可能引用了一个不存在的键

为了更好地理解和解决加载AOF文件时的问题,可以查看Redis的日志文件.这通常会提供有关为什么Redis无法加载AOF文件的详细信息和错误消息.如果出现问题,你可以使用redis-check-aof工具来检查和修复AOF文件.

---

相对而言,RDB的快照是二进制文件,所以一般比AOF要小,所以在恢复数据时占优势,而且通过BGSAVE等方式生成快照时,Redis服务器会新创建一个子进程,所以不会影响Redis服务器继续执行命令.不过RDB持久化的缺陷之前也已经提到,即无法即时恢复数据

综合考虑到这两种方式的优缺点,在实际项目里可以同时用到这两种方式,当出现数据误删的情况时,可以用AOF持久化文件来恢复数据,在一般情况下,可以用RDB快照来恢复数据.一旦出现因AOF持久化文件损坏而无法恢复数据的情况,就可以用RDB的方式来恢复数据,最大限度地提升Redis内存数据的安全性

6.4.2 综合使用两种持久化方式

• step1. 编写配置文件

(base) root@yuanhong section6-4 % cat redis.conf
# 快照或AOF文件存储路径
dir /StudyRedisBaseOnDocker/conf/chpater6/section6-4

# 5秒内有1个或1个以上的键被修改时生成快照
save 5 1

# 300秒内有100个或100个以上的键被修改时生成快照
save 300 100

# 60秒内有1000个或1000个以上的键被修改时生成快照
save 60 1000

# 快照文件名
dbfilename my_dump.rdb

# 启用AOF持久化机制
appendonly yes

# 持久化频率为每秒持久化1次
appendfsync everysec

# 持久化文件名称
appendfilename my_appendonly.aof

• step2. 启动redis-server

(base) root@yuanhong section6-4 % redis-server /StudyRedisBaseOnDocker/conf/chpater6/section6-4/redis.conf

• step3. 写入一些键值对

(base) root@yuanhong ~ % redis-cli
127.0.0.1:6379> SET name Peter
OK
127.0.0.1:6379> SET age 18
OK

• step4. 查看配置文件指定的路径下的文件情况

(base) root@yuanhong section6-4 % ls
my_appendonly.aof	my_dump.rdb		redis.conf

可以看到,AOF文件和RDB文件同时存在

6.4.3 查看持久化状态的命令

• INFO persistence:查看持久化相关状态

127.0.0.1:6379> INFO persistence
# Persistence
loading:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1692090209
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:0
aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0
aof_current_size:87
aof_base_size:0
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0

其中:

• rdb_last_save_time:上次RDB持久化快照的生成时间

• aof_enabled:是否启用AOF持久化机制

• aof_last_write_status:上次AOF同步数据的操作是否成功

• aof_current_rewrite_time_sec:表示当前AOF重写操作(如果有的话)已经进行的秒数.如果没有AOF重写操作正在进行,该值为-1

• aof_last_rewrite_time_sec:上一次AOF重写操作所花费的总时间.单位:秒