Redis 持久化

叶佳欣

关注

发布于: 2021 年 04 月 25 日

[TOC]

两种持久化方式

RDB(Redis DataBase)

在不同的时间点，将 redis 存储的数据生成快照并存储到磁盘等介质上；

####优点

RDB 是一种快照式的持久化方法，redis 会单独 fork 一个子进程，主进程不用进行任何 IO 操作，这样 Redis 具有极高的进行。
持久化过程中，数据会写到临时文件，待持久化过程结束，才会用临时文件替换上次持久化好的文件，这样保证了数据的完整性。
进行大规模的数据恢复，RDB 比 AOF 方式更加高效 ####缺点
对持久化数据的完整性保证不高，在 RDB 模式下，即使 5 分钟持久化一次，当 redis 故障时，仍然可能会有 5 分钟的数据丢失。

AOF(Append Only File)

将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

优点

充分保证数据的持久化，正确的配置一般最多丢失 1 秒的数据
aof 文件内容是以 Redis 协议格式保存，易读

缺点

同样数据规模的情况下，AOF 文件要比 RDB 文件的体积大
AOF 方式的恢复速度也要慢于 RDB 方式
重新启动 redis 时会极低的概率会导致无法将数据集恢复成保存时的原样(日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满，写入中途停机，等等), redis-check-aof 工具也可以轻易地修复这种问题)

相关配置

############################## APPEND ONLY MODE ################################默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。appendonly yes
#aof文件名, 保存目录由 dir 参数决定appendfilename "appendonly.aof"
#aof持久化策略的配置#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。#always表示每次写入都执行fsync，以保证数据同步到磁盘。#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。appendfsync everysec
# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。no-appendfsync-on-rewrite no
#aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。auto-aof-rewrite-percentage 100#设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写auto-aof-rewrite-min-size 64mb
#aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。aof-load-truncated yes

复制代码

AOF 重写

#####原理

因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，redis 提供了 AOF 文件重写（rewrite）机制，即当 AOF 文件的大小超过所设定的阈值时，redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。
例如我们调用了 100 次 INCR 指令，在 AOF 文件中就要存储 100 条指令，但这明显是很低效的，完全可以把这 100 条指令合并成一条 SET 指令，这就是重写机制的原理。

操作

自动重新详见 aof 配置
命令执行: BGREWRITEAOF

详细过程

在重写即将开始之际，redis 会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中。
当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中了。

参考文档

官方文档

redi持久化方式，以及aof文件过大怎么处理

Redis 持久化详解及配置

发布于: 2021 年 04 月 25 日阅读数: 12

叶佳欣

关注

还未添加个人签名 2018.01.18 加入

还未添加个人简介

发布

暂无评论

创作场景

Redis 持久化

两种持久化方式

RDB(Redis DataBase)

相关配置

AOF(Append Only File)

优点

缺点

相关配置

AOF 重写

操作

详细过程

参考文档

叶佳欣

评论