一、持久化
redis 虽然是个内存数据库，但是 redis 支持RDB 和 AOF 两种持久化机制， 将数据写往磁盘，可以有效的避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。
二、Redis 支持RDB 和 AOF 两种持久化机制
- RDB : 快照模式
- AOF：追加模式
三、RDB（Redis DataBase） - 内存快照模式
1、给哪些内存数据做快照？
- 全量快照：给所有的数据做快照
2、当快照的量越来越大，RDB 文件的生成是否会阻塞主线程？
- 手动机制
- 命令：
- sava：会阻塞线程（生产上时不允许用save命令的）
- bgsave：创建子进程，该子进程专门写入RDB文件
- bgsave不阻塞原因： 写时复制机制
自动机制
- RDB的自动化配置：
#当用户设置了多个save的选择配置，只要其中任一条满足，Redis都会触发一次bgsave操作 save 900 1 save 300 10 save 60 10000 #以上配置的含义： # 900秒之内发生至少 1 次写操作 # 300秒之内发生至少 10 次写操作 # 60秒之内发生至少 10000 次写操作 # 以上3种，只要满足任一条件，均会触发bgsave- save "" ：这样的配置会导致redis不做持久化。 Redis就是一个纯内存中间件
- 这里不是说SAVE 命令要注意区分
shutdown命令
- shutdown命令用于安全地停止服务器
- 在RDB持久化中的核心逻辑是：在关闭服务器前，根据配置触发一次RDB快照的生成，确保数据持久化到磁盘后再终止进程。
- shutdown 命令的默认行为
- 触发RDB持久化：
- 默认情况下，执行 SHUTDOWN 时，Redis会尝试将当前内存中的数据同步保存到RDB文件（即使未配置自动RDB策略）。
- 这相当于隐式执行SAVE命令（阻塞主进程，直到RDB文件生成完毕），确保关闭前数据持久化。
- 对比直接终止进程
- 如果直接通过 kill 命令终止Redis进程，不会触发 RDB 或 AOF 持久化，可能导致数据丢失。而 SHUTDOWN 保证了关闭前的数据安全。
- 通过参数控制默认行为
- shutdown 支持两个可选参数，覆盖默认行为
- SHUTDOWN SAVE :
- 强制在关闭前执行RDB持久化（即使未配置自动保存策略）。
- SHUTDOWN NOSAVE： （慎用）
- 跳过持久化，直接关闭服务器，可能导致数据丢失
- 从节点执行全量赋值操作，主节点会自动执行bgsave生成一个RDB文件发给从节点。
3、配置 rdbcompression : yes
- 开启相当于是开启了LZF压缩算法。
- 优点：该算法会大大压缩导出的文件大小，节约磁盘
- 缺点：消耗CPU资源
- 默认会开启（原因： 优点 > 缺点）
4、若怀疑 dump.rdb 文件损坏如何校验呢？
- dump.rdb 文件
- dump.rdb 文件是RDB持久化的核心文件，它保存了Redis在某个时间点的内存数据快照。
- 在Redis重启时，自动加载 dump.rdb 文件中的数据到内存，恢复至最后一次快照的状态
- redis提供了一个 redis-check-rdb.exe 程序
5、快照时的数据能修改吗？（save与bgsave的介绍）
- 结论：bgsave可以修改；save不能修改
- 具体行为取决于快照生成的方式（同步的SAVE 或 异步的BGSAVE）
- SAVE命令 - 同步快照 - 阻塞主进程
- 命令由主进程直接生成快照，期间Redis完全停止处理任何请求（包括读写操作）
- 数据修改：在SAVE执行期间，客户端的所有写操作会被阻塞，因此数据无法被修改，直到快照生成完毕。
- 生产环境不适用
- BGSAVE命令 - 异步快照 - 非阻塞主进程
- 通过 fork子进程 生成快照，主进程继续正常处理客户端请求
- 数据修改：在BGSAVE执行期间，客户端可以 正常读写，修改操作会被主进程处理。
- 快照一致性：子进程保存的是fork时刻的内存数据快照，后续主进程的操作不会影响当前快照。
- 关键机制 - 写时赋值（Copy-On-Write, COW)
- 原理：
- 当执行 BGSAVE 时，Redis主进程fork出一个子进程，子进程与主进程 共享相同的内存数据。
- 如果主进程在此期间修改数据，操作系统会为被修改的内存页创建副本，子进程继续读取原始内存页。
- 快照数据：子进程始终看到fork时的数据状态，因此生成的RDB文件是某一时刻的一致性快照。
- 内存影响：
- 若主进程频繁修改数据，COW机制会导致 内存占用上升（赋值的内存页增多）。极端情况下，可能会触发OOM。
6、rdb时若redis宕机了，会导致数据丢失
- 减少快照时间
- 这样会导致性能变差，因为保存的是全量数据。RDB 的时长10秒设置成5秒回导致前一个RDB没做完下一个又开始了
- fork命令会阻塞的，所以不能频繁的fork。
四、AOF（append only file）-- 追加模式
1、什么是AOF
- AOF 是一个日志文件，Redis的每个命令都将以AOF格式写入AOF文件，AOF日志仅记录修改内存的指令。
- AOF日志文件的命令存储，是在命令执行成功后。
- 当需要做恢复时，直接导入AOF文件以执行其中的记录，并且记录是实时的。
2、如何开启AOF持久化
- 配置文件
- appendonly参数 配置为 yes 来启动AOF持久化。
- appendfilename参数 配置是保存的文件名
3、（重点）AOF 持久化实现
- AOF的工作流程主要是4个部分：命令写入(append) -> 文件同步(sync) -> 文件重写(rewrite) -> 重启加载(load)
- 命令写入（append）
- AOF命令写入是以RESP文本协议。
- 【问题】为什么要采用RESP文本协议？
- 文本协议具有很高的兼容性。
- 开启AOF后，所有命令都包含追加操作。直接采用协议格式，避免二次开销，文本协议具有可读性，方便直接修改和处理