Redis 持久化

最新推荐文章于 2025-05-28 16:17:51 发布

liujiangbo1

最新推荐文章于 2025-05-28 16:17:51 发布

阅读量299

点赞数

分类专栏： Redis 文章标签： redis c#

本文链接：https://blog.csdn.net/SXML123456/article/details/106653552

版权

Redis 专栏收录该内容

10 篇文章

订阅专栏

持久化方式

RDB

简介

将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

命令

save
说明：手动执行，save指令的执行会阻塞当前redis服务器，直到当前rdb过程完成为止，有可能造成长时间的阻塞，线上环境不建议使用

bgsave
说明：手动执行，redis另起进程执行rdb操作，不会阻塞redis服务器，当rdb操作执行完成后，会写结果到控制台或日志文件，bgsave是针对save阻塞问题做的优化，redis内部所有涉及到的rdb操作都采用bgsave的方式，save命令可放弃使用

save second changes
说明：自动执行，这个指令背后执行的是bgsave操作，通过
，我们可设定在second时间内当有changes个key更改的时候执行bgsave操作

介质

默认保存为dump.rdb文件（文件名称可配置）

save指令相关配置

dbfilename dump.rdb
说明：设置本地数据库文件名，默认为dump.rdb，通常设置为dump-端口号.rdb

dir 
说明：设置存储.rdb文件的路径，通常设置在存储空间较大的目录中，文件夹的名称为Data

rdbconpression key
说明：设置存储至本地数据库时是否压缩数据，默认为yes，采用LZF压缩，通常为开启状态，如果修改为no，可以节省cou运行时间，但是保存的数据文件会较大

rdbchecksum yes
说明：设置是否进行rdb文件格式校验，该校验过程在读写文件过程均进行，通常为开启状态，如果修改为no，可节约时间，但生成的数据文件有失败的风险

bgsave指令相关配置

stop-writes-on-bgsave-error yes
说明：后台存储过程中，如果配出异常，是否终止保存操作，通常为开启状态

使用RDB进行数据恢复

重启redis服务器即可

RDB持久化优缺点

优点

RDB是一个紧凑压缩的二进制文件，存储效率较高
RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
RDB恢复数据的速度比AOF快
应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

缺点

RDB方式无论是执行命令还是利用配置，都无法做到实时持久化，具有较大的可能性丢失数据
bgsave命令每次运行要执行fork操作来创建子进程，要牺牲掉一些性能
redis的众多版本中未进行rdb文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容的现象（可解决）

AOF

简介

将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。
以独立日志的方式记录每次写命令，重启redis服务器时，再重新执行AOF文件中的命令以达到恢复数据的目的，与RDB相比可以简单描述为改记录数据为记录数据产生的过程。
AOF主要是为了解决数据持久化的实时性，目前已经是redis持久化的主要方式。

AOF写数据的过程

执行一条写的命令后，先将命令写到缓存区，最后将命令同步到AOF文件中。

AOF写数据的三种策略

always
每次写数据均同步到AOF文件中，可以做到数据零误差，性能较低
everysec
每秒将缓存区中的指令同步到AOF文件中，数据准确性较高，性能较高，在系统突然宕机的情况下可能丢失1秒的数据
no
由操作系统控制每次将命令同步到AOF文件中的周期，整体过程不可控

AOF功能开启

配置

appendonly yes/no（是否开启AOF持久化功能，默认不开启）
appendfsync always/everysec/no（AOF写数据的策略）
appendfilename filename（AOF持久化数据文件名，默认吗文件名为appendonly.aof，建议配置为appendonly-端口号.aof）
dir （AOF持久化文件的保存路径，与RDB持久化文件保持一致即可）