一杯咖啡的时间，聊聊技术与成长
大合流：一张缓存体系全景图
十七篇讲完，零件齐了——现在把一个请求的完整旅程串起来：读请求从 L1 一路漏斗到 DB，写请求从更新库到延迟双删；穿透击穿雪崩的防线各守一层，预热热key大key的治理各有清单。机制是散的，体系是一张图。
命中率：缓存体系的核心指标
缓存做得好不好，最终就浓缩成一个数字：命中率。它不是好看虚荣的仪表盘——每一次未命中都是一次回源、一笔 DB 开销、一段更高的 RT。命中率偏低，要从容量、TTL、访问模式三条线上找病根，而不是盲目加内存。
多级缓存：本地与分布式的合璧
Redis 再快也是一次网络往返，进程内存里的 Caffeine 才是纳秒级的终点站——本地缓存挡第一波，分布式缓存守第二层，数据库永远排在最后。但多一级缓存就多一份副本，「多实例怎么一起失效」这个新难题，是多级方案的全部代价所在。
Cluster：数据分片与横向扩展
哨兵解决了可用性，装不下的大数据量还得靠分片——Cluster 把 16384 个哈希槽摊到多个节点上，key 按槽就位，数据天生分散。MOVED 与 ASK 重定向、smart client、gossip 协议、扩容迁移，能力上去了，多 key 操作的枷锁也戴上了。
哨兵：主从架构的自动值班员
主库半夜挂了，谁把从库提成新主库？哨兵给出的答案是：一群值班员盯着，一个人说挂了不算，多数人投票才算，选出一个领队执行切换。主观下线与客观下线的仲裁、哨兵自己的选主、脑裂的防范，这套机制比想象中民主。
持久化：RDB 快照与 AOF 日志
重启就丢光所有缓存，Redis 也能接受——但接受到什么程度，是 RDB 和 AOF 的选择题。RDB 是定时快照，恢复快但丢得多；AOF 是逐条日志，丢得少但恢复慢；4.0 的混合持久化把两者缝在一起。fork 的内存玄机，是这道题隐藏的第三问。
过期与复制：Redis 自身的两套机制
TTL 到期的 key 是谁删掉的？主库的数据是怎么到从库的？过期删除靠惰性加定期两班倒，主从复制靠 RDB 全量加 backlog 增量两段式。这两套机制藏在幕后，却直接决定了从库读到的数据新不新鲜、断线重连的代价有多大。
淘汰策略：内存满了，腾谁留谁
Redis 是内存数据库，内存总有满的一天——满了以后新写入是报错还是淘汰旧数据、按什么标准淘汰，这就是 maxmemory 与八种淘汰策略的选择题。LRU 看最近、LFU 看频率，纯缓存选 allkeys，还挂了持久化的系统要用 volatile 系列。
大 Key：Redis 里的定时炸弹
一个 hash 里塞了十万条成员、一个 value 存了几 MB 的 JSON——平时相安无事，直到某次删除把单线程卡住两秒。大 Key 的危害全是连锁反应：慢查询阻塞、网络打满、内存倾斜、迁移卡顿。发现靠扫描，治理靠拆分，预防靠规矩。