【八】、Redis持久化RDB和AOF

最新推荐文章于 2023-07-03 13:12:50 发布

艾卡西亚丶暴雨L

最新推荐文章于 2023-07-03 13:12:50 发布

阅读量463

点赞数

分类专栏： Redis 文章标签： redis 缓存数据库

本文链接：https://blog.csdn.net/qq_45291280/article/details/122534102

版权

Redis 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

八、Redis持久化RDB和AOF

面试和工作，持久化都是重点！

Redis是内存数据库，如果不能将内存数据库中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会小时，所以Redis提供了持久化功能(即数据恢复功能)!

1.RDB(Redis DataBase)

什么是RDB

什么是RDB
在指定的时间间隔内将内存中的数据集快照写入到磁盘当中，Snapshot快照，恢复时将快照文件直接读到内存当中
默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中，文件名可以在配置文件中进行自定义。

工作原理：

单独创建一个子进程(fork)，同时拥有子进程和父进程
将内存内容写入临时的RDB文件
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

整个过程主进程不进行任何的io操作，保证了性能，如果大规模数据恢复，RDB和AOF都可以进行数据恢复，RDB数据恢复完整性不敏感，RDB更加高效，缺点是最后一次持久化后的数据可能会丢失，默认使用RDB，一般情况不需要修改这个配置。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。)

RDB保存的文件是dump.rdb 都是在我们的配置文件的快照中进行配置的
rdb保存的文件名
触发机制：

save的规则满足的情况下，会自动触发rdb规则
执行flushall命令，也会触发我们的rdb规则
正常退出redis，也会产生rdb文件

如何恢复rdb文件

只需要将rdb文件放在我们redis的启动目录就可以，redis启动的时候会自动检查dump.rdb并且恢复其中的数据
查看需要rdb文件需要存放的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" #如果在这个目录下存在 dump.rdb，启动就会自动恢复其中的数据

save

使用 save 命令，会立刻对当前内存中的数据进行持久化 ,但是会阻塞，也就是不接受其他操作了

由于 save 命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。

flushall命令
flushall命令也会触发持久化

触发持久化规则
满足配置条件中的触发条件

可以通过配置文件对Redis进行设置，让它在"N秒内数据及至少有M个改动"这一条件被满足时，自动进行数据集保存操作。

bgsave

bgsave 是异步进行，进行持久化的时候，redis 还可以将继续响应客户端请求

bgsave和save的对比

命令	save	bgsave
IO类型	同步	异步
是否阻塞	是	否
复杂度	O(n)	O(n)
优点	不会消耗额外的内存	不会阻塞客户端命令
缺点	阻塞客户端命令	需要fock子进程，消耗内存

优缺点：

RDB的优点

适合大规模的数据恢复
对数据的完整性要求不高

RDB的缺点

需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次修改的数据就没有了。
fork进程的时候，会占用一定的内容空间。

2.AOF（Append Only File）

恢复机制:将我们所有的命令都记录下来，history，恢复的时候就把这个文件全部再执行一遍

以日志的形式来记录每个写的操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

什么是AOF

快照功能（RDB）并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、以及未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。
AOF
如果要使用AOF，则需要修改配置文件：
开启aof

appendonly no默认是不开启aof的，使用rdb方式持久化，将no改成yes则表示启用AOF
我们手动配置yes启动AOF之后，重启redis，就可以生效。
如果这个时候AOF文件有错误，redis是启动不起来的，我们需要修改这个aof文件。
redis给我们提供了一个工具redis-check-aof --fix

优点和缺点：

appendonly no #默认不开启aof模式，默认是使用rdb方式持久化的，在大部分情况下rdb完全够用了！
appendfilename "appendonly.aof" #持久化的文件的名字

# appendfsync always 	#每次修改都会写入 sync，消耗性能
appendfsync everysec	#每秒执行一次sync,可能会丢失1s的数据
# appendfsync no		#不执行 sync，这个时候操作系统自己同步数据，速度最快

#rewrite 重写

优点：

每一次修改都会同步文件，文件的完整性会更加好
每秒同步一次，所以仅会丢失一秒的数据
从不同步，效率最高，因为这时候操作系统会自己同步数据

缺点：

相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢
AOF运行效率也比RDB要慢，所以redis默认的配置就是rdb持久化

3.RDB和AOP选择

RDB和AOF对比

功能	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	会丢失数据	根据策略决定

如何选用哪些持久化方式？

一般来说，如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能。
如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化，但并不推荐这种方式：因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

参考文献：https://blog.csdn.net/DDDDeng_/article/details/108118544?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1.no_search_link&utm_relevant_index=2