持久化与内存生命周期

3.1RDB：fork 子进程做快照

RDB 在某个时刻把整个内存数据集序列化成一个紧凑的二进制文件；靠 fork 出子进程来完成，父进程借助 copy-on-write 继续服务，快照保持那一刻的一致性视图。

fork 由 save 或 bgsave 触发，也可由 redis.conf 的 save 规则自动触发。save <seconds> <changes> 的含义是：在 seconds 秒内发生了至少 changes 次写操作，则自动执行一次 bgsave。默认三条规则（7.x）：

save 3600 1      # 1 小时内至少 1 次写 → bgsave
save 300  100    # 5 分钟内至少 100 次写 → bgsave
save 60   10000  # 1 分钟内至少 10000 次写 → bgsave

# 关闭自动 RDB（只用 AOF）：
save ""

fork 的代价：页表复制与 THP

fork 本身不复制物理内存，但必须复制进程的页表。页表大小正比于虚拟地址空间的映射条数，而非数据量本身。一个 20 GB 的实例，页表可能占几十到几百 MB；fork 时主线程在这段时间内阻塞（操作系统在内核态完成页表复制），延迟通常在 数十毫秒到数百毫秒量级，大实例偶发 1–2 秒。

透明大页（Transparent Huge Pages，THP）放大这个问题：THP 把普通 4 KB 页合并成 2 MB 的大页，COW 时粒度也变成 2 MB——父进程只改了几个字节，OS 却要复制整个 2 MB 大页，写入放大可达 500 倍。生产环境 Redis 官方建议关闭 THP：

echo never > /sys/kernel/mm/transparent_hugepage/enabled
# 持久化写入 /etc/rc.local 或 systemd service

3.2AOF：追加写命令 + 重写压缩

AOF（Append Only File）把每条写命令以 RESP 格式追加到文件末尾；重写（rewrite）在不中断服务的情况下把文件压缩成等价的最小命令集。

多段 AOF（Redis 7.0）

7.0 之前 AOF 是单个文件（appendonly.aof），rewrite 要把整个文件原地重写，存在覆盖失败导致丢数据的风险。7.0 引入多段 AOF（Multi-Part AOF），AOF 数据拆成三类文件，统一放在 appendonlydir/ 目录下：

• base 文件（appendonly.aof.1.base.rdb 或 .aof）：某次 rewrite 时的全量基线快照。当 aof-use-rdb-preamble yes（默认）时，base 用 RDB 格式写入，称为混合持久化——base 紧凑、恢复快，增量部分仍用 AOF 命令格式。
• 增量文件（appendonly.aof.1.incr.aof）：base 建好之后，新写入的命令追加到这里。
• manifest 清单文件（appendonly.aof.manifest）：记录当前哪个 base、哪些 incr 是有效的，恢复时按 manifest 顺序加载，多余的旧文件直接删除，彻底消除单文件覆盖的一致性风险。

3.3fsync 策略与丢失窗口

AOF 追加写命令后，数据先到 OS 页缓存（page cache），需要 fsync 才真正落盘；fsync 策略决定丢失窗口的上限。

everysec 由一个后台 I/O 线程（bio 线程）负责，每隔 1 秒调用一次 fsync(fd)。宕机发生在最坏位置时，上次 fsync 到宕机之间最多 1 秒的写入未落盘，因此说"最多丢约 1 秒的数据"。注意：这里的 1 秒是统计上界，实际丢失量取决于宕机时刻距上次 fsync 的间隔，可以是 0 到 1 秒之间的任意值。

3.4RDB vs AOF 选型

RDB 紧凑、恢复快、有丢失间隔；AOF 持久精度高、文件大、重放慢。生产常两者并开，用混合格式取最优解。

3.5过期删除：惰性 + 定期两路

过期 key 的删除走两条路：访问时惰性检查，以及 serverCron 定期采样；副本不自行过期，等主库传播 DEL/UNLINK。

惰性删除（lazy expiration）

任何读写命令访问某个 key 时，Redis 先调用 expireIfNeeded() 检查该 key 是否已过期。若过期，立即删除并返回 nil（或空结果），命令本身不再继续执行。这路删除零额外开销——只有被访问的 key 才被检查；代价是长时间不访问的已过期 key 会积压在内存里。

定期删除（active expiration）

serverCron 按 hz（默认 10，即每秒执行 10 次）调度过期清理逻辑。每轮从设有过期时间的 key 字典（expires dict）中随机采样 20 个 key，删掉其中已过期的；若这一轮删掉的比例超过 25%，说明过期 key 密度高，立即再来一轮，直到比例降到 25% 以下或达到单次时间上限（默认 25ms）。这个机制保证：既不长期占用主线程，也不会因为惰性路径的懒惰让过期 key 无限堆积。

hz 10                  # serverCron 每秒调度次数，提高可加快过期清理（但增加 CPU）
dynamic-hz yes         # 自适应调整 hz（负载高时升，空闲时降）；7.x 默认开启
lazyfree-lazy-expire yes  # 过期删除改为异步（bio 线程），避免大 key 过期阻塞主线程

副本不自行过期

Replica（副本）上的 key 不会被主动过期删除，只能等主库（primary）传播 DEL 或 UNLINK 命令过来才删除。原因：副本没有写权限，若副本自行删除会造成主从数据不一致（主库还在、副本先删）。但副本上访问一个已过期但主库尚未传播 DEL 的 key 时，4.0 以后副本会根据本地时钟判断是否过期，若过期则返回 nil——读行为一致，但删除操作仍由主库主导。

3.6内存淘汰：近似 LRU 与 LFU

内存达到 maxmemory 上限时，Redis 按 maxmemory-policy 决定淘汰哪些 key；近似 LRU 和 LFU 用采样池降低精度换取极低的内存和 CPU 开销。

八种淘汰策略

近似 LRU：24 位时钟 + 采样池

每个 redisObject 有一个 24 位的 LRU 时钟字段，记录最近一次访问的秒级时间戳（低 24 位，约 194 天回绕一次）。触发淘汰时，Redis 随机采样 maxmemory-samples（默认 5）个 key，加入一个候选池（eviction pool），保留其中访问时间最老的 key；下次淘汰再采样，与池中已有候选合并选最旧的淘汰。

把 maxmemory-samples 调到 10，准确度已非常接近真正的 LRU，但内存和 CPU 开销仍是 O(采样数) 而非 O(key 总数)。

LFU（Redis 4.0）：Morris 计数器 + 时间衰减

LFU 把 LRU 时钟字段复用为一个 8 位字段，分成两部分：

• 高 5 位（ldt）：上次访问的分钟级时间戳，用于衰减计算——lfu-decay-time（默认 1 分钟）控制每过多少分钟计数减 1。
• 低 3 位（counter）——这里文档有误，实际 LFU 使用原来 lru 字段的高 16 位存时间、低 8 位存计数。更准确地说：低 8 位作为 Morris 概率计数器，饱和在 255（实际访问次数对应约 100 万次）——每次访问不是无条件加 1，而是以 1 / (counter × lfu-log-factor + 1) 的概率加 1，使计数增长随访问次数呈对数曲线。lfu-log-factor 默认 10，让计数器在约 100 万次访问时饱和到 255。

LFU 的核心优势：对一次性大扫描（全表遍历、批量导入）有天然抵抗力——新访问的 key 计数从 0 开始，不会立刻把老热点挤走；而 LRU 只看最近一次访问时间，一次全表扫描会把所有扫过的 key 都标记成"最近访问"，把真正的热点从淘汰候选池里挤掉。