持久化介绍
Redis 是内存数据库，所有数据默认只存在于内存中。一旦服务器断电或进程意外退出，内存中的数据就会全部丢失。
持久化的目的：就是将内存中的数据定期保存到磁盘上，在 Redis 重启后可以从磁盘恢复数据，从而保证数据的安全性和可靠性。
Redis 持久化的两种核心方案
一、RDB（Redis Database Backup）：数据快照
1、核心原理：在指定的时间间隔内，将内存中的所有数据生成一个快照文件（.rdb）并保存到磁盘。
2、触发方式：
1）手动触发：
-
save：由 Redis 主进程执行，会阻塞所有客户端请求，直到快照完成。
-
bgsave：主进程 fork 一个子进程来执行快照，主进程继续处理请求，不阻塞。
2）自动触发 在 redis.conf 中配置，比如 save 60 10000 表示 60 秒内如果有 10000 个 Key 被修改，就自动执行 bgsave。
3、执行原理
bgsave 使用了 Copy-on-Write（写时复制） 技术。fork 出的子进程共享主进程的内存数据，当主进程执行写操作时，会复制一份受影响的数据副本进行修改，从而保证子进程能拿到一个一致的数据快照。
注：当主进程 fork() 出子进程时：
1）虚拟地址空间：子进程会复制一份主进程的虚拟地址空间，这意味着子进程看到的内存布局和主进程完全一样。
2）页表：子进程会复制主进程的页表
3）物理内存：父子进程的页表会指向同一块物理内存，实现了数据的 "共享"。
4、优缺点：
✅ ：文件体积小，恢复速度快，适合做冷备。
❌ ：两次快照之间的数据可能丢失，无法做到实时持久化。
二、 AOF（Append Only File）：命令日志
1、核心原理
将 Redis 执行的每一条写命令都记录到一个日志文件（.aof）中，重启时通过重新执行这些命令来恢复数据。
2、开启方式：
AOF默认是关闭的，需要在 redis.conf 中设置 appendonly yes来开启。
3、刷盘策略（通过 appendfsync 配置）：
-
always：每执行一条写命令就立即刷盘，数据最安全，但性能影响最大。
-
everysec：每秒刷盘一次，默认方案，性能和安全性的平衡，最多丢失 1 秒数据。
-
no：由操作系统决定何时刷盘，性能最好，但可靠性最差。
4、AOF 重写
AOF 文件会随着时间变得越来越大，因为它记录了所有历史命令。AOF会记录同一个key的多次操作，但只有最后一次写操作才有意义。通过bgrewriteaof 命令可以让AOF文件执行重写功能，用最少的命令达到和原文件一样的效果（比如将 set num 123 和 set num 666 合并为 set num 666），从而减小文件体积。
.5、优缺点：
✅ 优点：数据完整性更高，丢失数据最多 1 秒（默认策略）。
❌ 缺点：文件体积大，恢复速度慢。
RDB 与 AOF 的对比
| 特性 | RDB | AOF |
|---|---|---|
| 持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
| 数据完整性 | 不完整，两次备份之间会丢失 | 相对完整，取决于刷盘策略 |
| 文件大小 | 会有压缩，文件体积小 | 记录命令，文件体积很大 |
| 宕机恢复速度 | 很快 | 慢 |
| 系统资源占用 | 高，大量 CPU 和内存消耗 | 低，主要是磁盘 IO 资源（重写时占用高） |
| 适用场景 | 可以容忍数分钟的数据丢失，追求更快的启动速度 | 对数据安全性要求较高的场景 |
讨论
1、如何理解RDB定时对整个内存做快照，会导致不完整，两次备份之间会丢失？
===》
RDB 在指定规则下定时将内存全量数据写入磁盘。记录的是某一时刻的全量数据结果 ，而不是增量命令，所以两次 RDB 快照之间产生的所有新数据，只会保存在内存中，不会写入磁盘文件。如果在两次快照之间 Redis 发生宕机、断电，内存数据清空，这部分数据就会永久丢失。
也就是说数据不完整指的是redis宕机的情况，如果不宕机（ Redis 进程正常运行），两次备份之间的所有数据都安全地保存在内存里，随时可以读写。
2、 每个进程都有自己的页表；也有自己的虚拟空间，cpu访问的是进程的虚拟地址；进而再根据进程的页表找到目标物理地址； 我想问为什么要用"虚拟空间"这个概念，即cpu为什么不直接访问物理地址？
===》
1）直接访问物理地址的问题：如果所有程序都直接访问物理内存，那么一个恶意或有 bug 的程序可以随意读写其他程序甚至操作系统内核的数据，这会导致系统崩溃、数据泄露和恶意攻击。 2）虚拟地址空间的解决方案：每个进程都拥有一个独立的、从 0 开始的虚拟地址空间。这些虚拟地址会通过页表映射到物理地址，但不同进程的虚拟地址可以指向不同的物理地址，也可以指向同一块物理地址（用于进程间通信）。
效果：这就像给每个程序都分配了一个独立的 "沙箱"，它们无法直接看到或修改其他程序的内存，从而保证了系统的稳定性和安全性。
其他的有点我不论述了，反正这是一套非常优秀的解决方案，是现代操作系统能够稳定、高效运行的基石。
3、rgb数据快照之后，磁盘中存储的是一个个的快照文件吗？还是只有最新的快照文件？在哪里可以查看？
==》
Redis 默认情况下只会保留最新的一份 RDB 快照文件 。每次执行 bgsave 或自动触发快照时，新生成的 dump.rdb 文件会原子地替换掉旧的文件。
总结：本文介绍了两种redis持久化的方案，rdb和AOF；介绍了ROF的核心原理，触发方式；bgsave的原理；并讨论了os用虚拟地址的好处；以及ROF的优缺点（文件体积小，恢复速度快，两次开照之间的数据可能丢失）又讲了AOF核心原理，开启方式，刷盘策略，AOF重写；以及优缺点；并进行了RDB 与 AOF 的横向对比；