Redis持久化

  • 持久化(Persistence),即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。持久化的主要应用是将内存中的对象存储在数据库中,或者存储在磁盘文件中、XML数据文件中等等。
    • 还可以从如下两个层面简单的理解持久化:
      • 应用层:如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。
      • 系统层:如果关闭(shutdown)你的系统(电脑)然后重新启动则先前的数据依然存在。

Redis为什么要持久化

Redis是内存数据库,为了保证效率所有的操作都是在内存中完成。数据都是缓存在内存中,当你重启系统或者关闭系统,之前缓存在内存中的数据都会丢失再也不能找回。因此为了避免这种情况,Redis需要实现持久化将内存中的数据存储起来。

Redis如何实现持久化？

Redis官方提供了不同级别的持久化方式:

  • RDB持久化:能够在指定的时间间隔能对你的数据进行快照存储。
  • AOF持久化:记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
  • 不使用持久化:如果你只希望你的数据在服务器运行的时候存在,你也可以选择不使用任何持久化方式。
  • 同时开启RDB和AOF:你也可以同时开启两种持久化方式,在这种情况下当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB(Redis DataBase)快照

  • RDB持久化是把当前进程数据生成快照保存到硬盘的过程,触发RDB持久化过程分为手动触发和自动触发.
  • Redis的数据都在内存中,为了提供所有数据的可靠性保证,它执行的是全量快照;

RDB触发方式

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

    • save命令: 阻塞当前Redis服务器,直到RDB过程完成为止,对于内存比较大的实例会造成长时间阻塞[废弃].

    • bgsave命令:Redis进程执行fork操作创建子进程,RDB持久化过程有子进程负责,完成后自动结束.阻塞只发生在fork阶段,一般时间很短.

      img

      • Redis借助操作系统提供的写时复制技术(Copy-On-Wirte,COW),在执行快照的同时,正常处理写操作.

        • bgsave子进程是由主线程fork生成的,可以共享主线程的所有内存数据.bgsave子进程运行后,开始读取主线程的内存的数据,并把它们写入RDB文件.
        • 如果主线程对这些数据也是读操作,那么主线程和bgsave子进程互不影响(共享内存空间),但是,如果主线程要修改一块数据,那么,这块数据就会被复制一份,生成该数据的副本.然后bgsave子进程就会把这个副本数据写入RDB文件,而在这个过程中,主线程任然可以直接修改原来的数据.

        img

      • 虽然bgsave执行时不阻塞主线程,但是,如果频繁地执行全量快照,也会带来两方面的开销。

        • 一方面,频繁将全量数据写入磁盘,会给磁盘带来很大压力,多个快照竞争有限的磁盘带宽,前一个快照还没有做完,后一个又开始做了,容易造成恶性循环。
        • 另一方面,bgsave子进程需要通过fork操作从主线程创建出来。虽然,子进程在创建后不会再阻塞主线程,但是,fork这个创建过程本身会阻塞主线程,而且主线程的内存越大,阻塞时间越长。如果频繁fork出bgsave子进程,这就会频繁阻塞主线程了;
        • 可以做增量快照,所谓增量快照,就是指,做了一次全量快照后,后续的快照只对修改的数据进行快照记录,这样可以避免每次全量快照的开销。

        img

        img

      • Redis 4.0中提出了一个混合使用AOF日志和内存快照的方法。简单来说,内存快照以一定的频率执行,在两次快照之间,使用AOF日志记录这期间的所有命令操作。

        • 这样一来,快照不用很频繁地执行,这就避免了频繁fork对主线程的影响。而且,AOF日志也只用记录两次快照间的操作,也就是说,不需要记录所有操作了,因此,就不会出现文件过大的情况了,也可以避免重写开销。

        img

  • 除了执行命令手动触发外,Redis内部还存在自动触发的RDB的持久化机制:

    • 使用save相关配置,如save m n,表示m秒内数据集存在n次修改时,自动触发bgsave;
    • 若从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点;
    • 执行debug reload命令重新加载Redis,也会自动触发bgsave操作;
    • 默认情况下执行shutdown命令,若没有开启AOF持久化则自动执行bgsave;

  • **bgsave是主流的触发RDB持久化方式 **

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

RDB文件的处理

保存
  • RDB文件保存在dir配置指定的目录下,文件名通过dbfilename配置指定.可以通过执行config set dir {newDir}和config set dbfilename {newFileName}运行期动态执行,当下次运行是RDB文件会保存到新的目录中
  • 当遇到坏盘或磁盘写满等情况,可以通过config set dir {newDir}在线修改文件路径到可用磁盘路径,之后执行bgsave进行磁盘切换,同样试用于AOF持久化文件.
压缩
  • Redis默认采用LZF算法对生成的RDB文件做压缩处理,压缩后的文件远远小于内存大小,默认开启,可以通过参数config set rdbcompression {yes|no}动态修改.
  • 虽然压缩RDB会消耗CPU,但可大幅降低文件的体积,方便保存到硬盘或者通过网络发送给从节点,因此线上建议开启.
校验

  • 如果Redis加载损坏的RDB文件时拒绝启动,并打印如下日志:

    1
    # Short read or OOM loading DB. Unrecoverable error,aborting now

  • 这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告.

RDB的优缺点

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

  • RDB方式数据没办法做到实时持久化/秒级持久化

    • 因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高(fork子进程,压缩,写出RDB文件都比较耗时).

  • RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题

AOF(Append Only File)日志

  • 数据库的写前志(Write Ahead Log,WAL),也就是说,在实际写数据前,先把修改的数据记到日志文件中,以便故障时进行恢复。
  • 不过,AOF日志正好相反,它是写后日志,“写后”的意思是Redis是先执行命令,把数据写入内存,然后才记录日志.AOF里记录的是Redis收到的每一条命令,这些命令是以文本形式保存的。
    • 但是,为了避免额外的检查开销,Redis在向AOF里面记录日志的时候,并不会先去对这些命令进行语法检查。所以,如果先记日志再执行命令的话,日志中就有可能记录了错误的命令,Redis在使用日志恢复数据时,就可能会出错。
    • 而写后日志这种方式,就是**先让系统执行命令,只有命令能执行成功,才会被记录到日志中,否则,系统就会直接向客户端报错。**所以,Redis使用写后日志这一方式的一大好处是,可以避免出现记录错误命令的情况。
    • 除此之外,AOF还有一个好处:它是在命令执行后才记录日志,所以不会阻塞当前的写操作。

AOF持久化:以独立日志的方式记录每次命令,重启时再重新执行AOF文件中命令达到恢复数据的目的.

AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式.

  • 开启AOF功能需要设置配置:appendonly yes,默认不开启.

  • AOF文件名通过appendfilename配置设置,默认文件名是appendonly.aof.保存路径同RDB持久化方式一致,通过dir配置指定.

  • AOF的工作流程操作: 命令写入(append)、文件同步(sync)、文件重写(rewrite)、重启加载(load)

命令写入(append)

  • 所有的写入命令会追加到aof_buf(缓冲区)中;

    • AOF命令写入的内容是文本协议格式,目的如下:
      • 文本协议具有很好的兼容性;
      • 开启AOF后,所有写入命令都包含追加操作,直接采用协议格式,避免了二次处理开销;
      • 文本协议具有可读性,方便直接修改和处理.
    • AOF把命令追加到aof_buf中,是因为Redis使用单线程响应命令,如果每次写AOF文件命令都直接追加到硬盘,那么性能完全取决于当前硬盘负载.先写入缓冲区aof_buf中,还有另一个好处,Redis可以提供多种缓冲区同步硬盘的策略,在性能和安全性方面做出平衡.

文件同步(sync)

  • AOF缓冲区根据对应的策略向硬盘做同步操作;

  • Redis提供多种AOF缓冲区同步文件策略,有参数appendfsync控制

    可配置值 说明 配置分析
    always 命令写入aof_buf后调用系统fsync操作同步写回到AOF文件,fsync完成后线程返回
    立马同步地将日志写回磁盘    		 同步写回可以做到基本不丢数据,但是它在每一个写命令后都有一个慢速的落盘操作,不可避免地会影响主线程性能；
    everysec 命令写入aof_buf后调用系统write操作,write完成后线程返回,fsync同步操作由专门线程每秒调用一次
    每秒写回    		 每秒写回采用一秒写回一次的频率,避免了“同步写回”的性能开销,虽然减少了对系统性能的影响,但是如果发生宕机,上一秒内未落盘的命令操作仍然会丢失。所以,这只能算是,在避免影响主线程性能和避免数据丢失两者间取了个折中。
    no 命令写入aof_buf后调用系统write操作,不对AOF文件做fsync同步,同步硬盘操作由操作系统负责,通常同步周期最长为30秒
    操作系统控制的写回    		 虽然操作系统控制的写回在写完缓冲区后,就可以继续执行后续的命令,但是落盘的时机已经不在Redis手中了,只要AOF记录没有写回磁盘,一旦宕机对应的数据就丢失了；

    img

    • 写回策略的选择

      • 想要获得高性能,就选择No策略；
      • 如果想要得到高可靠性保证,就选择Always策略；
      • 如果允许数据有一点丢失,又希望性能别受太大影响的话,那么就选择Everysec策略。

    • 系统调用write和fsync说明:

      • write操作会触发延迟写(delayed write)机制.Linux在内核提供页缓冲区用来提高硬盘IO性能.write操作在写入系统缓冲区后直接返回.同步硬盘操作依赖于系统调用度机制,例如:缓冲区也空间写满或达到特定时间周期.同步文件之前,如果此时系统故障宕机,缓冲区内数据将丢失.

      • fsync针对单个文件操作(比如AOF文件),做强制硬盘同步,fsync将阻塞知道写入硬盘完成后返回,保证了数据持久化.

文件重写(rewrite)

  • AOF是以文件的形式在记录接收到的所有写命令。随着接收的写命令越来越多,AOF文件会越来越大。这也就意味着,我们一定要小心AOF文件过大带来的性能问题。这里的“性能问题”,主要在于以下三个方面

    • 一是文件系统本身对文件大小有限制,无法保存过大的文件；
    • 二是如果文件太大,之后再往里面追加命令记录的话,效率也会变低；
    • 三是如果发生宕机,AOF中记录的命令要一个个被重新执行,用于故障恢复,如果日志文件太大,整个恢复过程就会非常缓慢,这就会影响到Redis的正常使用。
    • 从而引出了AOF重写机制

  • 为什么重写机制可以把日志文件变小呢?

    • 实际上,重写机制具有“多变一”功能。所谓的“多变一”,也就是说,旧日志文件中的多条命令,在重写后的新日志中变成了一条命令。
    • AOF文件是以追加的方式,逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时,AOF文件会记录相应的多条命令。但是,在重写的时候,是根据这个键值对当前的最新状态,为它生成对应的写入命令。这样一来,一个键值对在重写日志中只用一条命令就行了,而且,在日志恢复时,只用执行这条命令,就可以直接完成这个键值对的写入了。

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

    • 手动触发: 直接调用bgrewriteaof命令

    • 自动触发: 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机;

      • auto-aof-rewrite-min-size: 表示运行AOF重写时文件最小体积,默认为64MB;
      • auto-aof-rewrite-percentage: 代表**当前AOF文件空间(aof_curent_size)和上次重写后AOF文件空间(aof_base_size)**的比值
      • 自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&(aof_current_size-aof_base_size)/aof_base_size>=auto-auto-aof-rewrite-percentage
      • 其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看

  • 重写过程

    • 和AOF日志由主程序写回,重写过程是由后台线程bgrewirteaof来完成的,这也是为了避免主线程,导致数据库性能下降.

    • 一个拷贝,两处日志

      • **“一个拷贝”**就是指,每次执行重写时,主线程fork出后台的bgrewriteaof子进程。此时,fork会把主线程的内存拷贝(写时复制(Copy On Write)机制)一份给bgrewriteaof子进程,这里面就包含了数据库的最新数据。然后,bgrewriteaof子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,记入重写日志。

      • “两处日志”

        • 因为主线程未阻塞,仍然可以处理新来的操作。此时,如果有写操作,第一处日志就是指正在使用的AOF日志,Redis会把这个操作写到它的缓冲区。这样一来,即使宕机了,这个AOF日志的操作仍然是齐全的,可以用于恢复。
        • 而第二处日志,就是指新的AOF重写日志。这个操作也会被写到重写日志的缓冲区。这样,重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后,重写日志记录的这些最新操作也会写入新的AOF文件,以保证数据库最新状态的记录。此时,我们就可以用新的AOF文件替代旧文件了。
        img

    img

  • 1- 执行AOF重写请求

    • 若当前进程正在执行AOF重写,请求不执行并返回如下响应:

      ERR Backgroud append only file rewrite already in progress

    • 若当前进程正在执行bgsave操作们,重写命令延迟到bgsave完成之后再执行,返回如下响应:

      Backgroud append only file rewriting scedule

  • 2-父进程执行fork创建子进程,开销等同于bgsave过程

  • 3.1-主进程fork操作完成后,继续响应其他命令.所有修改命令依然写入AOF缓冲区并更具appendfsync策略同步到硬盘,保证原有AOF机制正确性.

  • 3.2-由于fork操作运用写时复制技术,子进程只能共享fork操作时的内存数据.由于父进程依然响应命令,Redis使用"AOF重写缓冲区"保存这部分新数据,防止新AOF文件生成期间丢失这部分数据.

  • 4-子进程根据内存快照,按照命令合并规则写入新的AOF文件.每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制,默认为32MB,单次刷盘数据过多造成硬盘阻塞.

  • 5.1-新AOF文件写入完成后,子进程发送信号给父进程,父进程更新统计信息,具体见info persistence下aof_*相关统计.

  • 5.2-父进程把AOF重写缓冲区的数据写入到新的AOF文件.

  • 5.3-使用新AOF文件替换老文件,完成AOF重写;

重启加载(load)

  • 当Redis服务器重启时,可以加载AOF文件进行数据恢复;

  • AOF和RDB文件都可以用于服务器重启时的数据恢复.

  • Redis持久化文件加载流程:

    img

    • 1- AOF持久化开启且存在AOF文件时,优先加载AOF文件,打印如下日志

      DB loaded from append only file: 5.841 seconds

    • 2- AOF关闭或者AOF文件不存在时,加载RDB文件,打印如下日志:

      DB loaded from disk: 5.586 seconds

    • 3- 加载AOF/RDB文件后,Redis启动成功;

    • 4- AOF/RDB文件存在错误时,Redis启动失败并打印错误信息;

文件校验

  • 加载损坏的AOF文件时会拒绝启动,并打印如下日志:

    Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

  • 对于错误格式的AOF文件,先进行备份,然后采用redis-check-aof --fix命令进行修复,修复后使用diff -u对比数据的差异,找出丢失的数据,有些可以人工修改不全.

  • AOF文件可能存在结尾不完整的情况,比如机器突然掉电导致AOF尾部文件命令写入不全.Redis为我们提供了aof-load-truncated配置来兼容这种情况,默认开启,加载AOF时,当遇到此问题是会忽略并继续启动,同时打印如下告警日志:

    # !!! Waring: short read while loading the AOF file !!!

    # !!! Truncating the AOF at offset 3997856725!!!

    # AOF loaded anyway beacause aof-load-truncated is enabled

AOF追加阻塞

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

    img

  • 阻塞流程分析

    • 主线程复制写入AOF缓冲区
    • AOF线程复制每秒执行一次同步磁盘操作,并记录最近一次同步时间
    • 主线程复制对比上次AOF时间
      • 若距上次同步成功时间在2秒内,主线程直接返回;
      • 若距上次同步成功时间超过2秒,主线程将会阻塞,直到同步操作完成

  • AOF阻塞流程可以发现两个问题

    • everysec配置最多可能丢失2秒数据,而不是1秒;
    • 若系统fsync缓慢,将会导致Redis主线程阻塞影响效率.

  • AOF阻塞问题定位

    • 发生AOF阻塞时,Redis输出如下日志,用于记录AOF fsync阻塞导致拖慢Redis服务的行为:

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

    • 每当发生AOF追加阻塞事件发生时,在info Persistence统计中,aof_delayed_fsync指标会累加,查看这个指标方便定位AOF阻塞问题.

    • AOF同步最多运行2秒的延迟,当延迟发生时说明硬盘存在搞复杂问题,可以通过监控工具如iotop,定位消耗硬盘IO资源.

RDB和AOF的优缺点

RDB优点

  • RDB 是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
  • RDB 是一个紧凑的单一文件,很方便传送到另一个远端数据中心,非常适用于灾难恢复。
  • RDB 在保存 RDB 文件时父进程唯一需要做的就是 fork 出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他 IO 操作,所以 RDB 持久化方式可以最大化 Redis 的性能。
  • 与AOF相比,在恢复大的数据集的时候,RDB 方式会更快一些。

AOF优点

  • 你可以使用不同的 fsync 策略:无 fsync、每秒 fsync 、每次写的时候 fsync .使用默认的每秒 fsync 策略,

    • Redis 的性能依然很好 fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障,你最多丢失1秒的数据。

  • AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满,写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。

  • Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写:重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。

  • AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松。导出(export) AOF 文件也非常简单:举个例子, 如果你不小心执行了 FLUSHALL 命令, 但只要 AOF 文件未被重写, 那么只要停止服务器, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重启 Redis , 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

RDB缺点

  • Redis 要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在 Redis 意外宕机,你可能会丢失几分钟的数据。
  • RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候, fork 的过程是非常耗时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。

AOF缺点

  • 对于相同的数据集来说,AOF 文件的体积通常要大于RDB文件的体积。
  • 数据恢复(load)时AOF比RDB慢,通常RDB 可以提供更有保证的最大延迟时间。
RDB AOF
持久化方式 定时对整个内容做快照 记录每一次执行的命令
数据完整性 不完整,两次备份之间会丢失 相对完整,取决于刷盘策略
文件大小 会压缩,文件体积小 记录命令,文件体积大
宕机恢复速度 很快 慢
数据恢复优先级 低,因为数据完整性不如AOF 高,因为数据完整性更高
系统资源占用 高,大量CPU和内容消耗 低,主要数据完整性更高
使用场景 可以容忍数分钟的数据丢失,追求更快的启动速度 对数据安全性要求较高常见

服务器端优化-持久化配置

  • Redis的持久化虽然可以保证数据安全,但也会带来很多额外的开销,因此持久化请遵循下列建议：

    • 用来做缓存的Redis实例尽量不要开启持久化功能

    • 建议关闭RDB持久化功能,使用AOF持久化

    • 利用脚本定期在slave节点做RDB,实现数据备份

    • 设置合理的rewrite阈值,避免频繁的bgrewrite

    • 配置no-appendfsync-on-rewrite = yes,禁止在rewrite期间做AOF,避免因AOF引起的阻塞

    • 部署有关建议：

      • Redis实例的物理机要预留足够内存,应对fork和rewrite
        • 单个Redis实例内存上限不要太大,例如4G或8G。可以加快fork的速度、减少主从同步、数据迁移压力
        • 不要与CPU密集型应用部署在一起
        • 不要与高硬盘负载应用一起部署。例如：数据库、消息队列

RDB和AOF的选择

  • 数据不能丢失时,内存快照和AOF的混合使用是一个很好的选择；
  • 如果允许分钟级别的数据丢失,可以只使用RDB；
  • 如果只用AOF,优先使用everysec的配置选项,因为它在可靠性和性能之间取了一个平衡。

Redis采用fork子进程重写AOF文件时,潜在的阻塞风险?

AOF日志重写的时候,是由bgrewriteaof子进程来完成的,不用主线程参与,我们今天说的非阻塞也是指子进程的执行不阻塞主线程。但是,你觉得,这个重写过程有没有其他潜在的阻塞风险呢？如果有的话,会在哪里阻塞?

  • Redis采用fork子进程重写AOF文件时,潜在的阻塞风险包括:

    • fork子进程

      fork子进程,fork这个瞬间一定是会阻塞主线程的(注意,fork时并不会一次性拷贝所有内存数据给子进程),fork采用操作系统提供的写时复制(Copy On Write)机制,就是为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题,但fork子进程需要拷贝进程必要的数据结构,其中有一项就是拷贝内存页表(虚拟内存和物理内存的映射索引表),这个拷贝过程会消耗大量CPU资源,拷贝完成之前整个进程是会阻塞的,阻塞时间取决于整个实例的内存大小,实例越大,内存页表越大,fork阻塞时间越久。拷贝内存页表完成后,子进程与父进程指向相同的内存地址空间,也就是说此时虽然产生了子进程,但是并没有申请与父进程相同的内存大小。那什么时候父子进程才会真正内存分离呢？“写实复制”顾名思义,就是在写发生时,才真正拷贝内存真正的数据,这个过程中,父进程也可能会产生阻塞的风险,就是下面介绍的场景。

    • AOF重写过程中父进程产生写入的场景

      fork出的子进程指向与父进程相同的内存地址空间,此时子进程就可以执行AOF重写,把内存中的所有数据写入到AOF文件中。但是此时父进程依旧是会有流量写入的,如果父进程操作的是一个已经存在的key,那么这个时候父进程就会真正拷贝这个key对应的内存数据,申请新的内存空间,这样逐渐地,父子进程内存数据开始分离,父子进程逐渐拥有各自独立的内存空间。因为内存分配是以页为单位进行分配的,默认4k,如果父进程此时操作的是一个bigkey,重新申请大块内存耗时会变长,可能会产阻塞风险。另外,如果操作系统开启了内存大页机制(Huge Page,页面大小2M),那么父进程申请内存时阻塞的概率将会大大提高,所以在Redis机器上需要关闭Huge Page机制。Redis每次fork生成RDB或AOF重写完成后,都可以在Redis log中看到父进程重新申请了多大的内存空间。

AOF重写也有一个重写日志,为什么它不共享使用AOF本身的日志呢？

AOF重写不复用AOF本身的日志,

  • 一个原因是父子进程写同一个文件必然会产生竞争问题,控制竞争就意味着会影响父进程的性能。

  • 二是如果AOF重写过程中失败了,那么原本的AOF文件相当于被污染了,无法做恢复使用。所以Redis AOF重写一个新文件,重写失败的话,直接删除这个文件就好了,不会对原先的AOF文件产生影响。等重写完成之后,直接替换旧文件即可。