examination/topics/database/redis-persistence/fill_blank.json

{
  "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": []
    }
  ]
}