Redis缓存键设计那些事儿，聊聊怎么才能不乱又好用

综合自多位资深开发者的实践经验总结与技术社区分享,如阿里云开发者社区、InfoQ等技术网站上的相关讨论文章）

Redis缓存键设计这事儿,说大不大，说小不小，设计好了，系统跑得飞快，维护起来也省心；设计乱了，轻则缓存效果打折，重则引发一堆难以排查的怪问题，今天咱们就抛开那些高大上的理论，聊聊怎么把键设计得既规整又实用。

第一件事：起个好名字，清晰明了是第一位

键名不能瞎起,得像给文件起文件名一样，让人一眼就能看懂它是干嘛的，千万别用那种只有自己才懂的缩写或者拼音缩写，过几天你自己可能都忘了是啥意思。

一个比较通用的好方法是使用“业务名:表名:唯一标识”这样的模式，用冒号分隔，形成一种类似文件夹路径的结构，我们要缓存用户ID为123的信息，键名可以设计成 user:info:123，如果要缓存这个用户下的订单列表，可以叫 user:orders:123，这样一来，即使有成千上万个键，我们也能通过模式匹配（比如用 KEYS user:info:* 命令，生产环境慎用）来快速定位和管理一批相关的键。

第二件事：别忘了设置过期时间，别让缓存“长生不老”

Redis的数据是存在内存里的,内存是宝贵资源，如果缓存一个数据后就不管了，它就会一直占着地方，即使背后的真实数据已经变了，它也不会更新，这就成了“脏数据”，更糟的是，如果这样的无用数据越来越多，会把内存撑爆。

除非是极少数真的几乎不会变的数据,否则一定要给缓存键设置一个合理的过期时间（TTL），这个时间多长合适？这得看业务，比如用户 session，可能设个30分钟；热门文章列表，可能设个5分钟；一些基础配置信息，可能设个1天，设置过期时间，就像给食品贴上个保质期，到期自动清理，既能保证数据相对新鲜，又能避免内存无限增长。

第三件事：键的长度要权衡，别太长也别太短

键名太短了,比如就一个 u123，确实省空间，但可读性太差，容易冲突，但键名也不是越长越好，虽然Redis对键的长度支持很好，但过长的键名会占用更多内存，而且在网络传输和处理时也会消耗更多的带宽和CPU。

所以要在清晰和简洁之间找个平衡,用我们上面提到的命名规范，通常长度就已经比较适中了，关键是保持一致性，整个项目团队最好都用同一套命名规则。

第四件事：小心那些可能“搞乱”键名的数据

我们需要把一些用户输入或者组合信息放到键名里,这时候要特别小心，用户名如果允许包含冒号 ，那你用冒号做分隔符的键名可能就乱套了，再比如，如果用一个对象的多个属性组合成键，要确保这些属性值里没有那些特殊字符。

一个常见的做法是对要放入键名中的动态部分进行编码或哈希处理,如果用户名可能包含特殊字符，可以先对它做个MD5之类的哈希，用哈希值作为键名的一部分，这样就安全了，但也要注意，哈希后虽然安全了，可读性就几乎没有了，所以要根据场景选择。

第五件事：想到批量操作和清理的便利性

设计键名时,要有点“大局观”，想想以后怎么批量处理它们，当你需要批量删除某个用户的所有相关缓存时，如果你的键名都像 user:123:profile, user:123:orders, user:456:profile 这样有规律，你就可以很方便地用 DEL user:123:* 的模式匹配（实际生产中更推荐使用 SCAN 命令迭代删除，避免阻塞）来清理，但如果你的键名设计得五花八门，毫无规律，那批量操作就非常困难了。

总结一下

说白了,Redis缓存键设计的核心就几点：让人能看懂、让系统能管理、让资源能回收，遵循一套简单一致的命名规范，加上合理的过期时间，避开命名陷阱，就能让Redis在你的项目里稳稳当当地发挥作用，而不是变成一个难以收拾的“烂摊子”，这些事儿看起来是细节，但恰恰是这些细节决定了缓存使用的最终效果。