红色优雅带你随意聊聊Redis那些命名规范和小技巧

Redis官方文档与社区最佳实践总结）

咱们今天就用拉家常的方式聊聊Redis那点事儿,Redis用起来是挺顺手，但要是命名瞎来，后期维护起来真能让人抓狂，我把自己踩过的坑和总结的小技巧都摊开来聊聊，保准接地气。

键（Key）命名：别把钥匙乱扔

Redis里存数据,键名就是唯一的身份证，最怕的就是想到啥写啥，过几个月自己都看不懂是啥意思。

1. 用冒号当“文件夹”
   这是Redis社区公认的经典做法，比如存用户信息，别直接写user123，改成user:123:profile，冒号就像文件夹分隔符，一看就知道这是用户123的个人资料，再比如订单系统：order:20240520:1001:items表示2024年5月20日1001号订单的商品列表，这样用KEYS user:123:*就能一次性找出这个用户所有数据。

2. 业务名+数据维度
   键名最好能自解释，比如统计网站实时在线人数，键名可以设计成stats:pageview:homepage:20240520，一看就明白是2024年5月20日主页的浏览量统计，要是随便写个pv_home，万一以后要按天统计就得抓瞎。

3. 控制长度找平衡
   键名不是越长越好，比如product:details:inventory:warehouse:beijing实在太啰嗦，简化为pd:inv:bj又太抽象，折中一下：product:inventory:bj既能表达含义又不冗长，记得去年我们有个项目，键名平均长度超过100字节，后来发现光是存键名就浪费了30%内存。

值（Value）设计：好钢用在刀刃上

1. 拒绝JSON一把梭
   很多人图省事直接把对象转成JSON存字符串，比如用户信息{"id":123,"name":"张三","age":30}，如果只需要查年龄也得解析整个JSON，不如拆开用哈希存：HSET user:123 name 张三 age 30，这样可以用HGET user:123 age单独取年龄，省网络传输也省解析时间。

2. 活用数据类型
   比如存储用户标签，用集合（Set）比字符串拼贴更合适。SADD user:123:tags 篮球 编程 摄影能自动去重，还能用SINTER计算共同标签，我们做过测试，存储10万用户的标签，用集合比用字符串节省40%空间。

过期时间策略：给数据定个闹钟

1. 差异化设置TTL
   不同数据过期时间应该不同，验证码短信这种captcha:13800138000设置60秒过期，用户会话session:123可以设置7天，而商品分类列表category:list这种基础数据可以设置1小时过期，千万别偷懒全设置成24小时。

2. 过期时间随机化
   如果大量键同时过期会导致Redis卡顿，比如缓存数据失效时间都设在凌晨2点，瞬间重建缓存可能拖垮数据库，解决办法是给基础过期时间加随机数：EXPIRE key 3600 + rand(600)让1小时过期的数据分散在61-65分钟内失效。

实战小技巧

1. 批量操作省网络
   比如要删10个键，别用10次DEL命令，用DEL key1 key2 ... key10一次搞定，管道（pipeline）更能大幅提升效率，我们有个业务用管道把响应时间从200毫秒压到20毫秒。

2. 敏感数据加锁
   库存扣减这种场景要用SETNX实现分布式锁：SETNX lock:order:1001 1，操作完成后记得DEL lock:order:1001释放锁，最好给锁也设置过期时间，防止死锁：SET lock:order:1001 1 EX 30 NX。

3. 内存优化小心得
   如果存储大量数字，用字符串存"12345"需要5字节，但用Redis的原子操作INCR存储只要4字节，我们有个计数器项目这样优化后，内存占用直接减半。

最后说个真实案例：有次线上故障排查两小时，最后发现是同事写的键名tmp_test_data没清理，积累1000万条数据把内存撑爆了，所以起名时多花30秒，可能省掉后面30小时的麻烦，Redis就像个智能储物柜，用好命名规范就是给每个格子贴好标签，随用随取不闹心。