memcached缓存热点数据需分层设计：本地缓存极热数据，memcached集群承载主流量，数据库仅响应未命中请求；须防范击穿、雪崩与热点集中，通过空值缓存、互斥锁、预热、合理key设计、序列化优化及监控调优保障实效。
直接用Memcached缓存热点数据，核心是“先查缓存、未命中再查库、结果回填”，同时必须应对缓存击穿、雪崩和热点Key集中这三类典型问题。不是简单调用set和get就能生效，关键在策略设计和细节控制。
识别并分层缓存热点数据
真正高频访问的数据只占少数。比如电商中Top 100商品、配置表、用户权限等，应优先缓存；而长尾数据可不缓存或设极短TTL。
- 本地缓存（如Caffeine）存极热数据（如首页Banner），降低网络开销，命中率提升30%左右
- Memcached集群承载主流量，目标命中率70%以上，用一致性哈希分散负载
- 数据库只响应缓存未命中的请求，压力下降60%–80%
- 对爆款商品缓存TTL设为600秒（10分钟），普通商品120–300秒，滞销品可不缓存
防止缓存击穿与空查询穿透
当一个热门key过期瞬间，大量并发请求会同时打到数据库，极易拖垮服务。
- 对空结果也缓存（如
set("user:1001", null, 60)），避免反复查不存在的ID - 使用互斥锁（Mutex）：缓存失效时，仅第一个请求重建缓存，其余等待或短暂重试
- 预热机制：在大促前，用脚本批量加载已知热点key（如
echo "set product:123 0 3600 5\r\nhello\r\n" | nc 127.0.0.1 11211）
合理设计Key与序列化方式
Key命名混乱或序列化低效，会放大内存占用和网络延迟。
- Key带业务前缀+唯一标识，如
user:profile:789、config:site:lang，避免冲突和误删 - 会话类Key建议加随机后缀：
session:uid123:abc456，防Session Fixation攻击 - 序列化优先选MessagePack而非JSON，空间节省约40%，尤其适合嵌套结构
- 单个value不超过1MB（Memcached默认限制），超限需拆分或压缩
配合监控与动态调优
缓存效果不能靠猜，得看真实指标。
- 关注
get_hits / (get_hits + get_misses)，命中率低于60%需检查TTL或热点识别逻辑 - 用
memcached-tool 127.0.0.1:11211 display观察slab分布，避免内存碎片 - 启用LRU爬虫（
-o lru_maintainer,lru_crawler），自动识别最近1小时高频访问key用于定向预热 - 对持续高QPS的key（如
hot:news:top），考虑客户端本地副本+短TTL兜底，分流DataServer压力
