redis持久化

RDB

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

触发机制

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

1. save命令
   阻塞当前redis服务器，直到RDB过程完成为止
2. bgsave命令
   redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
   自动化触发
   1）使用save相关配置，如“save m n”，表示m秒内数据集存在n次修改时，自动触发bgsave
   2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
   3）执行“debug reload”命令重新加载redis时，也会自动触发save操作
   4）默认情况下执行“shutdown”命令时，如果没有开启AOF持久化功能则自动执行bgsave

bgsave工作流程

1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进
程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通
过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
3）父进程fork完成后，bgsave命令返回“Background saving started”信息
并不再阻塞父进程，可以继续响应其他命令。
4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后
对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见
info Persistence下的rdb_*相关选项。

RDB文件的处理

保存
RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可通过执行 config set dir {new Dir} 和 config set dbfilename {new FileName}运行期动态执行
压缩
redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可通过“config set rdbcompression{yes|no}”动态修改
校验
如果redis加载损坏的RDB文件拒绝启动，并打印如下日志：
#Short read or OOM loading DB. Unrecoverable error, aborting now.
这时可以用redis提供的redis-check-dump工具监测RDB文件并获取对应的错误报告

RDB的优缺点

RDB的优点：

• RDB是一个紧凑压缩的二进制文件，代表redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。
• redis加载RDB恢复数据远远快于AOF的方式
  RDB的缺点
• RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高
• RDB使用特定二进制格式保存，redis版本演进过程中有多个格式的RDB版本，存在老版本redis服务无法兼容新版RDB格式的问题

AOF

AOF持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到回复数据的目的。AOF的主要作用是解决了数据持久化的实时性。

使用AOF

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

AOF工作流程

1）所有的写入命令会追加到aof_buf（缓冲区）中。
2）AOF缓冲区根据对应的策略向硬盘做同步操作。
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

命令写入
1）AOF命令写入的内容直接是文本格式
2）redis为什么把命令追加到aof_buf中？redis使用单线程响应命令，如果每次写入AOF命令直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲区还有一个好处，redis可以提供多种缓冲区同步硬盘的策略

命令同步

系统调用write和fsync说明：

• write操作会触发延迟写机制。Linux在内核提供页缓冲区用来提高硬盘IO性能。wirte操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制。例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• fync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化

重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，redis引入了AOF重写机制压缩文件体积。

重写后的AOF文件为什么可以变小？

• 进程内已经超时的数据不再写入文件
• 旧的进程内含有无效命令，重写使用进程内数据直接生成，这样的AOF文件只保留最终数据的写入命令
• 多条命令可以合并为一个，如:lpush list a,lpush list b,为了防止单条命令过大造成客户端缓冲区溢出，对于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）的比值
  • 自动触发时机=aof_current_size>auto-aof-rewrite-minsize&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage（其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看）

AOF重写运行流程

1）执行AOF重写请求，如果当前进程正在执行AOF重写，请求不执行并返回如下响应：
ERR Background append only file rewriting already in progress
如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行，返回如下响应：
Background append only file rewriting scheduled
2）父进程执行fork创建子进程，开销等同于bgsave过程
3）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写
入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性
由于fork操作运用写时复制技术，子进程只能共享fork操作时的内
存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部
分新数据，防止新AOF文件生成期间丢失这部分数据
4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每
次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为
32MB，防止单次刷盘数据过多造成硬盘阻塞
5）新的AOF文件写入完成后，子进程发送信号给父进程，父进程更新
统计信息，具体见info persistence下的aof_*相关统计
父进程把AOF重写缓冲区的数据写入到新的AOF文件
使用新AOF文件替换老文件，完成AOF重写

重启加载

文件校验
加载损坏的AOF文件时会拒绝启动，并打印如下日志：
#Bad file format reading the append only file: make a backup of your AOF file,then use ./redis-check-aof --fix
对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof–fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全

问题定位与优化

fork操作

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

如何改善fork操作的耗时
1）优先使用物理机或者高效支持fork的虚拟化技术
2）控制redis实例最大可用内存，fork耗时跟内存量成正比，线上建议每个redis实例内存控制在10GB以内
3）合理配置linux内存分配策略，避免物理内存不足导致fork失败
4）降低fork操作的频率，如适度放宽AOF自动触发时机，避免不必要的全量复制等

子进程开销监控和优化

1. cpu

• CPU开销分析。子进程负责把进程内的数据分批写入文件，这个过程属于CPU密集操作，通常子进程对单核CPU利用率接近90%
• CPU消耗优化。Redis是CPU密集型服务，不要做绑定单核CPU操作。由于子进程非常消耗CPU，会和父进程产生单核资源竞争不要和其他CPU密集型服务部署在一起，造成CPU过度竞争。如果部署多个Redis实例，尽量保证同一时刻只有一个子进程执行重写工作

2. 内存
   内存消耗分析。子进程通过fork操作产生，占用内存大小等同于父进
   程，理论上需要两倍的内存来完成持久化操作，但Linux有写时复制机制（copy-on-write）。父子进程会共享相同的物理内存页，当父进程处理写请求时会把要修改的页创建副本，而子进程在fork操作过程中共享整个父进程内存快照

内存消耗优化：
1）同CPU优化一样，如果部署多个redis实例，尽量保证同一时刻只有一个子进程在工作
2）避免在大量写入时做子进程重写操作，这样将导致父进程维护大量页副本，造成内存消耗

硬盘开销分析：
子进程主要职责是吧AOF或RGB文件写入硬盘持久化，势必造成硬盘写入压力。根据redis重写AOF/RDB的数据，结合系统工具，如sar,iosar,iotop等，可分析出重写期间磁盘负载情况

硬盘开销优化：
1）不要和其他高硬盘负载的服务部署在一起。
2）AOF重写时会消耗大量硬盘IO，可以开启配置no-appendfsync-on-rewrite，默认关闭。表示在AOF重写期间不做fsync操作
3）当开启AOF功能的Redis用于高流量写入场景时，如果使用普通机械磁盘，写入吞吐一般在100MB/s左右，这时Redis实例的瓶颈主要在AOF同步硬盘上。
4）对于单机配置多个Redis实例的情况，可以配置不同实例分盘存储AOF文件，分摊硬盘写入压力。

AOF追加阻塞

当开启AOF持久化时，常用的同步硬盘的策略是everysec，用于平衡性能和数据安全性。对于这种方式，Redis使用另一条线程每秒执行fsync同步硬盘。当系统硬盘资源繁忙时，会造成Redis主线程阻塞

阻塞流程分析：
1）主线程负责写入AOF缓冲区
2）AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间
3）主线程负责对比上次AOF同步时间
如果距上次同步成功时间在2秒内，主线程直接返回。
如果距上次同步成功时间超过2秒，主线程将会阻塞，直到同步操作完成