Redis 使用规范与最佳实践
在企业级项目中,Redis 作为高频使用的缓存中间件,其稳定性直接关系到业务体验。基于实际生产环境中的踩坑经验,我们梳理了一套从键值设计到运维操作的全链路规范。
一、键名与 Value 设计
1. Key 命名规范
禁止包含特殊字符 Key 中严禁出现空格、换行符、单双引号及其他转义字符,这会导致序列化或网络传输时的解析异常。
结构化前缀
建议采用 业务名:表名:id 的格式,既防止不同业务间的 Key 冲突,也便于后续按业务线清理数据。
ugc:video:10086
teach:lesson_id:21
控制长度
过长的 Key 在大量存储时会显著增加内存占用。在保证语义清晰的前提下,尽量精简。
例如将 user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}。
2. Value 设计原则
拒绝大 Key(Big Key) 虽然 Redis 支持 512MB 的 String,但生产环境中应严格限制。
- String 类型:建议控制在 10KB 以内,避免单次写入占用过多网络 IO。
- 集合类型:Hash、List、Set、ZSet 的元素个数建议不超过 5000。
*反例:直接将整个 ORM 模型对象序列化为 Value 存储,极易导致网卡流量打满或慢查询阻塞。
选择合适的数据结构 根据访问模式选择数据结构,平衡资源与性能。
# 反例:分散存储
set user:1:name tom
set user:1:age 19
# 正例:Hash 结构
hmset user:1 name tom age 19 favor football
生命周期管理 Redis 不是垃圾桶,所有 Key 都应设置过期时间(TTL)。对于热点数据,建议打散过期时间,避免同一时刻大量 Key 失效导致数据库雪崩。
按需存储 不需要的数据坚决不存,浪费内存空间的同时增加了维护成本。
二、命令使用安全
1. 禁用高危命令
线上环境严禁执行 KEYS *、FLUSHALL、FLUSHDB 等全量扫描或清空命令。这些命令是 O(N) 复杂度,会阻塞单线程的 Redis 服务。
- 替代方案:遍历 Key 请使用
SCAN家族命令。 - 配置加固:建议在交付实例前通过
rename-command机制禁用危险命令。
2. 慎用批量获取命令
HGETALL、LRANGE、SMEMBERS、ZRANGE 等命令若未限制范围,可能一次性拉取大量数据造成阻塞。
- 建议:明确 N 的数量级,有遍历需求时使用
HSCAN、SSCAN、ZSCAN进行渐进式处理。
3. 连接与事务
- 连接池:务必使用连接池(如 JedisPool),有效控制连接数并复用资源。

