Redis持久化
Redis持久化的核心目标是确保数据安全，防止因进程意外退出而导致数据丢失。其基本思想是将数据同时保存在内存和硬盘中。
- 写操作：数据同时写入内存和硬盘。
- 读操作：直接读取内存中的数据，保证高性能。
- 数据恢复：当Redis重启时，利用硬盘中保存的数据来恢复内存中的数据状态。
- 代价：需要消耗额外的存储空间，因为同一份数据存储了两份。
Redis提供了两种主要的持久化机制：RDB（Redis Database） 和 AOF（Append Only File）。RDB可理解为定期备份，而AOF则是实时备份。
01.RDB
分为手动触发和自动触发。
1.1手动触发
1.1.1save命令
阻塞式执行，直到RDB过程完成。对于大数据量实例会造成长时间阻塞，不推荐使用。
1.1.2bgsave命令
后台异步执行。Redis主进程通过fork操作创建子进程，由子进程负责快照生成，主进程继续提供服务。阻塞仅发生在fork阶段，时间极短。
bgsave工作流程
1.2自动触发
通过在配置文件(redis.conf)中设置规则，让Redis在满足条件时自动执行bgsave。例如，配置“N秒内数据集至少有M个改动”时触发。
02.配置与文件
-
配置文件：通常位于/etc/redis/redis.conf。可通过 config get dir查找该文件。
-
-
dir /var/lib/redis：通过该命令＋路径指定RDB文件（及AOF文件）的工作目录。
-
dbfilename dump.rdb：指定RDB文件名。
-
save <seconds> <changes>：配置自动触发条件，如save 60 10000。
-
save ""：用于关闭RDB自动持久化。
-
2.1RDB文件
是一个压缩的二进制文件，不可直接编辑。Redis提供了redis-check-rdb工具（或redis-server –check-rdb）来校验其完整性。
有可能你的安装路径与之不符，可以通过下面命令查找find /usr -name "redis-*" 2>/dev/null。后面的操作是让输出更简洁。
这样我们就可以发现-rdb结尾的文件了，即rdb校验工具。
-
当执行生成rdb镜像 操作的时候，
1、会把要生成的快照数据，先保存至一个临时文件。当快照生成完毕
2、再删除之前的rdb文件
3、再把新生成的临时rdb文件改为刚刚的dump.rdb。
这样就保证了dump.rdb文件自始至终就只有一个
2.2RDB文件操作
使用命令：
-
连接到本地Redis服务器的6379端口
redis-cli -h 127.0.0.1 -p 6379
-
使用vi编辑器打开Redis的RDB数据文件(不建议使用vi直接查看或编辑dump.rdb文件)
vi 你的路径/dump.rdb
然后在redis客户端插入数据，再次查看rdb文件，没有变化。也就是说现在并未执行手动触发rdb，也没有达到自动触发rdb的条件。
因为自动触发RDB持久化的条件，可以在配置文件 /etc/redis/redis.conf 中通过 save 指令设置。
但是生成一次rdb快照的成本是一个比较高的成本，不能让这个操作太频繁。这也导致快照的数据和实时内存中的数据可能存在偏差。比如说在两次快照之间的时候，redis服务器挂了，就会导致在快照之间这个时间段的数据就丢失了，因为还并未写到磁盘。（AOF就是解决这种场景的有效方案）
2.3触发rdb场景
除了手动命令和配置触发，以下情况也会自动触发RDB生成：
- 执行shutdown命令正常关闭Redis时。
- 在主从复制场景中，主节点会自动生成RDB快照并发送给从节点。
2.4RDB优缺点
- 优点：
- 文件紧凑，适合备份、全量复制和灾难恢复。
- 数据恢复速度远快于AOF。
- 缺点：
- 无法做到实时/秒级持久化，两次快照之间的数据有丢失风险。
- bgsave的fork操作属于重量级操作，频繁执行成本高。
- 二进制格式可能存在不同版本的兼容性问题。
02.AOF持久化（实时命令日志）
AOF以独立日志的形式记录每次写命令，重启时重新执行这些命令来恢复数据，解决了数据持久化的实时性问题。
2.1开启AOF
在redis.conf中将appendonly配置项改为yes，并重启Redis生效。AOF文件默认保存在与RDB相同的工作目录下，文件名由appendfilename指定。
2.2工作流程
核心流程包括：命令追加、文件同步、文件重写、重启加载。
2.3 写入与同步策略（appendfsync）
策略通过appendfsync参数控制，是性能与安全性的权衡关键。
- always：每个写命令都同步写入硬盘（fsync）。数据最安全，但性能影响最大。
- everysec（默认）：先执行write写入系统缓冲区，再由后台线程每秒进行一次fsync同步。兼顾安全与性能，理论上最多丢失1秒数据。
- no：只执行write，由操作系统决定何时同步。性能最好，但数据丢失风险最高。
2.4 重写机制
为了解决AOF文件不断增大的问题，Redis引入AOF重写来压缩文件体积。
-
压缩原理：
- 丢弃进程内已超时的数据。
- 将多条命令合并为最终状态的一条命令。
- 删除无效的命令。
-
触发方式：
- 手动触发：执行bgrewriteaof命令。
- 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数自动判断。
-
重写流程（bgrewriteaof）：
- 主进程fork出子进程。
- 子进程基于当前内存数据，生成新的AOF文件（此过程不依赖旧AOF文件）。
- 主进程在此期间将新的写命令同时写入原有的AOF缓冲区和重写缓冲区（aof_rewrite_buf）。
- 子进程完成新AOF文件写入后，通知主进程。
- 主进程将重写缓冲区的内容追加到新的AOF文件中。
- 用新的AOF文件原子替换旧文件。
2.5混合持久化
为了解决AOF文件恢复速度慢的问题，Redis 4.0引入了混合持久化。
- 开启：通过配置aof-use-rdb-preamble yes（默认开启）。
- 原理：在AOF重写时，子进程将当前内存数据以RDB二进制格式写入新的AOF文件头部。之后主进程的写命令再以AOF文本格式追加到文件尾部。这样既利用了RDB的快速恢复特性，又保留了AOF的实时性。
- 文件内容：重写后的AOF文件是“RDB头部 + AOF尾部”的混合体。
总结：
- 当AOF和RDB同时开启时，Redis重启会优先使用AOF文件进行数据恢复，因为AOF通常数据更全。
- 数据恢复流程：Redis启动时，会检查是否启用了AOF。如果启用，则加载AOF文件（如果是混合格式，先加载RDB部分，再执行后续的AOF命令）；如果未启用AOF，则尝试加载RDB文件。
| 持久化方式 | 定时生成内存快照 | 记录每次写命令日志 |
| 数据完整性 | 可能丢失两次快照间的数据 | 根据策略不同，完整性更高（如每秒同步） |
| 恢复速度 | 快（二进制，直接载入） | 慢（需重放命令） |
| 文件大小 | 小（压缩二进制） | 大（文本命令日志，可重写压缩） |
| 对性能影响 | fork子进程时会有瞬时阻塞和内存消耗 | 主要在于文件同步策略的磁盘IO开销 |
| 应用场景 | 冷备、全量复制、快速恢复 | 对数据安全性要求高、可容忍轻微性能损失的场景 |
核心共同点：RDB和AOF都利用了fork子进程和操作系统的写时复制技术，尽可能减少对主进程处理请求的影响。
