《redis开发与运维》持久化

最新推荐文章于 2022-07-05 21:18:08 发布

lxxxxxt

最新推荐文章于 2022-07-05 21:18:08 发布

阅读量446

点赞数

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

本文链接：https://blog.csdn.net/qq_36281031/article/details/122454582

版权

redis 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

系列文章目录

前言

redis是纯内存操作，将所有数据存放在内存中，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。

一、RDB

Redis DataBase，在执行的时间间隔内将当前进程数据生成快照保存到硬盘，可以手动和自动触发。

触发机制

手动触发

手动触发主要命令有save、bgsave、bgrewriteaof。

save: 阻塞当前Redis服务器，直到RDB操作完成，对于内存比较大的实例会造成长时间阻塞。
bgsave: Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束，阻塞只发生在fork阶段，一般时间很短，在微妙级。

info persistence，rdb_*查看Redis服务器RDB相关信息。

rdb_last_save_time	// 上次成功保存RDB的基于纪年的时间戳
rdb_last_bgsave_time_sec	// 上次RDB保存操作的持续时间（以秒为单位）
rdb_changes_since_last_save	  // 自上次转储以来的更改次数

bgsave 期间服务器拒绝执行save、bgsave、bgrewriteaof这三个命令，主要是防止线程间竞争产生问题。

子进程创建RDB文件（dump.rdb）是一个压缩的二进制文件，压缩后的文件远远小于内存中的大小，保存在dir配置指定的目录下，通过它可以恢复Redis内存中的数据。

config set dir {newDir}   // 修改保存路径
config set dbfilename {newName}   // 修改文件名
// 动态修改是否开启压缩, 压缩会消耗CPU，但大幅降低文件体积, 方便保存到硬盘或通过网络发送给从节点
config set rdbcompression{yes|no}

RDB文件结构：
TYPE：REDIS_RDB_TYPE_STRING/REDIS_RDB_TYPE_LIST/REDIS_RDB_TYPE_LIST_ZIPLIST/...
key_value_pairs举例：

自动触发

自动触发RDB持久化的场景大致有以下几种，配置文件redis.conf：

配置 save m n，例如 save 900 1，表示900（saveparam.seconds）秒内数据集出现1次（saveparam.changes）修改时，执行bgsave。
- 服务器维护dirty计数器，每进行一次写操作，计数器+1；lastsave属性记录上次save或bgsave的时间戳。
从节点执行全量复制操作，则主节点自动执行bgsave生成RDB文件发送给从节点。
执行debug reload重新加载redis时，自动触发save操作。
执行shutdown命令时，如果没有开启AOF，则自动执行bgsave。

恢复：是否启用AOF设置为no，将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可（CONFIG GET dir获取安装目录）。

优缺点

优点：

RDB文件，压缩的二进制文件，是redis某个时间点的数据快照，适用于备份、全量复制、拷贝到远程机器或文件系统中用于灾备。

加载RDB文件恢复数据，远快于AOF。

缺点：

无法实时持久化/秒级持久化，bgsave每次执行都要fork操作执行子进程，属于重量级操作，频繁执行成本过高。
RDB是特定二进制格式的文件，演进过程中有多个格式的RDB版本，存在老版本redis服务无法兼容新版RDB格式的问题。
最后一次持久化后的数据可能丢失。

二、AOF

Append Of File，以独立日志的方式记录每次写命令，重启时重新执行AOF文件中的命令以恢复数据。解决了数据持久化的实时性，是目前Redis持久化的主流方式。

开启AOF：

// 默认不开启, 默认文件名是appendonly.aof
appendonly yes

工作流程如下：

写入内容是文件协议格式，即RESP格式。

// set hello world
// 格式：
*参数数量
$参数1字节数
参数1
$参数2字节数
参数2
...
// 示例
*3
$3
SET
$5
hello
$5
world
// 实际格式
*3\r\n$3\r\nSET\r\n$5hello\r\n$5\r\n$5\r\nworld\r\n

先写入缓冲区然后再追加到硬盘：如果直接追加到硬盘，由于Redis是单线程，性能完全取决于硬盘负载，先写入缓冲区还可以提供多种同步到硬盘的策略，平衡性能和安全性。
AOF缓冲区根据对应的策略向硬盘AOF文件做同步操作。
- 通过参数appendfsync控制同步策略，取值有三种（always、everysec、no，建议使用everysec，也是默认配置）
```
# appendfsync always
appendfsync everysec
# appendfsync no
```

可配项	说明
always	命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync完成后线程返回
everysec	命令写入aof_buf后调用系统write操作，write完成后线程返回，fsync同步文件操作由专门线程每秒调用一次
no	命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，同步硬盘操作有操作系统负责，通常同步周期最长30s

这里涉及两个系统调用，write和fsync。
- write触发延迟写，写入系统缓冲区后返回，通过系统调度完成同步磁盘的操作。
- fsync强制磁盘同步，阻塞直到写入硬盘完成后返回。

随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
- 父进程fork出子进程，子进程创建新的AOF文件，不包含进程内已经超时的数据，以及旧的AOF文件中的del、hdel等无效命令，不是去读取和分析现有AOF文件的内容，而是将进程内的数据转化为写命令同步到新AOF文件中，这样新的AOF文件中只有最终数据的写入命令，并且可以将多条写命令合并为一个。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

> RPUSH list "A" "B"
(integer) 2
> RPUSH list "C"
(integer) 3
> RPUSH list "D" "E"
(integer) 5
> LPOP list
"A"
> LPOP list
"B"
> RPUSH list "F" "G"
(integer) 5

------ AOF重写后 -------
>RPUSH list "C" "D" "E" "F" "G"
// 重写程序会检查键所包含的元素的个数，如果元素的数量超过了redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值，那么重写程序会使用多条命令来记录键的值，而不是单使用一条命令

- 父进程依然响应其他命令，将新产生的数据保存在AOF重写缓冲区，新AOF文件写入完成后子进程发信号给父进程，父进程将重写缓冲区的数据写入到新AOF文件，然后原子替换旧的AOF文件。
- 因为fork子进程的操作是写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，所以Redis使用AOF重写缓冲区保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。

触发：

bgrewriteaof 命令手动触发

自动触发：

auto-aof-rewrite-min-size     // AOF重写时文件最小体积, 默认64MB
auto-aof-rewrite-percentage   // 代表 当前AOF文件空间/上次重写后AOF文件的空间的比值，默认100
// 自动触发时机
aof_current_size>auto-aof-rewrite-min-size && (aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage

当Redis服务器重启时，可以加载AOF文件进行数据恢复。
- AOF开启且有AOF文件时加载AOF，否则加载RDB文件。

AOF追加阻塞

从AOF缓冲区同步到硬盘通常使用everysec，这种方式会创建另外一个线程每秒执行fsync，同步到硬盘，当系统硬盘繁忙时，会造成redis主线程阻塞。有流程图可知，最多可能会丢失2秒数据。

AOF阻塞问题定位：

AOF阻塞时redis日志：

Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis

发生AOF阻塞时，info Persistence统计中aof_delayed_fsync指标会增加。

持久化性能分析

持久化是影响redis性能的高发地。

fork操作：创建的子进程会复制父进程的空间内存页表，例如10G的redis进程，大概需要复制20MB的内存页表，所以fork操作与进程总内存量息息相关。正常情况下fork每GB耗时20毫秒左右。

改善fork的耗时，可以通过控制redis实例最大可用内存；合理配置Linux内存分配策略，避免物理内存不足导致fork失败；降低fork频率，适当放宽AOF自动触发时机，避免不必要的全量复制等。

CPU开销：子进程负责AOF和RDB文件的重写，负责把进程内的数据分批写入文件，属于CPU密集型操作，redis是CPU密集型服务，不要和其他CPU密集型服务部署在一起，造成CPU过度竞争。如果部署多个redis实例，尽量保证同一时刻只有一个子进程执行重写工作。

内存消耗：Linux的fork采用写时复制copy-on-write，父子进程共享父进程的物理内存页，在父进程需要处理写请求时会把修改的页创建副本。所以尽量避免在大量写请求时做子进程的重写（父进程会维护大量页副本）。

COW：写时拷贝是一种可以推迟甚至免除拷贝数据的技术。创建子进程时内核并不复制整个进程地址空间，而是让父进程和子进程共享同一个拷贝。只有在需要写入的时候，数据才会被复制，从而使各个进程拥有各自的拷贝。也就是说，资源的复制只有在需要写入的时候才进行，在此之前，只是以只读方式共享。

硬盘：子进程主要职责是把AOF或者RDB文件写入硬盘持久化，势必造成硬盘写入压力。不要和其他高硬盘负载的服务部署在一起。如：存储服务、消息队列服务等。 AOF重写时会消耗大量硬盘IO，可以开启配置no-appendfsync-on-rewrite，默认关闭，表示在AOF重写期间不做fsync操作（在极端情况下可能丢失整个AOF 重写期间的数据，需要根据数据安全性决定是否配置）

总结

RDB使用一次性生成内存快照的方式，产生的文件紧凑压缩比更高，因此读取RDB恢复速度更快。由于每次生成RDB开销较大，无法做到实时持久化，一般用于数据冷备和复制传输。

AOF通过追加写命令到文件实现持久化，通过appendfsync参数可以控制实时/秒级持久化。因为需要不断追加写命令，所以AOF文件体积逐渐变大，需要定期执行重写操作来降低文件体积。

参考：《Redis开发与运维》《Redis设计与实现》

lxxxxxt

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
《redis开发与运维》持久化

系列文章目录前言一、RDB触发机制优缺点二、AOFAOF追加阻塞持久化性能分析总结前言redis是纯内存操作，将所有数据存放在内存中，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。一、RDBRedis DataBase，在执行的时间间隔内将当前进程数据生成快照保存到硬盘，可以手动和自动触发。触发机制手...
复制链接

扫一扫