Redis持久化：从AOF到RDB，如何实现数据不丢失？

Redis属于内存数据库但为了防止宕机等导致的数据丢失也有对应的数据持久化技术。持久化主要作用就是数据备份即将数据存储在硬盘保证数据不会因进程退出而丢失。AOF持久化Append Only File类似于Mysql的binlog日志类似会吧写操作命令以追加写的方式写入到AOF日志中。当重启redis后先去读取这个文件里的命令并且执行它就相当于恢复了缓存数据。Redis写入日志过程图Redis 在执行完写操作命令后并不会直接将命令写入到硬盘中的AOF日志中因为这样将会产生大量的IO而是会将命令追加到 server.aof_buf 缓冲区然后通过 write() 系统调用将 aof_buf 缓冲区的数据写入到 AOF 文件此时数据并没有写入到硬盘而是拷贝到了内核缓冲区 page cache等待内核将数据写入硬盘具体缓冲区的数据什么时候写入到硬盘由写回策略来决定。三种写回策略Redis有三种写回策略Always每次写操作命令执行完后总是会将 AOF 日志数据写回硬盘Everysec每次写操作命令执行完后先将命令写入到 AOF 文件的内核缓冲区然后每隔一秒将缓冲区里的内容写回到硬盘No意味着不由 Redis 控制写回硬盘的时机转交给操作系统控制写回的时机也就是每次写操作命令执行完后先将命令写入到 AOF 文件的内核缓冲区再由操作系统决定何时将缓冲区内容写回硬盘。这三种写回策略在源码中其实就是在控制fsync()方法的调用时机。if (sdslen(server.aof_buf) 0) {//检查aof_buf中有没有数据 if (server.aof_fsync AOF_FSYNC_EVERYSEC server.aof_last_incr_fsync_offset ! server.aof_last_incr_size server.unixtime server.aof_last_fsync !(sync_in_progress aofFsyncInProgress())) { goto try_fsync;//控制每秒写回异步执行不影响主线程 } else if (server.aof_fsync AOF_FSYNC_ALWAYS server.aof_last_incr_fsync_offset ! server.aof_last_incr_size){ goto try_fsync;//总是写回由主线程执行未返回会阻塞主线程 } else { //redis不控制写回最终交给操作系统决定何时写回不影响主线程 return; } }显然Always写回策略是由主进程执行的总是调用fsync函数Everysec异步执行不影响主线程No则redis不控制写回最终交给操作系统决定何时写回不影响主线程fsync()函数会将内存中修改的数据和文件描述符的属性持久化到存储设备中并且等到硬盘写操作完成后该函数才会返回。三种写回策略的优缺点AOF 重写机制重写机制主要就是为了压缩AOF文件的大小当 AOF 文件的大小超过所设定的阈值后Redis 就会启用 AOF 重写机制来压缩 AOF 文件。//表示当前AOF文件空间aof_current_size 和上一次重写后AOF文件空间aof_base_size 的比值。 auto-aof-rewrite-percentage 100 //表示运行AOF重写时文件最小体积 默认为64MB。 auto-aof-rewrite-min-size 64mbAOF 重写机制是在重写时读取当前数据库中的所有键值对然后将每一个键值对用一条命令记录到新的 AOF 文件等到全部记录完后就将新的 AOF 文件替换掉现有的 AOF 文件。重写机制的原理如果某个键值对被多条写命令反复修改最终也只需要根据这个键值对当前的最新状态然后用一条命令去记录键值对代替之前记录这个键值对的多条命令这样就减少了 AOF 文件中的命令数量。重写时为什么不复用当前AOF如果 AOF 重写过程中失败了现有的 AOF 文件就会造成污染可能无法用于恢复使用。Redis 的重写 AOF 过程是由后台子进程 bgrewriteaof来完成的RDB快照RDB 快照就是记录某一个瞬间的内存数据记录的是实际数据也就是说RDB是全量快照也就是说每次执行RDB都是把内存中的所有数据都记录到磁盘中。当需要恢复数据时 RDB 恢复数据的效率也会比 AOF 高些因为直接将 RDB 文件读入内存就可以不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。由于RDB是全量快照因此不建议过于频繁但频率过低也会导致丢失的数据更多。执行命令RDB全量模式持久化将数据写入磁盘的动作可以分为SAVE与BGSAVE两种。所谓BGSAVE就是background-save也就是后台异步save区别点在于SAVE是由Redis的命令执行线程按照普通命令的方式去执行操作而BGSAVE是通过fork出一个新的进程在新的独立进程里面去执行save操作。Redis的请求命令执行是通过单线程的方式执行的所以要尽量避免耗时操作而save动作需要将内存全部数据写入到磁盘上对于redis而言这一操作是非常耗时的会阻塞住全部正常业务请求所以save操作的触发只有两个场景客户端手动发送save命令执行Redis在shutdown的时候自动执行从数据保存完备性方面看这两种方式都起不到自动持久化备份的能力如果出现一些机器掉电等情况是不会触发redis shutdown操作的将面临数据丢失的风险。相比而言bgsave的杀伤力要小一些、适用度也更好一些它可以保证在持久化期间Redis主进程可以继续处理业务请求。bgsave增加了过程中自动持久化操作的机制触发条件更加的“智能”客户端手动命令触发bgsave操作Redis配置定时任务触发支持间隔时间变更数据量双重维度综合判断达到任一条件则触发此外在master-slave主从部署的场景中还支持仅由slave节点触发bgsave操作来降低对master节点的影响。写时复制技术Redis可以执行bgsave将生成RDB的工作交给子进程来做此时Redis主线程还可以继续处理操作命令。Redis为了实现后台把内存数据的快照写入文件采用了操作系统提供的Copy On Write写时复制技术也就是fork系统调用。写时复制大致过程如下fork系统调用会产生一个子进程与父进程共享相同的内存地址空间这样进程在这一时刻就能拥有与父进程的相同的内存数据。虽然子进程与父进程共享同一块内存地址空间但在fork子进程时操作系统需要拷贝父进程的内存页表给子进程如果整个Redis实例内存占用很大那么它的内存页表也会很大在拷贝时就会比较耗时同时这个过程会消耗大量的CPU资源。在完成拷贝之前父进程也处于阻塞状态无法处理客户端请求。fork执行完之后子进程就可以扫描自身所有的内存数据然后把全部数据写入到RDB文件中。之后父进程依旧处理客户端的请求当在处理写命令时父进程会重新分配新的内存地址空间从操作系统申请新的内存使用不再与子进程共享这个过程就是Copy On Write写实复制名字的由来。这样父子进程的内存就会逐渐分离父进程申请新的内存空间并更改内存数据子进程的内存数据不受影响。比如当主线程要修改共享数据里的某一块数据比如键值对 A时就会发生写时复制那么这块数据的物理内存就会被复制一份键值对 Abgsave 子进程可以把原来的数据键值对 A写入到 RDB 文件中。与此同时主线程可以在这个数据副本键值对 A进行修改操作。为了保证生成RDB时还能执行操作命令引入的写时复制技术但显然写时复制技术也有其缺点在生成RDB的过程中如果主线程修改了内存数据RDB 快照无法写入主线程刚修改的数据如果此时系统宕机了也就丢失了这部分修改的数据。极端情况下所有数据都被修改那么由于写时复制技术内存占用将会是原来的两倍。如果机器剩余内存不足则可能导致fork的时候两份内存数据量超过机器物理内存大小导致系统启用虚拟内存拷贝速度大打折扣虚拟内存本质上就是把磁盘当内存用操作速度相比物理内存大大降低会阻塞住Redis主进程的命令执行底层的实现仅仅复制了页表但映射的物理内存还是同一个。这样做可以加快 fork 的速度减少性能损耗(fork会阻塞主进程)。注意避免高峰期生成 RDB如果 RDB 时间长且写并发高此时会被系统产生比较大的影响。原因是因为写时复制时如果共享的每一页内存都被修改就会使得内存极速膨胀最大内存可以膨胀两倍所以要注意内存的使用量防止内存过载,RDB 会产生大量的磁盘 I/O要注意磁盘性能导致的影响。还需要注意 CPU 负载毕竟有大量的数据需要写入。因此如果 RDB 在高峰期可能会影响到正常业务需要合理安排生成 RDB 的时机。总结区别记录的数据不一样RDB 快照就是记录某一个瞬间的内存数据记录的是实际数据而 AOF 文件记录的是命令操作的日志AOF 文件的内容是操作命令RDB 文件的内容是二进制数据。恢复数据和执行频率RDB是全量快照恢复数据更快AOF则需要额外执行操作命令相对更慢。RDB是全量快照不宜频繁执行而AOF数据文件更新比较及时比RDB保存更完整的数据这样在数据恢复时能够恢复尽量完整的数据降低丢失数据的风险。因此发生故障时RDB丢失的数据会比 AOF 持久化的方式更多是否影响主进程AOF的Always写回策略是主进程执行的总是调用fsync函数Everysec异步执行不影响主线程No则redis不控制写回最终交给操作系统决定何时写回不影响主线程。RDB可以将工作交给子进程来做此时Redis主线程还可以继续处理操作命令。如果同时存在RDB文件和AOF文件Redis会优先使用AOF文件进行数据恢复。混合持久化RDB 比 AOF 的数据恢复速度快但是快照的频率不好把握如果频率太低两次快照间一旦服务器发生宕机就可能会比较多的数据丢失如果频率太高频繁写入磁盘和创建子进程会带来额外的性能开销。混合持久化就是混合使用 AOF 日志和RDB混合持久化工作在AOF日志重写过程中会把 Redis 的持久化数据以 RDB 的格式写入到 AOF 文件的开头之后写时复制时修改数据再以 AOF 的格式化追加的文件的末尾写入完成后再新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。也就是说使用了混合持久化AOF 文件的前半部分是 RDB 格式的全量数据后半部分是 AOF 格式的增量数据。Redis恢复数据源码AOF 格式的开头是 *而 RDB 格式的开头是 REDIS。if (fread(sig,1,5,fp) ! 5 || memcmp(sig,REDIS,5) ! 0) { // AOF 文件开头非 RDB 格式非混合持久化文件 if (fseek(fp,0,SEEK_SET) -1) goto readerr; } else { /* RDB format. Pass loading the RDB functions. */ rio rdb; int old_style !strcmp(filename, server.aof_filename); if (old_style) serverLog(LL_NOTICE, Reading RDB preamble from AOF file...); else serverLog(LL_NOTICE, Reading RDB base file on AOF loading...); if (fseek(fp,0,SEEK_SET) -1) goto readerr; rioInitWithFile(rdb,fp); // AOF 文件开头是 RDB 格式先加载 RDB 再加载 AOF if (rdbLoadRio(rdb,RDBFLAGS_AOF_PREAMBLE,NULL) ! C_OK) { if (old_style) serverLog(LL_WARNING, Error reading the RDB preamble of the AOF file %s, AOF loading aborted, filename); else serverLog(LL_WARNING, Error reading the RDB base file %s, AOF loading aborted, filename); ret AOF_FAILED; goto cleanup; } else { loadingAbsProgress(ftello(fp)); last_progress_report_size ftello(fp); if (old_style) serverLog(LL_NOTICE, Reading the remaining AOF tail...); } }优点混合持久化结合了 RDB 和 AOF 持久化的优点开头为 RDB 的格式使得 Redis 可以更快的恢复数据同时结合 AOF 的优点减低了大量数据丢失的风险。缺点AOF 文件中添加了 RDB 格式的内容使得 AOF 文件的可读性变得很差兼容性差如果开启混合持久化那么此混合持久化 AOF 文件就不能用在 Redis 4.0 之前版本了。