【redis】RDB与AOF持久化的区别

RDB介绍

1、触发机制：

        save手动触发：阻塞当前redis服务器，直到rdb过程完成。不建议使用

        bgsave手动触发：fork创建子进程，由子进程完成持久化。阻塞只存在fork阶段。

        自动触发：

                save m n （在m内修改n次，自动触发bgsave）

                从节点执行全量复制，主节点自动执行bgsave

                执行debug reload命令，触发save

                执行shutdown，没有开启AOF自动执行bgsave

2、持久化文件处理方式

        默认采用LZF算法对生成RDB二进制文件压缩。（压缩会消耗cpu，但能大幅降低文件体积）

3、优点

       适用于备份、全量复制场景。比如每6小时执行bgsave，用于熔灾恢复。

        RDB恢复数据远快于AOF

4、缺点

        不能做到秒级、实时持久化， fork子进程、频繁执行，性能耗费严重

        使用特定二进制格式保存，存在新老版本不兼容问题

AOF介绍

1、触发机制：采用缓冲区文件同步策略。可配置写入文件时机。

     同步策略介绍：新命令写入AOF缓冲区 -> sync按规则将缓冲区向硬盘同步 ->在硬盘AOF文件过大时，按规则对文件重写。

    sync同步硬盘3种策略：

                always：有新命令立即执行，将文件同步到硬盘

                everysec（推荐）：每秒同步一次

                no：同步硬盘操作由操作系统负责，周期最长30s

2、AOF文件重写机制详解

      重写后硬盘文件通过以下方式进行压缩

                1、进程内的超时数据不再进行保存

                 2、旧的AOF无效命令直接生成数据。如del key、hdel key、set aaa 1 set aaa2

                 3、多条命令合并处理。对于list、set、zset、hash类型。防止单条数据过大，以64个元素拆分多条

      AOF重写触发机制

                 1、手动调用 bgrewriteaof

                  2、根据配置自动触发 auto-aof-rewrite-min-size（默认64M，超过此数值执行），auto-aof-rewrite-percentage（新增数据超过，最后一次执行的百分之几触发）。两者同时满足后触发

3、持久化文件处理方式

        采用文本格式直接存储。兼容性更好，避免二次处理开销。

4、优点

       可以实现秒级、实时持久化，且性能耗费低

5、缺点

       everysec策略，存在追加阻塞可能，严重情况小概率会丢失2s数据 

       恢复数据耗时较长