Redis 键设计先把命名和版本想清楚

很多项目第一次接 Redis，都把注意力放在“怎么查得更快”上。但真正在 2021 年做内容或后台服务时，我觉得更应该先想清楚的是 key 设计。因为缓存逻辑可以改，key 一旦遍布代码和运维脚本，后面想统一重构就很难了。

一个好用的 key 方案，至少要同时考虑命名、层级和未来升级空间。

命名先围绕业务对象组织

我更推荐的格式通常是 系统:对象:标识:附加维度。比如文章详情、分类树、首页推荐这类缓存，看 key 时最好一眼就能知道自己在看什么业务对象，而不是只能猜。

把业务语义放在前面，后续排查和批量删除都更顺手。

预留版本位能减少大面积清缓存

很多缓存结构早期简单，后面随着字段变化、序列化方式变化，总会遇到“旧缓存和新代码不兼容”的情况。这时如果 key 里完全没有版本概念，只能用更粗暴的全量删除来兜底。

提前留一个版本段，比如 post:v2:123，会让升级动作温和很多。

列表 key 要把查询条件表达清楚

详情 key 通常比较直接，列表 key 则容易偷懒。分页、排序、筛选条件如果没有稳定编码，缓存命中和排障都会变得混乱。

哪怕一开始查询维度不多，也值得先约定一套可读格式，而不是把一整个对象随手拼成字符串。

不要把临时缓存和核心缓存混在同一风格里

像验证码、短期锁、队列状态这种临时用途，和内容详情、配置项缓存并不是同一类东西。它们虽然都放在 Redis，但生命周期和运维方式完全不同。

命名层次清晰，才能避免后面批量扫描或删除时误伤。

小结

Redis key 设计看起来像小事，实际会决定缓存系统后面是不是可维护。只要把业务命名、版本位和查询维度这三层先收清楚，后面的扩展空间会大很多。