Redis中RDB与AOF的区别及说明

在Redis的使用中持久化是一个重要的特性它将内存中的数据保存到硬盘上以防止数据丢失。Redis 提供了三种主要的持久化方式AOFAppend Only File、RDBRedis DataBase以及混合持久化RDB和AOF。本文将详细介绍 AOF 和 RDB 的区别及配置方式帮助读者更好地理解和选择合适的持久化方式。2.RDB和AOF2.1 RDB2.1.1 RDB概念RDB 持久化方式是 Redis 将当前内存中的数据快照snapshot保存到硬盘的过程。这种方式是就是将内存中数据以快照的方式写入到二进制文件中默认的文件名为dump.rdb。其实就是每隔一段时间Redis 会创建一个代表某一时刻的数据集的磁盘文件。2.1.2 RDB工作原理Copy-On-WriteRDB 的生成过程依赖于操作系统的写时复制COW机制这一机制确保了快照生成期间 Redis 依然能正常处理读写请求不会阻塞业务。具体流程如下1.触发快照生成当满足预设条件时时间到、达到修改次数阈值Redis 主进程会fork 一个子进程此时子进程与主进程共享同一块内存空间2.子进程写入快照子进程负责遍历内存中的所有数据将其序列化后写入一个临时的.rdb 文件3.主进程正常服务在子进程生成快照期间主进程继续处理客户端的读写请求。若有数据被修改操作系统会为该数据块创建一个副本主进程修改副本数据而子进程依然读取原始数据避免快照被污染4.替换旧快照当子进程完成快照写入后会用临时文件替换当前的.rdb 文件至此一次 RDB 持久化完成。2.1.3 RDB触发方式1.自动触发基于配置的指定时间修改次数在Redis 的配置文件redis.conf中通过save指令定义RDB的触发规则格式为1save seconds changes [seconds changes ...]表示 “在 seconds 秒内若数据修改次数达到 changes 次则触发 RDB”。默认配置如下1234# 3600秒(1小时)内修改1次、300秒内修改100次、60秒内修改10000次满足任一条件即触发RDBsave 3600 1save 300 100save 60 100002.手动触发主动备份场景手动触发主要通过save、bgsave指令实现save命令由主进程直接生成 RDB期间会阻塞所有客户端请求线上不推荐使用会阻塞请求导致业务中断bgsave命令主进程 fork 子进程生成 RDB主进程本身不阻塞线上手动触发的首选指令3.RDB核心配置文件12345678#指定 RDB 文件的名称默认为dump.rdbdbfilename dump.rdb#指定 RDB 文件的保存路径默认是 Redis 的启动目录建议改为绝对路径如/var/redis/dir ./#是否对 RDB 文件进行压缩默认开启用 CPU 开销换取磁盘空间关闭可提升快照速度rdbcompression yes#是否对 RDB 文件进行校验默认开启通过 CRC64 算法确保文件完整性关闭可提升加载速度rdbchecksum yes4.RDB优缺点优点恢复速度快RDB 是二进制的全量快照加载时无需解析复杂指令仅需反序列化数据适合大规模数据的快速恢复文件体积小压缩后的 RDB文件体积远小于 AOF 文件便于备份和传输对性能影响小子进程负责生成快照主线程仅在fork子进程时短暂阻塞阻塞时间与内存大小相关通常毫秒级对业务读写影响低。缺点数据一致性低 RDB获取的是“某一时间点快照”若在两次快照间隔期间 Redis 宕机则该时间段内修改的数据将全部丢失例如配置save 30 1000则最多可能丢失30秒的数据文件可读性性低RDB 文件是一个二进制文件并不是一个易于读取和理解的文本文件不适合实时备份存在丢失数据的可能适用于对数据一致性要求不高的业务。2.2 AOF2.2.1 AOF概念AOF其实就是将每一个收到的写命令都通过write函数追加到文件中当 Redis 需要恢复数据时只需执行 AOF 文件中的命令就可以恢复到原来的状态。这个文件有点像MySQL的binlog日志文件只不过binlog日志文件是二进制Redis的AOF生成的文件是文本格式。2.2.2 AOF工作原理1.命令追加每当 Redis 执行一条写命令并成功处理后会将该命令按照 Redis 协议格式追加到内存中的 “AOF 缓冲区”避免直接写入磁盘降低IO开销。2.文件刷盘AOF 缓冲区中的命令需要定期写入磁盘刷盘策略由appendfsync配置决定。3.日志重写随着运行时间延长AOF 文件会产生大量重复命令如多次set同一个key而变得异常庞大占用大量磁盘空间还会导致Redis重启恢复时间边长。Redis携带了 “日志重写” 机制会生成一个包含 “当前内存数据最终状态” 的精简 AOF 文件替换旧的AOF文件能有效降低空间占用率、提升恢复效率。例如若指定key的值经过多次set最终是value3AOF文件中记录了SET key value1、SET keyvalue2、SET key value3三条命令重写后只会保留SET key value3一条命令。2.2.3 AOF配置1.启用AOF123456# 启用AOF默认noappendonly yes# AOF文件名称默认appendonly.aofappendfilenameappendonly.aof# AOF文件保存路径与RDB一致dir ./2.刷盘策略appendfsync定义了 AOF 缓冲区的命令何时写入磁盘有三种可选值值解释always每执行一条写命令立即将缓冲区内容写入到磁盘数据安全性高IO频繁everysec每秒将缓冲区内容写入磁盘一次数据安全性一般性能适中no由操作系统决定何时写入磁盘默认30秒刷盘一次数据安全性低性能较高3.日志重写规则AOF 重写同样支持自动触发和手动触发自动触发通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置实现12auto-aof-rewrite-percentage 100 # 当AOF文件大小比上次重写后增大100%即翻倍时触发auto-aof-rewrite-min-size64mb # 当AOF文件大小至少达到64MB时才触发避免小文件频繁重写手动触发执行bgrewriteaof命令主进程 fork 子进程完成重写不阻塞业务和bgsave类似。4.AOF优缺点优点数据一致性高可通过appendfsync always实现 “数据零丢失”或everysec实现 “最多丢失 1 秒数据”满足高一致性需求日志可读性强由于AOF 文件是一个易于读取和理解的文本文件可以方便地进行数据恢复、备份和分析可靠性高记录了Redis执行的所有写操作可以提供更可靠的数据持久性避免数据丢失。缺点恢复速度慢恢复数据时需要执行大量的写命令因此恢复速度相对较慢文件体积大即使经过重写AOF 文件体积通常仍大于 RDB 文件占用更多磁盘空间性能开销较高每次写操作都需要追加到 AOF 文件中可能会导致磁盘 I/O 的负载增加。