Redis 持久化之RDB和AOF

RDB、AOF详解及优缺点总结

Redis 持久化之RDB和AOF

Redis 的两种数据持久化保存机制 ，RDB （Redis DataBase）和 AOF （Append Only File）

RDB持久化

RDB持久化是指把当前内存中的数据集快照写入磁盘的过程。

触发RDB持久化过程分为自动触发和手动触发。

自动触发是默认的持久化方式，这种方式就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb，Redis 重启会通过加载dump.rdb文件恢复数据。我们也可以通过配置文件来修改Redis服务器保存快照的频率， 在redis.conf 配置文件中的 SNAPSHOTTING 下，上文Redis配置文件详解中已做详细介绍。

手动触发包括save和bgsave两种方式

save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。

bgsave命令：Redis从master主进程先fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件，比如:tmp-.rdb，当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这 样可以保证每一次做RDB快照保存的数据都是完整的。因为直接替换RDB文件的时候,可能会出现突然断电等问题,而导致RDB文件还没有保存完整就因为突然关机停止保存,而导致数据丢失的情况.后续可以手动将每次生成的RDB文件进行备份，这样可以最大化保存历史数据。

RDB模式的优点

  • RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave(非阻塞，后台执行)或者 save(会阻塞写操作,不推荐)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不 同时间点的版本,很适合备份,并且此文件格式也支持有不少第三方工具可以进行后续的数据分析 比如: 可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个 ROB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

  • RDB可以最大化Redis的性能，父进程在保存 RDB文件时唯一要做的就是fork出一个子进程，然后 这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/0操作。

  • Redis加载RDB恢复数据远远快于AOF的方式

  • RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复

RDB模式的缺点

  • 不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据

    如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的 保存点（save point）来控制保存RDB文件的频率，但是，因为ROB文件需要保存整个数据集的状 态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况 下，一旦发生故障停机，你就可能会丢失好几分钟的数据。

  • 当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或 者秒，取决于磁盘IO性能；在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失

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

     

AOF持久化

AOF（append only file）持久化：按照操作顺序依次将操作追加到指定的日志文件末尾 AOF 和 RDB 一样使用了写时复制机制，AOF默认为每秒钟 fsync一次，即将执行的命令保存到AOF文件 当中，这样即使redis服务器发生故障的话最多只丢失1秒钟之内的数据，也可以设置不同的fsync策略 always，即设置每次执行命令的时候执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用 户的正常请求而不受到写入AOF文件的I/O影响 同时启用RDB和AOF,进行恢复时,默认AOF文件优先级高于RDB文件,即会使用AOF文件进行恢复 注意: AOF 模式默认是关闭的,第一次开启AOF后,并重启服务生效后,会因为AOF的优先级高于RDB,而 AOF默认没有文件存在,从而导致所有数据丢失

AOF 重写

因为 AOF 持久化是通过保存被执行的写命令来记录 Redis 状态的，所以随着 Redis 长时间运行，AOF 文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的 AOF 文件很可能对 Redis 甚至宿主计算机造成影响。

为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 文件重写( rewrite) 功能，以达到压缩的目的。

AOF重写可以通过auto-aof-rewrite-min-size和auto-aof-rewritepercentage参数控制自动触发，也可以使用bgrewriteaof命令手动触发。

手动执行AOF重写 BGREWRITEAOF 命令 ：

 127.0.0.1:6379> BGREWRITEAOF
 Background append only file rewriting started
 ​
 时间复杂度： O(N)， N 为要追加到 AOF 文件中的数据数量。
 执行一个 AOF文件 重写操作。重写会创建一个当前 AOF 文件的体积优化版本。
 即使 BGREWRITEAOF 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 BGREWRITEAOF 成功之
 前不会被修改。
 重写操作只会在没有其他持久化工作在后台执行时被触发，也就是说：
 如果 Redis 的子进程正在执行快照的保存工作，那么 AOF 重写的操作会被预定(scheduled)，等到保存
 工作完成之后再执行 AOF 重写。在这种情况下， BGREWRITEAOF 的返回值仍然是 OK ，但还会加上一条
 额外的信息，说明 BGREWRITEAOF 要等到保存操作完成之后才能执行。在 Redis 2.6 或以上的版本，可
 以使用 INFO [section] 命令查看 BGREWRITEAOF 是否被预定。
 如果已经有别的 AOF 文件重写在执行，那么 BGREWRITEAOF 返回一个错误，并且这个新的
 BGREWRITEAOF 请求也不会被预定到下次执行。
 从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作  

redis默认不启用AOF功能，需要在redis.conf 配置文件中的 APPEND ONLY MODE 下手动开启，上文Redis配置文件详解中已做详细介绍。

AOF模式的优点

  • 数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存 储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以 保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执 行，所以主线程可以继续努力地处理命令请求)

  • 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出 现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出 现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决 数据一致性的问题

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

  • AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文 件完成数据的重建 AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因 此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件 也非常简单:举个例子，如果你不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只 要停止服务器，移除 AOF文件末尾的FLUSHALL命令，并重启Redis ,就可以将数据集恢复到 FLUSHALL执行之前的状态

AOF模式的缺点

  • 即使有些操作是重复的也会全部记录，AOF 的文件大小要大于 RDB 格式的文件

  • AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢

  • 根据fsync策略不同,AOF速度可能会慢于RDB

     

总结

  1. Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。

  2. RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。

  3. Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。

  4. AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

  5. Redis 针对 AOF文件大的问题，提供重写的瘦身机制。

  6. AOF 策略会使数据稳定性更高，具有更完整的数据备份，RDB 恢复效率高适合做灾难恢复，建议生产环境上两者都开启。

posted @ 2021-08-03 22:17  屈宏志  阅读(208)  评论(0)  编辑  收藏  举报