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

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

一、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工作过程

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提供了多种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流程如下：

三、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自动触发时机，避免不必要的全量复制等。