一杯咖啡的时间，聊聊技术与成长
步长与号段：DB 发号的第一正解
从第 1 篇的步长方案升级：独立发号表、一次领一段、内存里慢慢发。号段模式趋势递增、ID 短小、DB 压力降为几百分之一——但号段有洞、主从切换可能号回跳，先立正解再立防线。
UUID：最顺手的瑞士军刀，最差的订单主键
撞车事故后同事提议全员换 UUID：零依赖、本地生成、概率上永不重复。但 128 位的随机串当 InnoDB 主键是三重暴击——无序写翻页、体积撑爆二级索引、排序无意义。v7 和 ULID 能救一半，场景判断才是关键。
订单号撞车之后：为什么需要分布式 ID
商城扛过大促，订单库拆成 16 库 256 表，上线第三天就出了跨用户退款事故——两张表的自增 ID 都从 1 开始。auto_increment 在分布式下必撞车，步长方案救急不救命，业务对 ID 的五条要求与四条候选路线一次列清。
收官：缓存进阶的完整地图
二十篇走完，从 Cache Aside 的第一行代码，到哨兵与 Cluster 的部署图，再到七个事故的复盘——缓存的知识地图最后合拢。用会、用好、用稳是三个台阶，这张地图把每一步的下一站都标了出来：性能优化的尽头，永远是对业务的深刻理解。
事故集锦：七次缓存事故复盘
机制都懂，事故照出——集体失效的凌晨、先删缓存留下的旧值、打满分片的热 Key、卡住主线程的大 Key 删除……七个真实形态的缓存事故，现象、根因、修复与教训逐一复盘。事故报告里最贵的一句话永远是：早就知道，没做。
大合流：一张缓存体系全景图
十七篇讲完，零件齐了——现在把一个请求的完整旅程串起来：读请求从 L1 一路漏斗到 DB，写请求从更新库到延迟双删；穿透击穿雪崩的防线各守一层，预热热key大key的治理各有清单。机制是散的，体系是一张图。
命中率：缓存体系的核心指标
缓存做得好不好，最终就浓缩成一个数字：命中率。它不是好看虚荣的仪表盘——每一次未命中都是一次回源、一笔 DB 开销、一段更高的 RT。命中率偏低，要从容量、TTL、访问模式三条线上找病根，而不是盲目加内存。
多级缓存：本地与分布式的合璧
Redis 再快也是一次网络往返，进程内存里的 Caffeine 才是纳秒级的终点站——本地缓存挡第一波，分布式缓存守第二层，数据库永远排在最后。但多一级缓存就多一份副本，「多实例怎么一起失效」这个新难题，是多级方案的全部代价所在。
Cluster：数据分片与横向扩展
哨兵解决了可用性，装不下的大数据量还得靠分片——Cluster 把 16384 个哈希槽摊到多个节点上，key 按槽就位，数据天生分散。MOVED 与 ASK 重定向、smart client、gossip 协议、扩容迁移，能力上去了，多 key 操作的枷锁也戴上了。