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

【Redis】持久化机制

目录

    • 一、如何在 Redis 里持久化数据的?
      • 1. RDB(Redis DataBase)—— 内存的全量快照
      • 2. AOF(Append Only File)—— 命令的流水账日志
      • 3. 两者混合使用
    • 二、如何确认开启持久化
      • 1. 配置文件
      • 2. 状态验证与文件位置查看
        • ① 验证 AOF 是否成功开启
        • ② 验证混合持久化(Mixed Persistence)是否开启
        • ③ 查找持久化文件的最终保存路径
      • 3. 其它进阶修改
        • ① 灵活自定义 RDB 配置
        • ② 重启 Redis 服务令配置生效

一、如何在 Redis 里持久化数据的?

MySQL 追求安全:数据必须写进硬盘。硬盘哪怕断电,磁介质或闪存颗粒上的数据也不会消失。但代价是慢。

Redis 追求速度:数据全部塞进内存。CPU 读写内存的速度比硬盘快了成百上千倍。但代价是“断电即失”。

为了兼顾“内存的速度”和“硬盘的安全”,Redis 引入了持久化机制。它的核心逻辑是:在内存中飞速读写,在后台悄悄把数据同步到硬盘。

当 Redis 触发持久化时,它会对整个内存数据进行操作。

只要持久化在运行,你写入的任何数据,都会被存入硬盘。

Redis 持久化的两种不同的方案:

1. RDB(Redis DataBase)—— 内存的全量快照

RDB 的本质就是定时全量备份。

它是怎么工作的?
Redis 会根据你设定的时间周期(或者使用默认周期),在后台开启一个子进程。这个子进程会把当前内存里的所有数据变成一个二进制的压缩文件(默认叫dump.rdb)。

默认配置的致命盲区:
你刚装好 Redis 时,RDB 是默认开启的。它的规矩写在/etc/redis.conf配置文件里:

  • save 900 1:15 分钟内至少 1 个 key 改变,就触发备份。
  • save 300 10:5 分钟内至少 10 个 key 改变,就触发备份。
  • save 60 10000:1 分钟内至少 10000 个 key 改变,就触发备份。

为什么要重新配置它?
默认规矩太宽松了!假设你的虚拟机在 4 分钟内只被修改了 5 个 Key,它不会触发任何备份。如果此时突然停电,这 4 分钟内写入的所有数据彻底蒸发。

深度优缺点分析:

优势: 文件体积小,恢复速度快得惊人。重启时,Redis 直接把dump.rdb读进内存就完事了。

劣势: 丢数据概率高。两次快照之间的时间段,就是无保护的“裸奔期”。

2. AOF(Append Only File)—— 命令的流水账日志

AOF 的本质就是增量命令审计。

它是怎么工作的?
它是个极其勤快的秘书。它不关心内存里最终剩下了什么,它只记录你做过什么动作。你每敲一个写命令(比如SETHSETLPUSH),Redis 就会把这行命令转换成特定的文本格式,追加(Append)到硬盘的一个日志文件(默认叫appendonly.aof)的末尾。

默认状态:
默认是关闭的(appendonly no)。在真实生产环境中,我们必须手动把它改成appendonly yes

核心配置(三大刷盘策略):
开启 AOF 后,我们还要在配置文件里修改appendfsync参数,决定秘书多久把积攒的命令真正写进硬盘:

  • always(极度安全):每执行一条命令,立刻强制写硬盘。系统慢如蜗牛,硬盘寿命暴降。
  • no(极度不安全):执行完命令先放内存缓存里,什么时候写硬盘听 Linux 操作系统的。
  • everysec(黄金行业标准):每秒钟雷打不动写一次硬盘。哪怕断电,我们也只会丢失最近 1 秒钟内的数据。

深度优缺点分析:

超强优势: 极其安全,配合everysec策略,几乎做到了天衣无缝。

致命劣势:

  1. 文件巨大。你把一个数字自增了 10 万次,AOF 会老老实实记 10 万行INCR账本。
  2. 恢复极慢。重启时,Redis 必须把 AOF 日志里的所有命令从头到尾在内存里重演一遍。

3. 两者混合使用

RDB 快照:在指定时间间隔内(如 15 分钟至少 1 个 key 变化)将内存中的全部数据以二进制压缩文件(dump.rdb)保存到磁盘。恢复时直接加载文件,速度极快。缺点是如果两次快照之间发生宕机,未达到触发条件的新数据(哪怕已经改了多个 key 但时间间隔未到)就会永久丢失。

AOF 日志:记录每个写命令(如SETHSET)追加到日志文件(appendonly.aof),重启时逐条执行命令重建数据。可通过appendfsync配置数据安全性(如everysec最多丢一秒数据)。缺点是日志文件体积大、恢复速度慢(尤其写命令多时)。

两者弊端:RDB 可能丢较多数据,AOF 恢复慢且文件大。因此生产环境通常两者同时开启,并结合 Redis 4.0 引入的混合持久化来互补。

混合持久化是怎么做的?

从 Redis 4.0 开始,当同时开启 RDB 和 AOF 并启用aof-use-rdb-preamble(默认 yes)时,AOF 重写(BGREWRITEAOF)产生的文件不是纯 AOF 格式,而是RDB 快照 + 增量 AOF 命令

  1. 文件结构:AOF 文件开头是一份完整的 RDB 二进制快照(存储当前内存状态),快照之后是新写入的增量命令(以 AOF 文本格式追加)。
  2. 写入过程:AOF 重写时,Redis 会先 fork 子进程生成内存快照写入 RDB 部分,然后继续将重写期间的新命令记录到缓冲区,最后将缓冲区内容追加到 AOF 文件末尾(作为 AOF 部分)。
  3. 恢复过程:Redis 重启时,先读取 AOF 文件开头的 RDB 部分,瞬间恢复快照时的全部数据,然后再执行后续的 AOF 命令(这些命令很少,因此重放极快)。结果就是:既有 RDB 的快速恢复,又有 AOF 的高安全性(最多丢一秒数据)。

混合持久化的优势:AOF 文件比纯 AOF 小得多(RDB 部分压缩存储),恢复速度接近纯 RDB,数据安全性接近纯 AOF(最多丢一秒)。这也是目前生产环境最推荐的持久化方案。

二、如何确认开启持久化

在知道了 Redis 有这两种持久化的方式之后,就得知道怎么开启和配置它们了。

1. 配置文件

如果现在你在 Linux 中输入ps -ef | grep redis命令时,看到的是:redis-server *:6379,后面什么都没有,那就说明现在没有配置文件(如果输出类似/user/bin/……redis.conf,那么这就是配置文件的路径,直接进去改参数就行)。

既然没有,就可以在网上下载或者自己手动配置。这里做手动配置的情况。

  1. 创建正规的配置目录与数据目录

    sudomkdir-p/etc/redis# 存放配置文件sudomkdir-p/var/lib/redis# 存放持久化数据(dump.rdb 和 appendonly.aof)
  2. 手动创建并编辑 redis.conf 文件

    sudovi/etc/redis/redis.conf

    进入空白界面后,按下键盘上的i键进入编辑模式(看到左下角出现-- INSERT --),然后把下面这段企业标准配置复制粘贴(或照着敲)进去:

    # ==================== 基础运行配置 ====================# 1. 允许 Redis 在后台默默运行,不霸占你的终端窗口daemonizeyes# 2. 绑定 IP,允许所有网络连接(方便以后用外部工具连接)bind0.0.0.0# 3. 关闭保护模式,配合上面的 bind 使用protected-mode no# 4. 给你的 Redis 设定访问密码requirepass123456# ==================== 持久化核心配置 ====================# 5. 指定数据和持久化文件的存放目录(专属储物间)dir/var/lib/redis# 6. 开启安全的 AOF 持久化,并设定黄金刷盘策略(每秒记一次日记)appendonlyyesappendfsync everysec# 7. 开启混合持久化大招(结合 RDB 的快与 AOF 的安全)aof-use-rdb-preambleyes

    检查无误后,按下Esc键,输入:wq回车,保存并退出。

  3. 杀死正在裸奔的旧 Redis

    sudopkillredis-server
  4. 带着崭新的配置文件启动

    sudoredis-server /etc/redis/redis.conf

2. 状态验证与文件位置查看

修改完配置文件并重启后,我们如何验证持久化是否真正生效?这些文件又存放在哪里?请按以下步骤逐一排查。

① 验证 AOF 是否成功开启

连入redis-cli后,执行以下命令:

CONFIG GET appendonly
  • 如何判断:如果返回"yes",说明 AOF 持久化已成功开启。
② 验证混合持久化(Mixed Persistence)是否开启

redis-cli中,输入以下命令查看混合持久化开关:

CONFIG GET aof-use-rdb-preamble
  • 如何判断:如果返回"yes",说明混合持久化大招已经就位。当后续触发 AOF 重写时,文件就会自动转换为“RDB 二进制开头 + AOF 文本结尾”的混合格式。
③ 查找持久化文件的最终保存路径

想要知道 AOF 和 RDB 文件在硬盘的哪个文件夹,可以分两步走:

  1. 获取 Redis 数据基础根目录:
    redis-cli中输入:
CONFIG GETdir

Redis 会返回一个绝对路径(例如:"/var/lib/redis""/root"),这就是持久化数据的“大本营”。
2.定位 AOF 专属子目录(Redis 7.0 及以上版本特性):
在 Redis 7.0+ 版本中,官方引入了多文件 AOF 机制,AOF 文件不再直接堆在根目录下,而是存放在一个名为appendonlydir的子目录中。
你可以使用以下命令查看该目录的名字:

CONFIG GET appenddir

通常默认返回"appendonlydir"

💡 最终文件绝对路径总结:

  • RDB 快照文件:直接存放在根目录下,即/var/lib/redis/dump.rdb
  • AOF 文件夹:存放在根目录的子目录下,路径为/var/lib/redis/appendonlydir/。进入该文件夹后,你会看到以.manifest.base.rdb.incr.aof结尾的一组文件。

3. 其它进阶修改

① 灵活自定义 RDB 配置

除了 AOF,你还可以根据业务的并发量,在配置文件中自定义 RDB 的快照频率。其格式为save <秒数> <修改次数>

  • 自定义策略示例:
save 1200 100

这行配置意味着:“在 1200 秒(20 分钟)内,如果至少有 100 个 Key 被修改,就自动触发一次 RDB 快照”。

  • 彻底禁用 RDB 自动保存:如果你只想用 AOF,不希望 Redis 自动拍 RDB 快照,可以在配置文件中加入:
save ""
  • 手动强制触发 RDB 快照:无需等待定时规则,你可以在redis-cli中随时手动输入以下命令,让 Redis 在后台立刻进行一次全量快照:
BGSAVE
② 重启 Redis 服务令配置生效

请务必记住,任何配置文件的修改,都必须重启 Redis 服务才能生效。在 CentOS 7 / Ubuntu 系统中,通常使用以下命令:

  • 如果使用 systemd 管理服务(推荐):
sudosystemctl restart redis# 注:部分系统服务名叫 redis-server,命令为:sudo systemctl restart redis-server
  • 如果是手动带路径启动的:
redis-cli-a<你的密码>shutdownredis-server /etc/redis/redis.conf
http://www.cnnetsun.cn/news/2668314.html

相关文章:

  • 单片机时钟电路设计全解析
  • 从Google Duplex看对话式AI:技术原理、伦理挑战与工程实践
  • AR眼镜设计实战:如何将Lumerical光栅模型导入Ansys Speos进行系统级杂散光分析
  • 从三调到日常:一个ArcGIS Pro面积平差工具包的迭代与封装思路
  • 告别硬边UI!用UE4材质和UMG轻松实现CSS级圆角按钮(附完整材质蓝图)
  • 华为云Stack网络排障实战:从OVS流表看懂VXLAN流量转发(附抓包分析)
  • 终极窗口分辨率控制指南:如何用SRWE突破游戏窗口限制
  • Flutter UI2CODE:从Figma设计稿到可运行代码的自动化实践
  • dSPACE安装避坑大全:从系统准备到MicroAutoBox II注册,我踩过的雷你别再踩
  • Unity3D项目突然报WakeUp为空?别慌,试试这个重启大法(附详细步骤)
  • AI助手最后一公里:从技术能力到实用价值的跨越策略
  • C++lambda表达式与函数式编程
  • 别再折腾了!Ubuntu 22.04下CLion 2022.2.5保姆级安装与性能调优全攻略
  • 别再傻傻分不清!DDR4/5与LPDDR4/5的ECC方案到底有啥不同?
  • 团队协作必备:如何为你的Aurix TriCore项目搭建稳定的Tasking浮动许可证环境
  • CSS渐变背景从入门到‘会玩’:linear-gradient和radial-gradient的10个隐藏技巧与常见坑点
  • PIM架构:突破内存墙的计算革命与优化实践
  • 别再只调学习率了!深入浅出图解目标检测四大IOU Loss的演进与坑点
  • 别再只用TileMap了!用Godot4.2手搓一个轻量级2D网格节点(附完整源码)
  • Unity VR开发避坑:用XR Interaction Toolkit 2.3.2搞定角色移动与楼梯碰撞(附自定义CharacterController脚本)
  • Lindy自动化部署全链路解析:从零配置到生产级合约监控的7个关键节点
  • Keil C51 V6汇编错误A14解析与修复方案
  • 3D高斯泼溅SLAM技术优化与AGS架构解析
  • TaiBai芯片:脑启发计算与脉冲神经网络硬件革新
  • 基于小程序的网上摄影工作室的开发与实现毕业设计源码
  • 低成本DIY智能音乐盒:基于ESP32-S3和LVGL的3.5寸屏UI实战(附源码)
  • 别再死记硬背了!一文搞懂BEV算法家族:从LSS到BEVFormer,哪个更适合你的自动驾驶项目?
  • Vivado IP核的ModelSim仿真库:一次编译,多次复用(附2018.3版本库路径配置详解)
  • 告别迷茫!5分钟搞定Node.js项目中的SM2/SM3/SM4国密算法集成(sm-crypto保姆级教程)
  • 别再死记硬背了!用Arduino/ESP32玩转W25Q16和GD25Q128 SPI Flash(附完整代码)