Redis持久化

最新推荐文章于 2024-04-24 17:58:21 发布

唥雨凊

最新推荐文章于 2024-04-24 17:58:21 发布

阅读量64

点赞数

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

本文链接：https://blog.csdn.net/weixin_44777669/article/details/116520000

版权

14 篇文章 6 订阅

订阅专栏

RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。更适合做冷备。

优点：

缺点：

RDB是周期间隔性的快照文件，数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
备份时占用内存，因为Redis 在备份时会独立fork一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以要考虑到大概两倍的数据膨胀性。

两种触发方式

SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，导致无法提供服务。
BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，在保存完成后向主进程发送信号告知完成。在BGSAVE 执行期间仍可以继续处理客户端的请求。

目的是为了解决RDB后台备份时，保证快照是精准的

全称Copy On Write，备份的是开始那个时刻内存中的数据，只复制被修改内存页数据，不是全部内存数据。

缺点： Copy On Write时如果父子进程大量写操作会导致分页错误。

AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog。AOF更适合做热备。

优点： AOF是一秒一次去通过一个后台的线程fsync操作，数据丢失不用怕。

缺点：

命令的实时写入，不同级别可能有1秒数据损失。命令先追加到aof_buf然后再同步到AO磁盘，如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。
对aof文件的重写，目的是为了减少AOF文件的大小，可以自动触发或者手动触发(BGREWRITEAOF)，Fork出子进程操作，期间Redis服务仍可用。

流程图如下：

注意事项：

fork的建议：

降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写
控制Redis最大使用内存，防止fork耗时过长
合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败
Redis在执行BGSAVE和BGREWRITEAOF命令时，哈希表的负载因子>=5，而未执行这两个命令时>=1。目的是尽量减少写操作，避免不必要的内存写入操作
哈希表的扩展因子：哈希表已保存节点数量 / 哈希表大小。因子决定了是否扩展哈希表

启动时会先检查AOF(数据更完整)文件是否存在，如果不存在就尝试加载RDB。

既然单独用RDB会丢失很多数据。单独用AOF，数据恢复没RDB来的快，所以出现问题了第一时间用RDB恢复，然后AOF做数据补全。

后续在4.x进行了优化，进行混合使用

AOF记录一个当时的一个RDB快照和记录那个时刻后面的日志记录，结合两者的优点

恢复的时候就可以先根据那个时间的RDB文件快照先恢复，然后那个时间点后面的就用指令进行恢复，保证了完整性

关注