《Redis开发与运维》----- 持久化

最新推荐文章于 2022-10-24 18:50:32 发布

jushisi

最新推荐文章于 2022-10-24 18:50:32 发布

阅读量149

点赞数

分类专栏： Redis

本文链接：https://blog.csdn.net/jushisi/article/details/108165269

版权

25 篇文章 0 订阅

订阅专栏

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。

一、RDB（Redis Data Base 数据快照）

手动触发：
save命令：阻塞当前Redis服务器，直到RDB过程完成。线上环境不建议使用。
bgsave（background save）命令：Redis进程执行fork操作创建子进程，RDB持久化由子进程负责。阻塞只发生在fork阶段，时间很短。
显然bgsave命令是针对save阻塞问题做的优化。因此Redis内部所有的涉及RDB的操作都采用bgsave的方式，而save命令已经废弃。
自动触发：
使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。
执行debug reload命令重新加载Redis时，也会自动触发save操作。
默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

在这里插入图片描述

RDB文件保存在dir配置指定的目录下，文件名字为dbfilename配置。可以通过命令动态修改 config set dir {newDir}；config set dbfilename {newFileName}
Redis采用默认的LZF算法对生成的RDB文件进行压缩，默认开启，虽然压缩过程会消耗cpu，但是可以大幅降低压缩后的文件体积，方便保存到磁盘和通过网络传输到从节点，线上建议开启
如果Redis加载损坏的RDB文件时拒绝启动，可以使用Redis提供的redis-check-dump工具检测RDB文件生成对应的错误报告

优点：
RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的快照。适用于备份、全量复制等场景。
Redis加载RDB恢复数据的速度远远快于AOF的方式
缺点：
RDB没有办法做到实时持久化
REB文件使用特定的二进制格式保存，存在老版本的服务器无法兼容新版RDB格式的问题

AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。
AOF默认是默认不开启的，开启AOF功能需要设置配置：appendonly yes。

在这里插入图片描述

AOF为什么直接采用文本协议格式？文本协议兼容性好
AOF为什么把命令追加到aof_buf（缓冲区）中？
1、如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。
2、缓冲区aof_buf中，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

AOF缓冲区同步文件策略，由参数appendfsync控制：

always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度,不建议配置
everysec  #每秒钟同步一次，默认配置
no        #让操作系统决定何时进行同步

AOF文件重写是把Redis进程内的数据转化为写命令同步到新- AOF文件的过程。重写后的AOF文件为什么可以变小？

AOF重写过程触发过程：
手动触发：直接调用bgrewriteaof命令。
自动解发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

AOF和RDB文件都可以用于服务器重启时的数据恢复。如果同时配了RDB和AOF，优先加载AOF。

关注