Redis持久化

最新推荐文章于 2024-09-14 17:41:44 发布

theONLY0318

最新推荐文章于 2024-09-14 17:41:44 发布

阅读量203

点赞数

分类专栏： NoSQL 文章标签： redis

本文链接：https://blog.csdn.net/sinat_35400668/article/details/115357454

版权

NoSQL 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

文章目录

1. 介绍
2. RDB
3. AOF
4. RDB-AOF混合持久化方式（推荐）

1. 介绍

什么是持久化？
将数据从掉电易失的内存存放到能够永久存储的设备上

Redis为什么需要持久化？

基于内存的
缓存服务器，需要吗？
内存数据库，需要吗？
消息队列，需要吗？

Redis持久化方式

RDB（Redis DB）
hdfs: fsimage
AOF（AppendOnlyFile）
hdfs : edit logs 关闭的

2. RDB

RDB是Redis的默认持久化方式，不需要配置
redis.conf配置文件：

SAVE m n ：在m秒内，如果至少有n个数据写入（key发生变化），就持久化
stop-writes-on-bgsave-error yes：当备份进程出错的时候，主进程就停止接受新的写入操作
rdbcompression yes：在备份的时候需要将RDB文件进行压缩后才去做保存（建议为no）
save ""：禁用RDB配置

在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中

产生一个RDB方式：

阻塞方式：
客户端中执行save命令
非阻塞方式：（复杂度高？）
bgsave

策略

自动
- 按照配置文件中的条件满足就执行BGSAVE
  save 60 1000：要满足在60秒内至少有1000个键被改动，自动保存一次
- 主从复制时，主节点自动触发
- 执行Debug Reload
- 执行Shutdown 且没有开启AOF持久化
手动
客户端发起SAVE、BGSAVE命令
- SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕
- BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程
  lastsave 指令可以查看最近的备份时间

SAVE命令
阻塞Redis服务，无法响应客户端请求
创建新的dump.rdb替代旧文件

BGSAVE命令
非阻塞，Redis服务正常接收处理客户端请求
Redis会fork()一个新的子进程来创建RDB文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕
父进程用新的dump.rdb替代旧文件

BGSAVE是一个异步命令

SAVE 和 BGSAVE 命令

SAVE不用创建新的进程，速度略快
BGSAVE需要创建子进程，消耗额外的内存
SAVE适合停机维护，服务低谷时段
BGSAVE适合线上执行

优点

完全备份，不同时间的数据集备份可以做到多版本恢复
紧凑的单一文件，方便网络传输，适合灾难恢复
恢复大数据集速度较AOF快

缺点

会丢失最近写入、修改的而未能持久化的数据
fork过程非常耗时，会造成毫秒级不能响应客户端请求

生产环境

创建一个定时任务cron job，每小时或者每天将dump.rdb复制到指定目录。确保备份文件名称带有日期时间信息，便于管理和还原对应的时间点的快照版本，定时任务删除过期的备份。如果有必要，跨物理主机、跨机架、异地备份。

3. AOF

Append only file，采用追加的方式保存

默认文件appendonly.aof

记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库

调整AOF持久化策略，可以在服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于RDB损失小得多

3.1 AOF写入机制

AOF方式不能保证绝对不丢失数据

目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

3.2 写入磁盘的策略

appendfsync选项，这个选项的值可以是always、everysec或者no

always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
everysec（默认）：服务器每一秒调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
no：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的

运行速度：always的速度慢，everysec和no都很快

3.3 AOF重写

写时复制
redis不仅可以将命令转换为数据，还可以将数据转换为命令

在这里插入图片描述

AOF重写机制

AOF文件过大
合并重复的操作，AOF会使用尽可能少的命令来记录
重写基于写时复制，直接将内存的数据反转为命令。

重写过程

执行AOF重写请求
父进程执行fork创建子进程，开销等同于bgsave过程
1. 主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区，并根据appendfsync策略同步到磁盘，保证原有AOF机制正确性。
2. 由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
子进程根据内存快照，按照命令合并规则写入到新AOF文件。每次批量写入硬盘数据量由aof-rewrite-incremental-fsync控制，默认是32MB，防止单次刷盘数据过多造成硬盘阻塞。
1. (比如8:00)新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
2. 父进程把AOF重写缓冲区数据写入到新的AOF文件。
3. 使用新AOF文件替换老文件，完成AOF重写。

注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

AOF重写触发

手动：客户端向服务器发送BGREWRITEAOF命令
自动：配置文件中的选项，自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size <size>，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写死循环
auto-aof-rewrite-percentage <percent>，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写

AOF重写配置项举例

# 默认关闭若要开启将no改为yes
appendonly no
# append文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# always一旦缓存区内容发生变化就写入AOF文件中
appendfsync always
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 将写入文件的操作交由操作系统决定
appendfsync no
# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。
auto-aof-rewrite-percentage 100
# 当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb

当AOF文件大于64MB时候，可以考虑重写AOF文件

只有当AOF文件的增量大于起始size的100%时（就是文件大小翻了一倍），启动重写

AOF优点