{ "topic": "redis-persistence", "type": "fill_blank", "schema_version": "1.0.0", "generated": "2026-09-07T00:00:00+08:00", "questions": [ { "id": "fb-001", "type": "fill_blank", "difficulty": 1, "tags": [ "Redis", "持久化", "AOF", "RDB" ], "question": "Redis 的 AOF 通过把每条____命令依次____到文件末尾,重启后按序____这些命令来恢复数据;Redis 的 RDB 则是把某时刻的____序列化成语义 sized 的全量快照文件。", "answer": [ "写", "追加", "重放", "键值状态" ], "answer_rule": "ordered", "explanation": "AOF 保存的是“命令”(逻辑增量),以追加方式写入,恢复时重放命令;RDB 保存的是“键值状态”(全量快照)。这个“追加命令 vs 状态快照”的对立是理解两种持久化的关键。", "source": null, "related": [] }, { "id": "fb-002", "type": "fill_blank", "difficulty": 1, "tags": [ "Redis", "持久化", "RDB" ], "question": "RDB 采用____(定时/每次写)方式做全量快照,因此文件____(更小/更大)、重载____(更快/更慢),但两次快照之间的数据在宕机后会____。", "answer": [ "定时", "更小", "更快", "丢失" ], "answer_rule": "ordered", "explanation": "RDB 定时全量快照:占用内存状态的极小二进制文件,恢复时直接载入状态而非逐命令重放,因此更小更快;代价是两次快照间隔内写入的数据在异常宕机时会丢失。", "source": null, "related": [] }, { "id": "fb-003", "type": "fill_blank", "difficulty": 2, "tags": [ "AOF", "AOF重写", "状态快照", "命令序列" ], "question": "AOF 重写(BGREWRITEAOF)的本质是把____序列重新生成为____描述,把命令流“压缩”成等价的键值状态;它丢弃的是被后续____覆盖的大量____命令。", "answer": [ "命令", "键值状态快照", "命令/写操作", "中间" ], "answer_rule": "ordered", "explanation": "重写的本质是“命令序列 → 状态快照”的等值转换:从当前内存状态出发生成重建所需的最小命令集,把被最终值覆盖的中间命令(如重复 SET、先增后删等)丢弃,从而压缩文件体积。注意四点顺序:命令、状态快照、中间命令。", "source": null, "related": [] }, { "id": "fb-004", "type": "fill_blank", "difficulty": 2, "tags": [ "AOF", "AOF重写" ], "question": "给定 AOF 命令序列:SET k 1;INCRBY k 5;SET k 9;DEL k;SET k 2。执行 AOF 重写后,恢复同样状态(k=2)的最小等价命令应为____(写出命令)。", "answer": [ "SET k 2" ], "answer_rule": "any", "explanation": "前 4 条命令产生的任何状态都被最后的 SET k 2 完全覆盖,因此只需保留最后这条 SET。答案等价写法如 `SET k 2` 即可。", "source": null, "related": [] }, { "id": "fb-005", "type": "fill_blank", "difficulty": 2, "tags": [ "AOF", "binlog", "追加日志", "重放" ], "question": "Redis 的 ____ 与 MySQL 的 ____ 都属于记录写操作并可重放的追加日志;但 binlog 支持丰富的位点控制,而 AOF 没有原生的时间切片点,要做定点重放需要手动____文件。", "answer": [ "AOF", "binlog", "截断" ], "answer_rule": "ordered", "explanation": "AOF 与 binlog 对应关系是“记录写操作并可重放”这一面;差别在于 binlog 具备 --start-position/--stop-position(精确)与 --start/--stop-datetime(近似)位点能力,AOF 则需人工截断 append 文件实现定点重放。", "source": null, "related": [] }, { "id": "fb-006", "type": "fill_blank", "difficulty": 3, "tags": [ "binlog", "重放" ], "question": "MySQL 基于 binlog 的 Point-In-Time Recovery(PITR)核心做法是:先用____恢复全量备份,再用 ____ 以 ____(精确)或 ____(近似)位点重放增量变更。", "answer": [ "全量备份/mysqldump", "mysqlbinlog", "--start-position/--stop-position", "--start-datetime" ], "answer_rule": "ordered", "explanation": "PITR 流程:先恢复最近的逻辑/物理全备,再回放备份之后的 binlog;精确恢复使用 mysqlbinlog 的 --start-position/--stop-position(字节位点),近似用 --start/--stop-datetime。因此顺序为:全量备份、mysqlbinlog、位置参数、datetime 参数。", "source": null, "related": [] }, { "id": "fb-007", "type": "fill_blank", "difficulty": 3, "tags": [ "redo log", "物理日志" ], "question": "InnoDB 的 redo log 记录的是对____(页面)层面所做的物理变更(页号、偏移、字节),属于____日志;AOF/ binlog 记录的是____层逻辑操作,属于____日志。", "answer": [ "物理页", "物理", "逻辑/命令/SQL/行变更", "逻辑" ], "answer_rule": "ordered", "explanation": "redo 面向物理页(页号+偏移+字节)描述最终状态变化,是物理日志;AOF 记录命令、binlog 记录 SQL/行变更,都在逻辑层,属逻辑日志。这是 redo 与 AOF/binlog 在“物理 vs 逻辑”层面的核心差异。", "source": null, "related": [] }, { "id": "fb-008", "type": "fill_blank", "difficulty": 3, "tags": [ "redo log", "环形缓冲", "追加日志" ], "question": "InnoDB redo log 使用____大小的____结构,旧页写入磁盘后对应记录即可被循环____,因此它天然不会无限膨胀,无需像 AOF 那样进行显式____。", "answer": [ "固定", "环形缓冲", "覆盖/复用", "重写/压缩" ], "answer_rule": "ordered", "explanation": "redo 固定大小 + 环形复用(旧日志可被覆盖)实现隐式防膨胀;AOF 需显式重写(BGREWRITEAOF)合并命令。四空分别对应:固定、环形缓冲、覆盖、重写。", "source": null, "related": [] }, { "id": "fb-009", "type": "fill_blank", "difficulty": 3, "tags": [ "AOF", "redo log", "AOF重写", "环形缓冲" ], "question": "AOF 通过____方式应对日志膨胀(命令序列重新生成成语义快照),而 redo log 通过环形缓冲____旧页来隐式控制大小;两者防止膨胀的____不一致性正是“显式重写合并 vs 隐式覆盖”的体现。", "answer": [ "重写/重写合并", "覆盖", "时机" ], "answer_rule": "ordered", "explanation": "AOF 日志会持续放大,需用户显式触发/策略配置自动触发的重写压缩;redo 则依靠环形覆盖机制在检查点后自动隐式回收。三空为:重写、覆盖、时机。", "source": null, "related": [] }, { "id": "fb-010", "type": "fill_blank", "difficulty": 4, "tags": [ "redo log", "undo log", "一致", "恢复" ], "question": "MySQL 崩溃恢复中,redo log 对所有____事务被脏页做前向____,undo log 对____事务做____,二者配合保证恢复后的持久性与一致性。", "answer": [ "已提交", "重做", "未提交", "回滚" ], "answer_rule": "ordered", "explanation": "崩溃恢复:已提交但落盘不全的事务用 redo 前向重做使其持久;未提交事务用 undo 回滚其部分写入。顺序为:已提交、重做、未提交、回滚。", "source": null, "related": [] } ] }