适用读者：核对"那 9 篇缓存与工具文去哪了"的读者；本系列维护者。
性质：登记表 + 三处补充判据。10 篇尾部旧文中 1 篇新写进 J06，其余 9 篇在此登记。
覆盖旧文：4583（分布式 ID）、4588（缓存雪崩/穿透/击穿）、4590（Redis 自定义线程池）、4591（淘汰算法与 Caffeine）、4592（Caffeine + Redis 二级缓存）、4593（CompletableFuture 并行化）、4594（MQ 选型）、4595（延时消息 + 延迟双删）、3706（Lucene）→ 9 篇。

---

1. 逐篇登记

旧文	标题	字符数	处置	去向与理由
4583	为什么需要分布式 ID？一文搞懂分布式 ID 生成方案	3,867	duplicate_ref	J05 分布式 ID：雪花/号段/UUID 的取舍已主讲
4588	缓存设计：雪崩、穿透、击穿	2,795	duplicate_ref	S12（缓存一致性/防护主讲）；本篇为三问速览
4590	为什么引入 Redis 缓存要自定义线程池配置类	2,160	appendix	有价值（缓存调用与业务线程池隔离），并入本文 §2
4591	缓存淘汰算法与 Caffeine：FIFO/LRU/LFU/W-TinyLFU	2,541	appendix	算法对照，并入本文 §3（与 S12 不重复：S12 讲一致性，此处讲淘汰）
4592	Caffeine + Redis 二级缓存设计	4,422	duplicate_ref	S12（多级缓存与一致性）；本篇为落地拼装
4593	用 CompletableFuture 优化接口：串行 RPC 改并行	2,959	duplicate_ref	S05（并发编程）+ S04（Future/异步）
4594	MQ 介绍与技术选型：从缓存一致性场景说起	2,062	duplicate_ref	J02 MQ 选型
4595	延时消息 + 延迟双删：保证 Redis 缓存一致性	2,960	duplicate_ref	S12（延迟双删）+ J03（延时消息）
3706	Lucene 入门：全文搜索引擎原理与实践	2,612	duplicate_ref	S13（检索原理与倒排索引）

---

2. 缓存调用为什么要独立线程池（4590 的机制化）

问题：缓存读写与业务逻辑共用同一个线程池
→ 缓存抖动（Redis 慢、网络重连）时，业务线程全部阻塞在缓存调用上
→ 整条接口链路雪崩（缓存本应是"加速器"，却成了单点）

对策：缓存调用走独立的、有界线程池 + 超时 + 降级（miss 就查库）
判据：线程池隔离的边界 = "故障域"边界；跨故障域的调用必须能超时并隔离

配置项	建议	理由
队列	有界（如 200~1000）	无界队列会把内存耗尽变成 OOM
超时	缓存读 50~100 ms	超时即降级查库，比等更快恢复
拒绝策略	拒绝 + 降级（CallerRuns 反而放大）	快速失败优于排队堆积
线程数	按 QPS × 平均耗时估算，通常 8~32	过多线程只是把压力转移到 Redis

---

3. 淘汰算法对照（4591）

算法	命中最优场景	缺陷	备注
FIFO	近似流式访问	忽略频率，热数据会被冲掉	实现最简
LRU	时间局部性强的访问	扫描型访问会污染缓存（一次全表扫冲掉热数据）	Redis 的近似 LRU
LFU	长期稳定热点	新热点难以晋升（历史权重压制）	Redis 4.0+ 有 LFU
W-TinyLFU（Caffeine）	大多数真实负载	实现复杂	用 frequency sketch + window LRU，抗扫描

判据："有扫描型访问的负载，LRU 会被打穿"——这正是 Caffeine 默认 W-TinyLFU 的原因；本地缓存优先 Caffeine，分布式缓存才用 Redis（并注意两者的一致性窗口，见 S12）。

---

4. 三处补充判据（不重复主讲篇）

主题	主讲篇已有	本文补充
分布式 ID	J05：雪花/号段/UUID 取舍	时钟回拨的处置：等待、借用未来序列、或改用号段
延迟双删	S12：两次删除的时序	删除失败的重试：MQ 补偿 + 幂等删除；删除延迟应大于"主从同步 + 业务读耗时"
MQ 选型	J02：Kafka/RabbitMQ/RocketMQ 对照	选型先看"是否需要事务消息/延时消息/顺序消息"，再看吞吐

时钟回拨的最小处置（雪花 ID）：

① 检测：当前时间 < 上次生成时间 → 回拨
② 小幅回拨（< 阈值如 5 ms）→ 自旋等待追平
③ 大幅回拨 → 拒绝服务并告警（绝不"倒拨 workerId"迁就）
④ 长期方案：号段模式（DB/Redis 分配区间），不依赖机器时钟

---

5. 缺口与待核

项	状态
Caffeine 当前版本 API 与默认参数	待核（正文只写算法与判据）
Redis 7.x 近似 LRU/LFU 的具体采样参数	待核
4590 的线程池数值	原文给的是经验值，非实测；本文按估算方法重写
Lucene 9.x 索引格式变化	由 S13 主讲，本篇不展开（待核）

---

6. 下一篇

S17 系列验收（v2） —— 16 篇 / 16,473 点位 / 10 篇尾部旧文 100% 处置 / 下一系列（P18：S22 9 篇）前置依赖。

---

本篇属于系列《S17 · 分布式与消息队列》。旧文来源：A-4583/4588/4590/4591/4592/4593/4594/4595/3706；扩展点 E-S17-024。ZK 行为按 3.5+ 口径描述，3.8/3.9 具体变更待核。

---

上一篇：S17-J06 · ZooKeeper 与分布式协调：会话、watch 与选主