一杯咖啡的时间，聊聊技术与成长
哨兵：主从架构的自动值班员
主库半夜挂了，谁把从库提成新主库？哨兵给出的答案是：一群值班员盯着，一个人说挂了不算，多数人投票才算，选出一个领队执行切换。主观下线与客观下线的仲裁、哨兵自己的选主、脑裂的防范，这套机制比想象中民主。
持久化：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 的危害全是连锁反应：慢查询阻塞、网络打满、内存倾斜、迁移卡顿。发现靠扫描，治理靠拆分，预防靠规矩。
热 Key：一个分片扛下全站流量
明星官宣的瞬间，那条八卦的 key 被几十万 QPS 同时敲——Redis 集群再大，单个 key 也只住在一个分片上。热 Key 是倾斜的极端形态：加机器没用、加副本有讲究，本地缓存和多副本打散才是对症的药。先得发现它，再谈治理它。
预热：别让冷启动拖垮上线
缓存空着的时候等于没有缓存——新服务上线、Redis 重启、大促前夕，冷启动的空窗期里全量流量回源，DB 承受平时十倍的冲击。预热就是把热点数据提前搬进缓存：预热什么、什么时机、怎么控制回源速率，一次讲清。
延迟双删与 Binlog 订阅：把同步做稳
先库后缓存留下了两根尾巴：主从延迟让回源读到旧从库，并发竞态让旧值偶尔回填——延迟双删用第二次删除兜住这两类脏数据，binlog 订阅则干脆把删缓存从业务代码里剥离出来。一个求简单直接，一个求彻底解耦。
一致性：缓存与数据库的同步难题
读路径人人会写，写路径才是修罗场——为什么删缓存而不是改缓存、为什么先更新库再删缓存、并发读写交错时旧值怎么钻空子，Cache Aside 的写侧每一步都是取舍。不一致窗口消灭不了，只能把它压到工程可接受的范围。