Redis持久化RDB和AOF

prger
588 阅读10分钟

前言：在工作中，Redis是一个必不可少的框架，用来做持久化。说到持久化，那肯定就不能少了RDB和AOF这两种持久化方式，接下来我们就来探知他们

持久化的意义

在使用Redis做持久化的时候，很少会去想Redis持久化的意义，在我看来，Redis持久化的意义在于故障修复。比如部署了redis，作为cache缓存，如果没有持久化的话，Redis遇到灾难性故障的时候，数据就会丢失，如果通过持久化将数据存储在磁盘上，然后定期同步和备份到云存储服务上去，那么就可以保证数据不丢失，还是可以恢复一部分数据的

持久化的方式

**RDB：**对Redis中的数据根据规则执行周期性的持久化

AOF： 对每条写入日志，以append-only的模式写入一个日志文件中，在Redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集

RDB

RDB是一个将Redis内存数据生成快照保存到磁盘的过程。RDB持久化可以分为手动触发和自动触发

手动触发

save：此命令是一个同步操作，会阻塞当前Redis进行，造成服务不可用，知道RDB过程完成，不建议使用

192.168.42.129:6379> save
OK

**bgsave：该命令会通过for()**创建子进程，在后台进行存储

192.168.42.129:6379> BGSAVE
Background saving started

自动触发

在实际开发中，我们一般不会通过命令来生成RDB文件，在Redis中是默认开启自动触发的RDB持久化的，我们可以通过redis.conf配置文件可以查看到

#redis.conf
save 900 1
save 300 10
save 60 10000

**save 60 10000：**每隔60s，如果有超过10000个key发生了变更，那么就会生成一个新的dump.rdb文件，就是当前Redis内存中完整的数据快照

工作流程

  1. redis执行bgsave命令，Redis判断当前存在正在进行执行的子进程，如RDB/AOF子进程，存在bgsave命令直接返回
  2. fork出子进程，fork操作中Redis父进程会阻塞
  3. fork完成返回
  4. 子进程对内存数据生成一个临时的RDB快照文件
  5. 子进程告诉父进程处理完成，然后替换之前的旧的快照文件
image-20210422053022935

基于RDB持久化机制的数据恢复实验

(1) 在Redis中保存几条数据，立即停掉Redis进程，然后重启Redis，你会发现数据还在，这是为什么呢？

RDB的机制的触发方式

通过redis-cli SHUTDOWN这种方式停掉Redis，是一种安全的退出模式，Redis会在退出的时候将内存中的数据立即生成一份完整的快照保存起来

(2) 在Redis中在保存几条新数据，用kill -9强制杀死Redis进行，模拟Redis故障异常退出，会导致内存数据丢失

(3) 在redis.conf配置文件中设置一个save 5 1，每隔5秒，超过1个key变更，就会自动生成一个dump.rdb文件，然后异常杀掉Redis进行，再重启Redis，可以发现插入的数据还在

RDB的优点和缺点

优点

  1. RDB会生成多个数据文件，每个数据文件都代表了某一时刻中Redis的数据，这种多个数据文件的方式，非常适合做冷备

    使用RDB做冷备的优势

    1. 由Redis去控制固定时长生成快照文件操作，比较方便；AOF需要自己写一些脚本去做这个事情，不方便
    2. RDB数据做冷备，在最坏的情况下，提供数据恢复时候，速度比AOF快

  2. RDB在Redis对外提供的读写速度，影响非常小，可以让Redis保持高性能，因为Redis主进程只需要fork一个子进程，让子进程来执行磁盘I/O操作来进行持久化

    RDB 每次写，都是直接写Redis内存，只是在一定时候，才会将数据写入磁盘中

    AOF每次写都是要写文件的，虽然可以快速的写入os cache中，但是还是有一定的时间开销，速度肯定比RDB略慢一些

  3. 相比AOF持久化机制来说，直接基于RDB数据文件来重启和恢复Redis进程，更加的快速

    AOF 存放的是指令文件，做数据恢复是，其实是要回放和执行所有的指令日志来恢复出内存中的所有数据的

    RDB 就是一份数据文件，恢复的时候，直接加载到内存中即可

结合上述优点，RDB非常适合做冷备份

缺点

  1. 如果想要在Redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦Redis进程宕机，那么会丢失最近5分钟的数据

    这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多

  2. DB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒

    一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的

AOF

如果Redis进程崩溃，那么两个RDB之间的数据是会丢失的，而AOF能很好的解决这个问题，AOF每次都会将指令写入文件。AOF会先将命令写入到os cache中，然后根据策略写入硬盘**(appendfsync)**

AOF配置

在Redis中，AOF持久化是默认关闭的，如果想要开启AOF持久化，需要在redis.conf文件修改一些配置

appendonly yes  # 是否开启aof文件模式
appendfilename "appendonly-6379.aof" # aof文件名称
appendfsync  everysec  # aof策略模式
dir /redis/data  # 数据存储路径
no-appendfsync-on-rewrite yes  #在重写的时候, 不要执行aof操作
auto-aof-rewrite-percentage 100  # 自动重写的百分比
auto-aof-rewrite-min-size     64mb # 重写的大小配置

appendfsync

**always：**每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常差，吞吐量很低，

everysec： 每秒将os cache中的数据fsync到磁盘，推荐使用

no： 仅仅Redis负责将数据写入到os cache就撒手不管，然后os自己会时不时根据自己的策略将数据刷入磁盘，不可控

auto-aof-rewrite-percentage、auto-aof-rewrite-min-size

比如说上一次AOF rewrite之后，是128mb

然后就会接着128mb继续写AOF的日志，如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite

但是此时还要去跟min-size，64mb去比较，256mb > 64mb，才会去触发rewrite

工作流程

redis中的数据，是有一定限量的，不能说redis内存中的数据无线增长，进而导致AOP无线增长

redis的内存大小是一定的，到了峰值，redis就会使用缓存淘汰算法,比如LRU，自动将一部分数据从内从中清除

AOF中存放的数据越来越大，当大到一定程度，AOF会做rewrite操作，基于当前redis内存中的数据，重新构建一个新的AOF文件，然后将旧的AOF文件删除

  1. Redis fork一个子进程

  2. 子进程基于当前内存的数据，构建日志，开始往一个新的临时的AOF文件中写入日志

  3. Redis主进程，接收到客户端新的写入操作之后，在内存汇总写入日志的同时，新的日志也会继续写入旧的AOF文件

  4. 子进程写完新的日志文件之后，Redis会将内存中的新的日志再次追加到新的AOF文件中

  5. 用新的日志文件替换掉旧的日志文件

image-20210422064144784

AOF破损文件修复

如果Redis在append数据到AOF文件时宕机了，可能会导致AOF文件破损

使用redis-check-aof --fix命令来修复破损的AOF文件

AOF和RDB同时工作

  1. 如果RDB在执行快照操作，那么Redis不会执行AOF rewrite；如果Redis再执行AOF rewrite，那么就不会执行RDB快照
  2. 如果RDB在执行快照，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite
  3. 同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整

基于AOF持久化数据恢复实验

  1. 在有rdb的dump和aof的appendonly的同时，rdb里也有部分数据，aof里也有部分数据，这个时候其实会发现，rdb的数据不会恢复到内存中

  2. 我们模拟让aof破损，然后fix，有一条数据会被fix删除

  3. 再次用fix得aof文件去重启redis，发现数据只剩下一条了

数据恢复完全是依赖于底层的磁盘的持久化的，主要rdb和aof上都没有数据，那就没了

AOF的优点和缺点

优点

  1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据
  2. AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复
  3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
  4. AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

缺点

  1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
  2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
  3. 唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适

RDB和AOF到底该如何选择

  1. 不要仅仅使用RDB，因为那样会导致你丢失很多数据
  2. 也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
  3. 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复
avatar
文章
阅读
粉丝