缓存Key设计规范：如何设计高命中率的Key？

大家好，我是你们的老朋友。今天我们来聊聊缓存Key的设计。

很多人觉得Key设计嘛，随便起个名字就行了。我刚开始做缓存时也这么想。结果呢？线上事故频发，缓存命中率惨不忍睹。后来我才明白——Key设计是缓存系统的地基。地基不稳，上面再好的策略都是白搭。

这一章，我把自己踩过的坑、总结的经验，全部分享给你。咱们从三个维度入手：前缀命名、热点Key打散、过期时间错峰。

一、前缀命名：让Key有迹可循

先问个问题：你见过这样的Key吗？

user_12345
order_67890
product_abcde

嗯，我见过。而且我接手过一个项目，里面全是这种Key。当时要排查一个缓存问题，我对着几千个Key，完全不知道哪个是哪个。说白了，这就是给自己挖坑。

好的前缀命名，应该像图书馆的索引号。一看就知道属于哪个业务、什么数据类型、什么版本。

我个人习惯用这种格式：

{业务域}:{模块}:{数据类型}:{唯一标识}:{版本号}

举个例子：

user:profile:info:12345:v2
order:detail:list:67890:v1
product:stock:count:abcde:v3

你看，一眼就能看出来：

• 这是用户模块的
• 存的是个人资料信息
• 用户ID是12345
• 当前是v2版本

我在项目中遇到过一件事：有一次要批量清理某个业务线的缓存。因为Key前缀规范，一条命令就搞定了：

redis-cli --scan --pattern "user:profile:*" | xargs redis-cli del

要是没有前缀规范，你想想看，得有多痛苦？

二、热点Key打散：别让流量压垮单点

热点Key，说白了就是那些被频繁访问的Key。比如双十一的爆款商品、微博热搜榜、秒杀活动的商品ID。

我记得有一次，一个电商平台的大促活动，某个爆款商品的缓存Key被疯狂访问。QPS直接飙到几十万。结果呢？那个Redis节点扛不住了，整个集群都跟着抖。这就是典型的热点Key打散问题。

为什么会这样？因为Redis是单线程模型。一个热点Key的请求，会把那个节点的CPU打满。其他Key的请求都得排队等着。

怎么解决？我常用的方法是给热点Key加随机后缀：

// 原始Key
product:detail:12345

// 打散后的Key
product:detail:12345:0
product:detail:12345:1
product:detail:12345:2
...
product:detail:12345:9

客户端读取时，随机选一个后缀：

// Java示例
int suffix = ThreadLocalRandom.current().nextInt(10);
String key = "product:detail:12345:" + suffix;
String value = redis.get(key);

这样，原来一个Key的压力，被分散到了10个Key上。每个Key的访问量只有原来的十分之一。

不过要注意一点：写的时候要同步写所有打散Key。不然会出现数据不一致。我一般用pipeline批量写入：

// 批量写入打散Key
Pipeline pipeline = redis.pipelined();
for (int i = 0; i < 10; i++) {
    String key = "product:detail:12345:" + i;
    pipeline.set(key, value);
}
pipeline.sync();

三、过期时间错峰：避免缓存雪崩

缓存雪崩，说白了就是大量Key在同一时间过期。然后所有请求都穿透到数据库。数据库瞬间被打爆。

我见过一个案例：某个系统把所有缓存Key的过期时间都设成了1小时。结果每到整点，数据库的QPS就飙升到平时的10倍。DBA吓得赶紧打电话。

怎么解决？给过期时间加一个随机偏移量：

// 基础过期时间：3600秒（1小时）
// 随机偏移：0-600秒（0-10分钟）
int baseExpire = 3600;
int randomOffset = ThreadLocalRandom.current().nextInt(600);
int expireTime = baseExpire + randomOffset;

redis.setex(key, expireTime, value);

这样，Key的过期时间分布在3600到4200秒之间。不会出现集体过期的现象。

你想想看，如果100万个Key都在同一秒过期，那是什么场景？数据库直接跪了。但分散到10分钟内过期，数据库完全扛得住。

另外，我建议不同业务线的Key，基础过期时间也要错开。比如：

这样，即使某个业务线的Key集中过期，也不会影响其他业务线。

知识体系总览

最后，我用一张图来总结本章的核心逻辑。这张图是我自己画的，希望能帮你建立整体认知：

嗯，这一章的内容就到这里。记住：Key设计不是小事。它决定了你的缓存系统能走多远。下一章，我们聊聊缓存穿透的应对策略。到时候见。

想要更多资料，联系可可