redis之RDB、AOF持久化及如何优化fork

发布于 2022-4-30 20:31
浏览
0收藏

作者 | 川石信息
来源 | 今日头条

一、RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程,触发RDB持久化过程分为手动触发和自动触发。

手动触发分别对应save和bgsave命令:

(1).save命令

save命令:阻塞当前Redis服务器,直到RDB过程完成为止,对于内存比较大的实例会造成长时间阻塞,线上环境不建议使用。运行save命令对应的Redis日志如下:

* DB saved on disk

(2).bgsave命令

bgsave命令:Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。运行bgsave命令对应的Redis日志如下:

* Background saving started by pid 3151 
* DB saved on disk 
* RDB: 0 MB of memory used by copy-on-write 
* Background saving terminated with success

RDB相关参数:

dbfilename dump.rdb 
设置本地数据库文件名,默认值为dump.rdb 
dir 
设置存储.rdb文件的路径
rdbcompression yes 
设置存储到本地的数据是否进行压缩数据,默认是yes,使用的压缩方式为LZF 
rdbchecksum yes 
设置是否进行RDB文件格式校验

RDB启动方式,sava配置

save second changes

RDB工作过程redis之RDB、AOF持久化及如何优化fork-开源基础软件社区

RDB的优点:

  • 1.RDB是一个紧凑压缩的二进制文件,代表Redis在某个时间点上的数据快照。非常适用于备份,全量复制等场景。比如每6小时执行bgsave备份,并把RDB文件拷贝到远程机器或者文件系统中(如hdfs),用于灾难恢复。
  • 2.Redis加载RDB恢复数据远远快于AOF的方式。

RDB的缺点:

  • 1.RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
  •  2.RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题。针对RDB不适合实时持久化的问题,Redis提供了AOF持久化方式来解决。

二、AOF

AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式。

开启AOF功能需要设置配置:appendonly yes,默认不开启。AOF文件名通过appendfilename配置设置,默认文件名是appendonly.aof。保存路径同RDB持久化方式一致,通过dir配置指定。

AOF的工作流程操作:命令写入(append)、文件同步(sync)、文件重写(rewrite)、重启加载(load)。redis之RDB、AOF持久化及如何优化fork-开源基础软件社区

Redis提供了多种AOF缓冲区同步文件策略,由参数appendfsync控制,appendfsync参数有以下几种设置方式。

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

随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。

重写后的AOF文件为什么可以变小?有如下原因:

→ 1)进程内已经超时的数据不再写入文件。

→ 2)旧的AOF文件含有无效命令,如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令。

→ 3)多条写命令可以合并为一个,如:lpush list a、lpush list b、lpush list c可以转化为:lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出,对于list、set、hash、zset等类型操作,以64个元素为界拆分为多条。

AOF重写过程可以手动触发和自动触发:

  • 手动触发:直接调用bgrewriteaof命令。
  • 自动触发:根据auto-aof-rewrite-min-size和

auto-aof-rewrite-percentage参数确定自动触发时机。

·auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积,默认为64MB。 
·auto-aof-rewrite-percentage:代表当前AOF文件空间(aof_current_size)和上一次重写后 AOF文件空间(aof_base_size)的比值。

bgrewriteaof流程如下:redis之RDB、AOF持久化及如何优化fork-开源基础软件社区

三、fork优化

当Redis做RDB或AOF重写时,一个必不可少的操作就是执行fork操作创建子进程,对于大多数操作系统来说fork是个重量级错误。虽然fork创建的子进程不需要拷贝父进程的物理内存空间,但是会复制父进程的空间内存页表。例如对于10GB的Redis进程,需要复制大约20MB的内存页表,因此fork操作耗时跟进程总内存量息息相关,如果使用虚拟化技术,特别是Xen虚拟 机,fork操作会更耗时。

fork耗时问题定位:对于高流量的Redis实例OPS可达5万以上,如果fork操作耗时在秒级别将拖慢Redis几万条命令执行,对线上应用延迟影响非常明显。正常情况下fork耗时应该是每GB消耗20毫秒左右。可以在info stats统计中查latest_fork_usec指标获取最近一次fork操作耗时,单位微秒。

如何改善fork操作的耗时:

◆ 1)优先使用物理机或者高效支持fork操作的虚拟化技术,避免使用Xen。

◆ 2)控制Redis实例最大可用内存,fork耗时跟内存量成正比,线上建议每个Redis实例内存控制在10GB以内。

◆ 3)合理配置Linux内存分配策略,避免物理内存不足导致fork失败 4)降低fork操作的频率,如适度放宽AOF自动触发时机,避免不必要的全量复制等。

标签
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐