【Redis分布式缓存实战】第5章 Redis两大持久化机制深度拆解

RDB持久化：快照原理、触发机制、优缺点、生产适用场景

RDB（Redis Database Backup）是 Redis默认的全量快照持久化机制，核心是将 Redis 内存中的所有数据一次性生成二进制快照文件（dump.rdb）保存到磁盘，实现数据落盘持久化。

一、RDB 快照核心原理

RDB 的底层依赖Linux fork () 系统调用+写时复制（Copy-On-Write, COW）技术，这是理解 RDB 的核心：

1. fork 子进程触发快照时，Redis 主进程通过fork()创建一个子进程，fork 瞬间子进程与主进程完全共享内存（不复制真实数据，速度极快）。
2. 子进程生成快照子进程独立遍历内存所有数据，将其序列化为紧凑的二进制dump.rdb文件，写入磁盘。
3. 写时复制（COW）保证数据一致性快照期间，主进程正常处理客户端读写：

1. 若主进程修改某块内存数据，会将该内存页复制一份新副本；
2. 主进程操作新内存页，子进程始终使用fork 瞬间的旧内存页生成快照；
3. 最终 RDB 文件是fork 时刻的完整内存数据，不受后续修改影响。

1. 原子替换文件子进程完成写入后，原子替换旧的 RDB 文件，避免文件损坏。

核心优势：RDB 持久化全程由子进程完成磁盘 IO，主进程几乎无性能损耗。

二、RDB 触发机制

分为自动触发、手动触发、隐式触发三类，生产环境仅推荐非阻塞的后台触发。

自动触发（配置文件控制）

通过​​redis.conf​​的​​save​​参数配置，满足「时间 + 修改次数」条件即自动执行​​bgsave​​：

conf

# Redis默认配置（满足任意一条触发） save 3600 1 # 1小时内至少1个key修改 save 300 100 # 5分钟内至少100个key修改 save 60 10000 # 1分钟内至少10000个key修改

• 注释所有save行 = 关闭自动 RDB；
• 触发方式为后台异步，不阻塞主进程。

手动触发

表格

隐式触发（Redis 自动执行）

• 执行FLUSHALL：生成空 RDB 文件；
• 主从复制初始化：主节点自动生成 RDB 发送给从节点；
• 执行SHUTDOWN：正常关闭时自动执行bgsave；
• Redis 重启：加载本地dump.rdb恢复数据。

三、RDB 优缺点

✅ 优点

1. 性能损耗极低持久化由子进程完成，主进程仅 fork 时有瞬时开销，不影响业务读写。
2. 备份 / 恢复速度极快二进制紧凑文件，全量数据加载速度远快于 AOF，适合大数据量快速恢复。
3. 文件体积小压缩存储数据，比 AOF 日志文件小得多，便于传输、归档、冷备。
4. 主从复制的基石Redis 主从架构的全量数据同步必须依赖 RDB 文件。

❌ 缺点

1. 数据丢失风险（最大短板）RDB 是定时全量快照，两次快照之间宕机，这段时间的所有数据会完全丢失。
2. fork 存在瞬时阻塞内存越大，fork 耗时越长（大内存实例可能毫秒～秒级阻塞），影响业务响应。
3. 写时复制内存开销快照期间修改数据会复制内存页，内存占用临时增加（极端情况接近翻倍）。
4. 版本兼容性差不同 Redis 版本的 RDB 格式可能不兼容，跨版本恢复易失败。

四、生产环境适用场景

RDB适合对数据丢失容忍度较高、追求快速恢复的场景；核心业务严禁单独使用，推荐搭配 AOF（混合持久化）。

纯缓存场景（核心适用）

• 场景：热点数据缓存、商品列表、接口缓存、页面缓存；
• 原因：缓存数据丢失可从数据库重新加载，无需强一致性，RDB 性能最优。

临时 / 会话数据存储

• 场景：用户登录会话、购物车、短信验证码、临时统计数据；
• 原因：数据丢失后用户仅需重新操作，容忍度高。

大规模数据快速灾难恢复

• 场景：TB 级 Redis 实例、大数据业务、日志统计；
• 原因：RDB 恢复速度远超 AOF，能快速恢复服务，减少停机时间。

定期冷备 / 数据归档

• 场景：每日 / 每周定时备份 Redis 数据；
• 原因：RDB 单文件、体积小，便于存储到云端 / 磁盘，长期归档。

主从 / 集群初始化同步

• 场景：主从架构、哨兵集群、Redis Cluster；
• 原因：主从全量同步必须用 RDB 传输全量数据，是集群必备机制。

Redis 4.0+ 混合持久化（生产最佳实践）

• 配置：aof-use-rdb-preamble yes；
• 原理：AOF 文件开头用 RDB 全量快照，后续追加 AOF 增量日志；
• 优势：兼顾 RDB 的恢复速度+ AOF 的数据安全性。

五、生产使用禁忌

1. 绝对禁用SAVE命令，仅使用BGSAVE；
2. 大内存实例（>10G）降低自动 RDB 频率，减少 fork 阻塞；
3. 金融、支付等核心强一致业务，禁止单独使用 RDB；
4. 定期校验 RDB 文件完整性，避免文件损坏。

总结

1. RDB 定位：全量快照持久化，快、小、性能高，但会丢数据；
2. 核心原理：fork 子进程 + 写时复制，主进程无 IO 阻塞；
3. 生产用法：缓存 / 临时数据单独用 RDB，核心业务用RDB+AOF 混合持久化；
4. 关键禁忌：禁用SAVE，大内存避免频繁快照。

AOF持久化：日志重写机制、刷盘策略、数据恢复流程

AOF（Append Only File）是 Redis 另一种持久化机制，以日志形式记录所有写命令（只追加、不修改），数据恢复时通过重放日志命令还原数据，完美解决 RDB 快照的数据丢失风险。

本文聚焦你需要的三大核心：刷盘策略、日志重写机制、数据恢复流程，结合生产实践讲解。

一、AOF 刷盘策略（fsync 核心）

AOF 的工作流程：写命令 → 写入内存缓冲区（aof_buf）→刷盘（fsync）落盘。刷盘策略直接决定数据安全性和Redis 性能，是 AOF 最核心的配置，通过 ​​appendfsync​​ 参数控制，共 3 种：

表格

核心总结

生产环境固定使用​​everysec​​，是数据安全和性能的最优平衡点。

二、AOF 日志重写机制（AOF Rewrite）

为什么需要重写？

AOF 是只追加日志，随着业务运行，文件会无限膨胀（比如反复修改同一个 key，会记录 N 条冗余命令）：

plaintext

# 冗余命令示例 set name zhangsan set name lisi hset user age 20 hset user age 21 del name

这些命令最终只保留 ​​hset user age 21​​，大量冗余命令会导致：

• AOF 文件过大，占用磁盘；
• 数据恢复极慢（重放冗余命令）；
• 刷盘 IO 压力剧增。

AOF 重写：将内存中的最终数据，转换为最小化的写命令集，生成新的 AOF 文件，替换旧文件，彻底解决文件膨胀问题。

重写核心原理

1. 不读取旧 AOF 文件：直接读取 Redis 内存最新数据，生成最简命令（无冗余）；
2. fork 子进程 + 写时复制（COW）：和 RDB 一致，重写由子进程完成，主进程无磁盘 IO 阻塞；
3. 双缓冲区保证数据一致性：重写期间，主进程新写命令会同步写入两个缓冲区，避免数据丢失。

完整重写流程（生产必懂）

1. 触发重写：满足自动配置 / 手动命令后，主进程 fork 子进程；
2. 子进程写新 AOF：子进程遍历内存数据，生成最小命令集，写入临时 AOF 文件；
3. 主进程双写缓冲：

1. 新写命令 → 写入aof_buf（原有刷盘逻辑）；
2. 新写命令 → 写入aof_rewrite_buf（重写专用缓冲区）；

1. 子进程完成：子进程写完临时文件，通知主进程；
2. 合并增量命令：主进程将aof_rewrite_buf中的命令追加到临时文件；
3. 原子替换：用临时文件原子替换旧 AOF 文件，重写完成。

触发机制

① 自动触发（配置文件）

conf

# AOF文件体积比上次重写后增长100%，触发重写 auto-aof-rewrite-percentage 100 # AOF文件最小达到64MB才触发重写（避免小文件频繁重写） auto-aof-rewrite-min-size 64mb

② 手动触发（命令）

bash

运行

BGREWRITEAOF # 后台异步重写，不阻塞主进程（生产推荐）

三、AOF 数据恢复流程

Redis 启动时，优先加载 AOF 文件（开启 AOF 后），恢复流程分两种：纯 AOF 恢复、混合持久化恢复（Redis 4.0+ 生产标准）。

前置条件

1. 开启 AOF：appendonly yes；
2. AOF 文件完好（appendonly.aof）。

流程 1：纯 AOF 恢复（老式方案）

1. 启动 Redis：检测到appendonly yes，优先加载 AOF 文件；
2. 文件校验：Redis 校验 AOF 文件完整性，若损坏则启动失败；
3. 命令重放：逐行读取 AOF 日志中的写命令，在内存中执行；
4. 恢复完成：所有命令执行完毕，内存数据还原，对外提供服务。

流程 2：混合持久化恢复（Redis 4.0+ 生产最优）

生产环境必须开启混合持久化：​​aof-use-rdb-preamble yes​​原理：AOF 文件 =RDB 全量快照（前半段） + AOF 增量命令（后半段）恢复流程：

1. 启动 Redis，加载 AOF 文件；
2. 快速加载 RDB 部分：先读取文件开头的 RDB 全量数据，瞬间恢复大部分数据；
3. 重放 AOF 增量：再执行后半段的 AOF 增量写命令，补全最新数据；
4. 恢复完成，服务上线。

✅ 优势：兼顾RDB 的恢复速度+AOF 的数据安全性。

异常处理：AOF 文件损坏修复

若 AOF 文件因宕机损坏，Redis 无法启动，使用官方工具修复：

bash

运行

# 修复AOF文件（会自动截断损坏的末尾数据） redis-check-aof --fix appendonly.aof

修复后重启 Redis 即可恢复数据。

四、生产环境核心配置（汇总）

conf

# 1. 开启AOF持久化（默认关闭） appendonly yes # 2. AOF文件名 appendfilename "appendonly.aof" # 3. 刷盘策略（生产固定配置） appendfsync everysec # 4. AOF重写配置 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 5. 开启混合持久化（必须开启！） aof-use-rdb-preamble yes

总结

1. 刷盘策略：生产用everysec，每秒刷盘，最多丢 1 秒数据，性能均衡；
2. 日志重写：解决 AOF 文件膨胀，fork 子进程 + 双缓冲区保证安全，不阻塞主进程；
3. 数据恢复：优先 AOF，4.0 + 用混合持久化（RDB+AOF），恢复最快、最安全；
4. 核心定位：AOF 比 RDB 数据更安全，RDB 比 AOF 恢复更快，生产环境两者同时开启。

RDB+AOF混合持久化原理与企业级最佳配置

Redis 4.0+ 推出的 RDB+AOF 混合持久化，是目前企业生产环境唯一推荐的持久化方案。它完美结合了 RDB 恢复快、文件小的优点，与 AOF 数据丢失少的优点，彻底解决了纯 RDB 和纯 AOF 的短板。

本文会从核心原理、优缺点、企业级完整配置、运维最佳实践四个维度，给你最实用的落地方案。

一、前置基础：纯 RDB vs 纯 AOF（快速铺垫）

先明确两种原生持久化的优缺点，才能理解混合模式的设计初衷：

表格

核心痛点：

• 纯 RDB：丢数据风险高，不适合核心业务；
• 纯 AOF：恢复极慢，文件巨大，高并发下 IO 压力大。

二、RDB+AOF 混合持久化核心原理

核心定义

混合持久化仅依赖 AOF 机制，是对 AOF 重写功能的优化：开启后，AOF 文件 = 前半段 RDB 全量快照 + 后半段 AOF 增量命令。

触发条件

1. Redis 版本 ≥ 4.0（企业推荐 5.0+/6.0+）；
2. 开启 AOF 持久化（appendonly yes）；
3. 开启混合开关（aof-use-rdb-preamble yes，默认开启）。

工作流程（关键）

（1）正常写入

主线程执行的写命令，以纯 AOF 格式追加到 AOF 文件末尾。

（2）AOF 重写触发（自动 / 手动）

当 AOF 文件达到阈值（大小 / 比例），Redis fork 子进程执行重写：

1. 子进程将当前内存所有数据以 RDB 格式写入新 AOF 文件（全量）；
2. 主进程缓存重写期间的所有新命令；
3. 子进程写完 RDB 后，将缓存的增量命令以 AOF 格式追加到文件末尾；
4. 用新 AOF 文件替换旧文件。

（3）重启恢复

Redis 启动时：

1. 优先加载 AOF 文件；
2. 识别文件开头为 RDB 格式，快速加载全量 RDB 数据；
3. 再逐行执行后半段 AOF 增量命令，补全最新数据。

优缺点总结

✅优点（企业级核心价值）

1. 恢复速度：接近 RDB，远快于纯 AOF；
2. 数据安全：接近 AOF，最多丢失 1 秒数据；
3. 文件体积：比纯 AOF 小 50%+，IO 开销更低；
4. 性能：无额外性能损耗，兼容高并发场景。

❌缺点

1. 兼容性：仅 Redis 4.0+ 支持；
2. 可读性：AOF 文件前半段是二进制 RDB，无法手动编辑；
3. 调试：比纯 AOF 日志更难排查问题。

三、企业级最佳配置（直接复制可用）

这是生产环境标准配置，兼顾性能、数据安全、稳定性，适配电商、金融、缓存等绝大多数场景。

完整配置片段（redis.conf）

ini

# ==================== 混合持久化核心配置 ====================# 1. 必须开启AOF（混合持久化基于AOF实现） appendonly yes # 2. 开启RDB+AOF混合模式（Redis4.0+默认yes，强制开启） aof-use-rdb-preamble yes # 3. AOF刷盘策略：企业级标准配置# everysec：每秒刷盘，平衡性能+安全（推荐）# always：每次命令刷盘，最安全但性能极差（禁止用于高并发）# no：操作系统控制刷盘，性能最好但丢数据多（禁止用于核心业务） appendfsync everysec # 4. AOF重写触发阈值（避免频繁重写） auto-aof-rewrite-percentage 100 # AOF文件比上次重写后大100%触发 auto-aof-rewrite-min-size 128mb # 最小128MB才触发（避免小文件频繁重写） # 5. 关键优化：重写时不阻塞fsync（企业必须开启）# 防止AOF重写时磁盘IO阻塞主线程，导致Redis卡顿 no-appendfsync-on-rewrite yes # 6. AOF异常自愈：重启时自动截断损坏的AOF文件 aof-load-truncated yes # ==================== RDB辅助配置 ====================# 关闭主动RDB快照（混合模式无需手动RDB，避免fork阻塞性能） save "" # 若需要冷备，可保留低频率快照（1小时1次）# save 3600 1# ==================== 存储配置 ====================# 持久化文件目录【必须挂载SSD】 dir /data/redis

分场景定制配置

场景 1：核心业务（金融、支付、订单）→ 数据安全第一

ini

appendfsync everysec auto-aof-rewrite-min-size 256mb # 降低重写频率 no-appendfsync-on-rewrite yes

场景 2：缓存业务（会话、商品缓存）→ 性能第一

ini

appendfsync everysec # 仍推荐，比no更安全 auto-aof-rewrite-percentage 200 save "" # 完全关闭手动RDB

场景 3：容灾备份（异地多活）

• 每日自动执行BGSAVE生成 RDB 全量备份；
• AOF 文件实时同步到异地存储；
• 从库单独开启持久化，主库专注提供服务。

四、企业级运维最佳实践

存储强制要求

持久化文件必须存放在 SSD 云盘：

• AOF fsync 刷盘、AOF 重写、RDB 生成都是高 IO 操作；
• 机械盘会直接导致 Redis 卡顿、超时。

内存优化（避坑关键）

Redis 内存使用 ≤ 物理内存的50%：

• 持久化时 fork 子进程会触发Copy-On-Write，内存会临时翻倍；
• 内存过高会导致 fork 阻塞、OOM 杀进程。

核心监控指标

必须监控以下指标，避免持久化故障：

1. ​​fork​​ 耗时：正常 < 1ms，超过 10ms 会阻塞主线程；
2. ​​aof_delayed_fsync​​：AOF 刷盘延迟次数；
3. 磁盘使用率：AOF/RDB 文件占用；
4. AOF 重写频率：避免每分钟重写。

备份策略

1. 每日：自动拷贝 RDB 快照 + AOF 文件到异地对象存储；
2. 每周：全量归档备份，保留 30 天；
3. 恢复演练：每月测试一次备份恢复，确保可用。

禁止操作

❌ 不要用 ​​appendfsync always​​：高并发下性能暴跌 90%；❌ 不要关闭 ​​no-appendfsync-on-rewrite​​：会导致主线程阻塞；❌ 不要用 Redis 4.0 以下版本：不支持混合持久化；❌ 不要将持久化文件存放在系统盘：容易占满磁盘导致服务宕机。

总结

1. 混合持久化是 Redis 企业级标配：Redis 4.0+ 必须开启，替代纯 RDB/AOF；
2. 核心配置三行代码：appendonly yes+aof-use-rdb-preamble yes+appendfsync everysec；
3. 运维核心：SSD 存储、控制内存使用率、定期备份、监控 fork/IO 指标。

这套方案能保证：最多丢失 1 秒数据、秒级恢复、高并发无性能损耗，完全满足企业生产要求。

持久化常见问题：数据丢失、重启耗时、磁盘IO过高排查

Redis 持久化核心是RDB（全量快照）和AOF（增量日志），以及 4.0+ 推荐的混合持久化（RDB+AOF）。所有问题都围绕这两种机制的配置、执行、硬件资源展开，下面分场景逐一拆解。

一、数据丢失问题

现象

Redis 宕机 / 重启后，部分最新数据丢失，核心业务数据不一致。

核心原因

1. RDB 机制天生缺陷RDB 是定时全量快照，两次快照之间的所有数据，若宕机会完全丢失（比如配置save 60 10000，60 秒内写 1 万条才快照，中间宕机数据全丢）。
2. AOF 刷盘策略不合理（最常见）AOF 是写命令日志，刷盘策略直接决定丢数据风险：

1. ​​appendfsync always​​：每次写都刷盘 → 0 丢失，但性能极差
2. ​​appendfsync everysec​​：每秒刷盘 → 最多丢1 秒数据（生产默认）
3. ​appendfsync no​：交给操作系统刷盘 → 丢数秒～数分钟数据（严禁生产用）

1. 持久化文件损坏AOF/RDB 文件因磁盘故障、断电损坏，重启加载失败，数据丢失。
2. 未开启持久化 / 混合持久化纯内存运行，或关闭了 AOF，仅依赖 RDB；未开启混合持久化，AOF 回放失败。

排查步骤

1. 查看持久化配置
2. bash
3. 运行

# 登录Redis执行 config get save # 查看RDB快照规则 config get appendonly # 查看AOF是否开启（必须yes） config get appendfsync # 查看AOF刷盘策略 config get aof-use-rdb-preamble # 查看混合持久化是否开启

1. 查看 Redis 日志搜索关键词：RDB save failed、AOF corrupted、Loading failed，定位文件损坏 / 持久化失败原因。
2. 查看最后持久化时间
3. bash
4. 运行

info persistence # 关键字段：rdb_last_save_time（最后RDB时间）、aof_last_write_time（最后AOF写入）

1. 对比宕机时间，直接确定丢失数据的时间区间。

解决方案

1. 强制开启 AOF：appendonly yes（生产核心配置，无 AOF 必丢数据）。
2. AOF 刷盘策略：核心业务用everysec，极致安全用always（性能换安全）。
3. 开启混合持久化（4.0+ 默认开启）：aof-use-rdb-preamble yes，兼顾速度和安全性。
4. 修复损坏文件：
5. bash
6. 运行

# 修复AOF文件 redis-check-aof --fix appendonly.aof # 修复RDB文件 redis-check-rdb --fix dump.rdb

1. 禁用激进的 RDB 规则：避免频繁快照，减少丢失风险。

二、Redis 重启耗时过长

现象

Redis 启动后长时间无法提供服务（loading 状态），日志显示加载持久化文件耗时分钟级。

核心原因

Redis 重启优先加载 AOF 文件（开启 AOF 时），加载速度直接决定重启耗时：

1. 纯 AOF 文件未重写，体积爆炸AOF 是日志文件，长期不重写会达到 GB~TB 级，重启需要逐行回放命令，速度极慢。
2. RDB/AOF 文件过大实例内存占用过高（几十 GB），持久化文件体积巨大，加载 / 解压耗时。
3. 未开启混合持久化纯 AOF 加载速度远慢于「混合持久化（RDB 快照 + AOF 增量）」。
4. 硬件瓶颈机械盘（HDD）读写速度慢、内存不足、CPU 性能低，拖慢文件加载。

排查步骤

1. 查看 Redis 启动日志直接定位耗时：
2. plaintext

* Loading RDB produced by version 7.0.0 * Loaded xxx MB in xxx.xx seconds # 核心耗时 * Loading AOF started * Reading RDB preamble from AOF file

1. 查看持久化文件大小
2. bash
3. 运行

du -h dump.rdb appendonly.aof

1. 若 AOF 文件远超内存大小，说明未触发重写。
2. 检查 AOF 重写记录日志搜索AOF rewrite，确认是否长期未执行重写。

解决方案

1. 开启 AOF 自动重写（核心）
2. conf

auto-aof-rewrite-percentage 100 # AOF文件增长100%触发重写 auto-aof-rewrite-min-size 64mb # 最小64MB才重写

1. 重写后 AOF 文件瘦身，重启速度提升 10~100 倍。
2. 强制开启混合持久化：重启时先加载 RDB 快照，再回放少量 AOF 增量，速度碾压纯 AOF。
3. 控制实例内存：maxmemory限制内存大小，配合内存淘汰策略，避免持久化文件过大。
4. 硬件升级：使用SSD 磁盘，加载速度提升 5~10 倍。
5. 高可用规避：主从架构，主节点宕机直接切换从节点，避免重启主节点加载耗时。

三、磁盘 IO 过高排查

现象

服务器磁盘使用率 100%、IO 等待（% wa）飙高、Redis 响应变慢，业务卡顿。Redis 持久化是磁盘 IO 高的第一元凶。

核心原因

1. RDB 频繁 bgsave配置激进的save规则（如save 10 100），频繁触发全量 RDB 写入，大内存实例会瞬间打满磁盘 IO。
2. AOF 刷盘 / 重写 IO 叠加

1. ​​appendfsync always​​：每次写命令都刷盘，IO 无上限
2. AOF 重写（bgrewriteaof）：子进程全量写新 AOF 文件，IO 飙升

1. RDB + AOF 重写同时执行两个子进程同时写磁盘，IO 彻底打爆（Redis 默认会规避，但配置不当会触发）。
2. 磁盘瓶颈：机械盘、磁盘空间满、多进程共用磁盘。

排查步骤

系统层面：确认是 Redis 导致 IO 高

bash

运行

# 1. 查看磁盘IO状态（util%=100% 说明磁盘满负载） iostat -x 1 3# 2. 查看进程级IO（定位Redis进程） pidstat -d 1# 3. 查看CPU IO等待（%wa 高说明磁盘瓶颈）top

Redis 层面：定位持久化异常

bash

运行

info persistence

关键字段：

• ​​rdb_bgsave_in_progress:1​​：正在执行 RDB 快照
• ​​aof_rewrite_in_progress:1​​：正在执行 AOF 重写
• ​​aof_enabled:1​​：AOF 开启状态

查看配置

检查 ​​save​​ 规则是否过于频繁、​​no-appendfsync-on-rewrite​​ 是否关闭。

解决方案

1. 优化 RDB 配置（核心）注释激进的快照规则，甚至关闭自动 RDB（仅靠 AOF 持久化）：
2. conf

# 注释所有save规则，关闭自动RDB # save 3600 1 # save 300 100

1. AOF 核心优化
2. conf

appendfsync everysec # 禁用always，用everysec平衡性能 no-appendfsync-on-rewrite yes # AOF重写时，暂停AOF刷盘（避免IO叠加） auto-aof-rewrite-percentage 200 # 降低重写频率

1. 硬件 / 架构优化

1. 用SSD 磁盘提升 IOPS
2. Redis 持久化文件存独立磁盘，不和业务 / 系统日志共用
3. 主从架构：主节点关闭持久化，从节点做持久化（彻底分担主节点 IO）

1. 控制内存大小：减少单次持久化的文件体积，降低 IO 压力。

总结

1. 数据丢失：根因是 AOF 未开 / 刷盘策略错误 + RDB 定时快照缺陷，必须开 AOF+everysec + 混合持久化。
2. 重启耗时：根因是 AOF 未重写 / 文件过大，开 AOF 重写 + 混合持久化 + SSD秒级重启。
3. 磁盘 IO 高：根因是频繁持久化 + IO 叠加，关闭自动 RDB + 重写时暂停刷盘 + 主从分离 IO。