一杯咖啡的时间，聊聊技术与成长
热 Key：一个分片扛下全站流量
明星官宣的瞬间，那条八卦的 key 被几十万 QPS 同时敲——Redis 集群再大，单个 key 也只住在一个分片上。热 Key 是倾斜的极端形态：加机器没用、加副本有讲究，本地缓存和多副本打散才是对症的药。先得发现它，再谈治理它。
预热：别让冷启动拖垮上线
缓存空着的时候等于没有缓存——新服务上线、Redis 重启、大促前夕，冷启动的空窗期里全量流量回源，DB 承受平时十倍的冲击。预热就是把热点数据提前搬进缓存：预热什么、什么时机、怎么控制回源速率，一次讲清。
延迟双删与 Binlog 订阅：把同步做稳
先库后缓存留下了两根尾巴：主从延迟让回源读到旧从库，并发竞态让旧值偶尔回填——延迟双删用第二次删除兜住这两类脏数据，binlog 订阅则干脆把删缓存从业务代码里剥离出来。一个求简单直接，一个求彻底解耦。
一致性：缓存与数据库的同步难题
读路径人人会写，写路径才是修罗场——为什么删缓存而不是改缓存、为什么先更新库再删缓存、并发读写交错时旧值怎么钻空子，Cache Aside 的写侧每一步都是取舍。不一致窗口消灭不了，只能把它压到工程可接受的范围。
雪崩：同一夜失效的所有缓存
击穿是一个 key 的意外，雪崩是一批 key 的集体事故——同一时刻大量 key 集中到期，或者 Redis 整体宕机，全部读流量一瞬间涌向数据库。TTL 打散是预防针，本地缓存是缓冲垫，限流降级是止血带，高可用才是根治手术。
击穿：爆款过期的那一秒
热点 key 过期的瞬间，成千上万个并发请求同时未命中、同时回源——同一份数据的重建请求把 DB 打了一梭子。互斥重建让一个人排队干活，逻辑过期让旧值先顶一会儿：一个求准，一个求稳，爆款必须想清楚选哪个。
穿透：查一个不存在的商品
缓存挡的是「查得到」的流量，可攻击者专发「查不到」的 id——缓存永远未命中，DB 替缓存挨了全部子弹。空值缓存、布隆过滤器、入口校验，三件武器各管一段：一个便宜，一个彻底，一个治本。
Cache Aside：最经典的读写模式
读先走缓存、未命中回源；写先更新库、再删缓存——Cache Aside 四句话就说完了，但「为什么是删而不是更」「为什么先库后缓存」这两个问题的答案里，藏着并发与懒加载的全部心思。最经典的模式，值得最认真地讲一遍。
3 秒的商品详情：性能问题为什么先找缓存
商品详情接口查五次库 RT 三秒，DB 的 CPU 天天飘红——读写比 99:1 的场景，第一步该动缓存而不是先磨 SQL。缓存用内存空间和一层新的复杂度换时间，这笔交易怎么算、代价怎么付，是整个系列的主线。