当前位置：首页 > news >正文

Redis 持久化：RDB 和 AOF 的 “爱恨情仇”

news 2025/9/14 5:48:28

一、RDB：“定时快照” 的急性子

触发方式：手动与自动的 “双响炮”

基本流程（bgsave 版）：“分身术” 的妙用

优缺点：“快” 与 “险” 的博弈

二、AOF：“记录流水账” 的慢性子

开启与配置：“慢工出细活”

优缺点：“全” 与 “大” 的权衡

三、RDB 和 AOF 的 “相爱相杀”

四、“强强联合” 才是王道

一、RDB：“定时快照” 的急性子

RDB，全称 Redis Database Backup file，翻译成人类能懂的话，就是 Redis 的数据快照。你可以把它想象成给 Redis 的内存数据拍张 “全家福”，然后把这张 “照片” 存到磁盘里。等 Redis 哪天 “失忆” 了（比如故障重启），就可以拿着这张 “照片” 恢复记忆。

触发方式：手动与自动的 “双响炮”

手动触发：
- save命令：这可是个 “霸道” 的主儿，它让 Redis 主进程亲自上阵拍 “照片”，但在拍的过程中，Redis 就像被施了定身术，所有命令都得乖乖等着，啥也干不了。
- bgsave命令：这个就聪明多了，它知道找个 “替身”（子进程）去拍 “照片”，主进程该干啥干啥，互不耽误，就像后台默默干活的 “社畜”。
自动触发：在redis.conf文件里，你可以给 RDB 设置 “自动拍照” 的条件。比如save 900 1，意思是 900 秒内要是有至少 1 个 key 被修改了，就得拍张 “照片”；要是写save ""，那就是直接 “封印” RDB，不让它拍了。

基本流程（bgsave 版）：“分身术” 的妙用

bgsave一开始会用 “分身术”（fork）从主进程里分出个子进程，子进程和主进程共享内存数据。然后子进程就开始 “拍照”（读取内存数据并写入 RDB 文件）。这里还用到了 copy - on - write 技术，主进程读数据的时候，就直接用共享内存；要是主进程要写数据，那就得先拷贝一份数据，再去写，生怕把要 “拍照” 的素材弄坏了。等子进程 “照片” 拍完，就用新 “照片” 替换旧 “照片”。

优缺点：“快” 与 “险” 的博弈

优点：“照片” 体积小（还能压缩），恢复数据的时候那叫一个快，就像看幻灯片似的，唰一下就好了。
缺点：两次 “拍照” 间隔时间长，这期间要是 Redis “倒霉” 了，中间写的数据可就丢了；而且 “fork” 子进程、压缩数据、写 RDB 文件这些活儿，都挺费时间，对 Redis 性能也有影响。

二、AOF：“记录流水账” 的慢性子

AOF，全称为 Append Only File，也就是追加文件。它可比 RDB 有耐心多了，Redis 每执行一个写命令，它都像个 “小秘书” 一样，把命令工工整整地记到 AOF 文件里，就跟写 “流水账” 日记似的。

开启与配置：“慢工出细活”

AOF 默认是关闭的，得修改redis.conf配置文件才能开启。你可以设置 AOF 文件名，比如appendfilename "appendonly.aof"。

至于命令记录频率，也有三种选择：

appendfsync always：每写一个命令，立马记到 AOF 文件里，可靠性是高，就跟实时直播似的，但 Redis 的性能可就被拖累了，跟背着个大包袱跑步似的。
appendfsync everysec：写命令先放到 AOF 缓冲区，每隔 1 秒再把缓冲区数据写到 AOF 文件里，这是默认方案，性能适中，最多也就丢 1 秒的数据，就像每天定时发朋友圈似的。
appendfsync no：写命令先放缓冲区，啥时候写到磁盘里，全看操作系统心情，性能是最好，但可靠性就差了，说不定丢好多数据，跟把日记交给别人保管似的，指不定啥时候就没了。