岳阳市规划局建设工程公示网站wordpress指定页面连接数据库连接
目录
一、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：写命令先放缓冲区，啥时候写到磁盘里，全看操作系统心情，性能是最好，但可靠性就差了，说不定丢好多数据，跟把日记交给别人保管似的，指不定啥时候就没了。
优缺点：“全” 与 “大” 的权衡
- 优点：数据完整性相对高，就看你选的刷盘策略了；主要是磁盘 IO 资源消耗，对 Redis 性能影响小。
- 缺点：AOF 文件会越来越大，跟个大胖子似的；恢复数据时得把所有写命令重放一遍，速度慢，就像看长篇小说似的，得慢慢翻。
三、RDB 和 AOF 的 “相爱相杀”
四、“强强联合” 才是王道
在实际开发中，如果对数据安全性要求高，那就得让 RDB 和 AOF “握手言和”，一起干活。Redis 启动时，先加载 RDB 文件，快速恢复大部分数据，就像先搭好骨架；然后再通过 AOF 文件，把 RDB 生成之后的写命令重放一遍，把细节补充完整，这样数据的完整性和一致性就都有保障啦。
好啦，关于 Redis 持久化的 RDB 和 AOF 就聊到这儿啦，希望大家看完能对它们有更有趣的认识，咱们下次再聊其他 Redis 的 “小秘密”～