文章定位
生产环境里的实战经验沉淀，适合拿来做方案评审、复盘和升级前检查。
阅读建议
先看标题和列表，再回到关键段落。技术文章更适合跳读和回查的结构。
适合场景
云原生、后端工程、系统设计、性能优化、故障处理和团队知识沉淀。
为什么要自己做缓存#
很多业务并不是缺一个 Redis，而是缺一个贴近进程、延迟更低、可控性更强的本地缓存层。
- 读热点高度集中
- 对尾延迟敏感
- 需要业务级淘汰策略
- 希望在压测里看清内存和并发行为
设计目标#
我给这个缓存系统定了四个目标：
- 多核下尽量减少锁竞争
- 热点数据有更高命中率
- 内存上限可控
- 排查性能问题时能直接定位瓶颈
核心结构#
整体结构拆成三层：
- 分片层：把 key 打散到多个 shard
- 准入层：决定值不值得进入缓存
- 淘汰层：在容量逼近上限时移除低价值数据
分片#
分片不是为了“看起来高级”，而是为了把锁竞争摊开。只要热点 key 分布足够均匀，吞吐就会比单锁模型稳定得多。
准入#
我更偏向 W-TinyLFU 这类策略，因为它对短期热点和长期热点之间的平衡更好，适合波峰明显的接口流量。
淘汰#
淘汰逻辑一定要和内存监控放在一起看。只看命中率，很容易得到一个“命中高但内存不可控”的系统。
实践经验#
真正上线前，最有价值的不是继续写功能，而是补：
- pprof 观察点
- 命中率统计
- 分片负载分布
- 热 key 识别
- 淘汰原因统计
这些信息会直接决定你后续能不能把缓存从“工具”变成“系统能力”。