第五部分：Redis 与缓存架构（第 51～60 题）

1. RDB vs AOF？2. 混合持久化？3. 恢复速度？4. 缓存要不要持久化？5. fork 阻塞？

第一步：分析。持久化=数据安全 vs 性能。缓存可丢（丢了解释回源），计数/队列不能丢需持久化。

第二步：挑战。恢复速度、数据丢失窗口、fork 阻塞。

第三步：架构。①缓存：可关持久化或仅 RDB（丢了解释回源，恢复快）；②重要数据：AOF（everysec）+ 混合持久化（RDB+AOF）——重启先加载 RDB 快，再重放 AOF 增量，兼顾速度与安全；③fork：bgsave 时 COW 可能阻塞，控制内存/低频。

第四步：选型。混合持久化（Redis 5+ 默认 aof-use-rdb-preamble yes）+ everysec。

第五步：一致性。持久化保证重启后数据可恢复；缓存丢可回源。

第六步：高可用。主从+哨兵，宕机切从，持久化兜底。

第七步：优化。缓存禁用持久化提性能；重要数据混合持久化。

RDB：快照，恢复快，但丢上次快照后数据，bgsave fork 有阻塞。AOF：记命令，everysec 最多丢 1s，但文件大恢复慢。混合：RDB 头（快速载入）+ AOF 增量尾（补丢失），鱼与熊掌。缓存若可回源，关持久化性能最佳。

// redis.conf 关键配置
// 重要数据:
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes   // 混合持久化
// 纯缓存(可丢):
save ""            // 关 RDB
appendonly no
// 应用侧: 缓存丢→回源DB重建

1. 固定窗口 vs 滑动窗口？2. 滑动窗口怎么用 Redis？3. 令牌桶 Lua？4. 集群限流？5. 限流误杀？

第一步：分析。限流保护系统，Redis 实现分布式共享计数。滑动窗口更平滑，令牌桶支持突发。

第二步：挑战。边界突刺、原子性、集群、误杀。

第三步：架构。①滑动窗口：ZSET 存请求时间戳，统计窗口内数量（Lua 原子）；②令牌桶：Lua 计算当前令牌（按速率补充），够则放行；③集群：单 Key 限流（如按用户/接口 Hash 到固定节点）或 Redis Token Server；④误杀：阈值留余量 + 多维限流（用户/IP/接口）。

第四步：选型。Redis + Lua（原子）+ ZSET/计数器。

第五步：一致性。Lua 保证计数原子，限流决策一致。

第六步：高可用。Redis 故障 fail-open（放行但有监控）或 fail-close（按风险）。

第七步：优化。本地令牌桶做第一道（降 Redis 压力），Redis 做全局。

固定窗口缺陷：窗口边界突刺（59s+1s 各满，瞬间 2 倍）。滑动窗口：ZSET 按时间计数，平滑但内存随请求数增。令牌桶 Lua：维护 last_refill + tokens，每次按 elapsed×rate 补，原子扣减，支持突发且平滑。fail 策略：限流组件故障不能阻断正常业务（fail-open），高风险的（如防刷）fail-close。

// 滑动窗口限流(Lua, 原子)
private static final String SLIDE = """
    redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, ARGV[1]-tonumber(ARGV[2]))
    local n = redis.call('ZCARD', KEYS[1])
    if n >= tonumber(ARGV[3]) then return 0 end
    redis.call('ZADD', KEYS[1], ARGV[1], ARGV[1])
    return 1""";
// 用户维度: key=user:limit:uid, 窗口=60000ms, 限100
Long ok = redis.eval(SLIDE, List.of("user:limit:"+uid),
    now+"", "60000", "100");

1. 两级缓存职责？2. 一致性怎么保？3. 本地内存爆？4. 何时只用 Redis？5. 多级读流程？

第一步：分析。多级=本地（Caffeine，纳秒级，容量小）+ Redis（分布式，毫秒，容量大）+ DB。就近优先，降远端压力。

第二步：挑战。一致性、内存、失效广播。

第三步：架构。①读：本地→Redis→DB，逐级回源；②写：更 DB→删 Redis→广播删本地；③本地用 Caffeine（LRU/窗口淘汰），短 TTL（如 1~5s）+ 失效广播；④只热数据进本地，控内存。

第四步：选型。Caffeine（本地）+ Redis（分布式）+ 广播（Redis pub/sub/配置中心）。

第五步：一致性。本地短 TTL+广播近实时；强一致走源。

第六步：高可用。本地降级（Redis/DB 仍可用）；Redis 挂本地撑短窗。

第七步：优化。本地只缓存热点；监控命中率调参。

为什么多级？本地命中省网络+序列化，RT 从 2ms→微秒，Redis 压力骤降。一致性权衡：本地是「牺牲一点新鲜换性能」，短 TTL+广播把脏窗口压到秒级，适合读多写少展示。何时只用 Redis：数据强一致/写频繁/单机内存小，本地反而添乱。

// 多级读
public Item load(Long id){
  Item v = local.getIfPresent(id);          // 1 本地
  if (v != null) return v;
  v = redis.get(id);                          if (v != null) { local.put(id,v); return v; } // 2 Redis
  v = db.load(id); redis.set(id,v,30min); local.put(id,v); return v; // 3 DB
}
// 失效广播
redis.publish("inv", id+""); // 各实例 local.invalidate

1. 整体分层？2. 各层职责与阈值？3. 一致性总策略？4. 监控看什么？5. 故障降级链？

第一步：分析。把分散的缓存技术编排为「本地→Redis→DB」三级 + 防护层（布隆/限流）+ 兜底（降级）。

第二步：挑战。多层一致、阈值联动、可观测、降级链。

第三步：架构。①本地 Caffeine（热 Key，1~5s）+ Redis（分布式，分片打散热/大 Key，错峰 TTL）+ DB（裁判）；②防护：布隆防穿透、逻辑过期/互斥防击穿、错峰防雪崩、滑动窗口限流；③一致：写更 DB→删 Redis→广播本地+binlog 兜底；④监控：命中率/回源 QPS/热 Key/大 Key；⑤降级：Redis 挂→本地+限流+默认值。

第四步：选型。见前述各题组合 + Prometheus/Grafana 监控。

第五步：一致性。多级最终一致，强一致走源；binlog 兜底。

第六步：高可用。逐层降级；Redis 集群 HA；限流保 DB。

第七步：优化。命中率驱动调参；自动热 Key 晋升。

为什么收敛为体系？单点方案各自为政易冲突；体系化按「命中率目标」反向设计每层阈值。一致性总策略：删缓存（非更新）+ 广播 + binlog 兜底，保证最终一致。降级链：明确每层故障时的行为，DB 始终是最后裁判但被限流保护。

// 体系封装: 读模板(本地→Redis→DB) + 防护
public <T> T getCached(Long id, Loader<T> db) {
  if (!bloom.mightContain(id)) return null;  // 防穿透
  T v = local.get(id, k -> redis.get(k, db));     // 多级
  return v;
}
// 写: DB → 删Redis → 广播本地 → binlog兜底

1. 延迟来源？2. 慢命令怎么治？3. fork 阻塞？4. 网络/客户端？5. 大 Key 与延迟？

第一步：分析。Redis 延迟=命令自身（大 Key/慢命令）+ 阻塞（fork/同步操作）+ 网络/客户端（连接、序列化）。

第二步：挑战。多源定位、慢命令、fork、网络。

第三步：架构。①监控：slowlog、latency-monitor 定位；②慢命令：禁 KEYS/FLUSHALL，用 SCAN/HSCAN；大 Key 拆分（Q54）；③fork：控制内存、低频 bgsave、用大页；④网络：pipeline/批量、连接池复用、就近部署；⑤客户端：避免大批量一次性读。

第四步：选型。slowlog + latency-monitor + SCAN + pipeline + 连接池。

第五步：一致性。延迟优化不影响语义；pipeline 注意原子性。

第六步：高可用。慢命令隔离（从节点执行）；主从降阻塞。

第七步：优化。命令时间复杂度 O(1)；热数据本地缓存降 Redis 调用。

O(1) 原则：KEYS 是 O(N) 全扫，必慢；用 SCAN 游标分批。fork 阻塞：bgsave/rewrite 时主进程 fork 子进程，内存大时 COW 卡顿，控制实例内存（<10G）、低频。pipeline：合并多次 RT 往返，但单次数据量别太大（避免阻塞+网络）。

// 用 SCAN 替代 KEYS(分批, 不阻塞)
var cur = ScanOptions.SCAN_POINTER_START;
do { List<String> ks = redis.scan(cur, 1000); process(ks); }
while (!cur.isComplete());
// pipeline 批量(降RT往返)
redis.pipelined(p -> { keys.forEach(k -> p.get(k)); }); // 单次量控
// 配置: slowlog-log-slower-than 10000(10ms) + latency-monitor