redis持久化方式之AOF和RDB小记

最新推荐文章于 2023-12-13 08:34:50 发布

Roc Bird

最新推荐文章于 2023-12-13 08:34:50 发布

阅读量208

点赞数 4

分类专栏： notes

本文链接：https://blog.csdn.net/qq_36581986/article/details/90905232

版权

notes 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

redis持久化方式之AOF和RDB小记

说明
- 之前了解redis的持久化方式,redis持久化主要是为了保存数据,当redis宕机后,这些数据能够恢复,所以趁此机会整理整理.把自己的理解分享出去.
RDB
- RDB持久化是在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程就是fork一个子进程,将数据集写入文件,用二进制压缩存储,再将之前的文件替换的过程.
- 在指定时间间隔内,执行指定次数的写操作,则会将内存中数据写入磁盘中,即在指定目录下生成一个dump.rdb文件,redis重启会从dump.rdb中恢复数据.
- 在redis.conf中的SNAPSHOTTING专栏中
```
#   save ""

save 900 1                 
save 300 10               
save 60 10000
```
  save <指定时间间隔><指定执行次数>
  - 官方默认: 900秒中有一个更改,300秒钟有10个更改,60秒中有10000个更改,则将内存中数据快照写入磁盘.
  - 官方默认使用的是RDB持久化,如果不想使用这种方式,可以# save ""打开即可.
- 在redis.conf中指定文件名字
  dbfilename dump.rdb
- 在redis.conf中指定本地数据存放的位置,
- 默认开启数据压缩,配置存储数据库是否压缩数据,默认为yes,redis采用LZF压缩方式,但是占用了CPU的一点时间,如果选择关闭,会导致数据库文件变得巨大.
  rdbcompression yes
- 触发redis快照写入磁盘的时机
  - 在指定时间间隔中,执行指定的写操作次数;
  - 执行save(阻塞,直管保存快照,其他的阻塞)或者是bgsave(异步)命令;
  - 执行flushall命令,清空所有数据;
  - 执行shutdown命令,关闭redis服务器.
- RDB恢复数据
  - 将dump.rdb文件放在redis的bin目录下,重启即可.
- RDB方式保存的是数据集快照,打开dump.rdb,没错,是乱码,说明保存的是数据,如下:
```
 REDIS0008?	redis-ver4.0.10?
 redis-bits?@?ctime½y?\used-mem????
 aof-preamble???ssssaaaa?NB??J??
```
AOF
- AOF持久化是以日志的形式记录服务器处理每一个写操作、删除操作,以文本的方式记录下来,打开可以看到详细的操作日志.
- redis默认不开启这种持久化方式,它的出现主要是弥补RDB的不足(数据的不一致性),redis重启会根据日志文件内容,将操作指令从前到后完整执行一遍,完成数据的恢复工作.
- 打开redis.conf,找到APPEND ONLY MODE专栏,将以下属性设置为yes,表示开启AOF,默认为no(关闭).
```
  appendonly yes	
```
- 同时执行以下命令,保证AOF文件的生成
```
  redis-cli config set appendonly yes
  redis-cli config set save ""
```
- 指定本地数据库名
```
  appendfilename "appendonly.aof"
```
- 指定更新日志条件
```
  # appendfsync always
    appendfsync everysec
  # appendfsync no	
```
  always:同步持久化,表示一发生数据变化就立刻写入到磁盘中,性能比较差但是完成性比较好;
  everysec : 官方默认,表示每秒异步写入磁盘一次.
- 配置重写触发机制
```
 auto-aof-rewrite-percentage 100
 auto-aof-rewrite-min-size 64mb
```
  当AOF文件大小是上次重写后文件大小的一倍,且文件大小大于64M时触发,其中这里的一倍和64M通过配置文件参数配置.
  AOF的工作原理是将写操作追加到文件中,所以appendonly.aof中冗余内容会比较多.所以redis提供了重写机制,当AOF文件超过所设定的阈值时,就会把redis的AOF文件进行压缩;
- 重写机制原理:
  - redis会fork一个新进程,读取内存中的数据,然后将操作日志保存在临时文件中,最后临时文件将替换旧的操作日志文件.即:AOF文件.
- AOF恢复数据
  - 将操作日志文件放在redis的bin目录下,重启redis即可,如果因为其他原因导致appendonly.aof格式异常,可以使用命令尝试修复.
```
	redis-check-aof --fix appendonly.aof
```
- AOF文件,可以看出它保存的是一些操作命令
```
SET
$2
t2
$2
t3
```
RDB和AOF优缺点
- RDB优势
  - 与AOF对比来说,如果数据量比较大,使用RDB,redis的启动效率会比较高;
  - 如果业务对数据的完整性和一致性要求不是很高,RDB是优选.
  - 性能最大化,RDB是fork一个子进程,由子进程进行持久化工作,这就避免了服务进程的执行IO操作.
- RDB不足
  - 数据的完整性和一致性不是很高,可能在准备备份的的过程中宕机了,导致没有持久化完整的数据;
  - 如果是大数据集,那么备份时,导致内存占用比较多,所以redis在备份时,应选择使用redis写操作频率低的时间段内进行处久化.
- AOF优势
  - 数据的完整型和一致性相对RDB比较好;
  - 可以提供一份比较好的操作日志.
- AOF不足
  - AOF记录的内容比较多,文件会越来越大,恢复数据会比较慢.
- 选择标准
  - 愿意牺牲一些性能 ,换取缓存的高一致性;
  - 还是牺牲高一致性,换取更高的性能.
- reference
  - 参考1