目标：简洁、高效、可维护。
一、Key 命名风格
- 【推荐】key 命名需具有可读性与可管理性，不使用含义不清的 key，也不使用特别长的 key 名；
- 【强制】以英文字母开头，命名中只能出现小写字母、数字、英文点号（
.）和英文半角冒号（:）； - 【强制】不要包含特殊字符：下划线、空格、换行、单双引号及其他转义字符。
二、命名规范：三段式
业务模块名 : 业务逻辑含义 : 其他 : value 类型
- 业务模块名：具体的功能模块；
- 逻辑含义段：
- 【强制】不同业务逻辑含义之间用英文半角冒号
:分割； - 【强制】同一逻辑含义段内的单词之间用英文半角点号
.分割，表示一个完整语义；
- 【强制】不同业务逻辑含义之间用英文半角冒号
- value 类型：【强制】key 以它所代表的 value 类型结尾，提高可读性。
示例：
user:basic.info:{userid}:string三、Value 设计
【强制】拒绝 bigkey（防止网卡流量打满、慢查询）：
String类型控制在 10KB 以内；Hash、List、Set、ZSet元素个数不要超过 5000。
四、业务规范九条
| # | 级别 | 内容 |
|---|---|---|
| 1 | 强制 | 使用 Redis 做缓存必须提出申请，拿出合理方案并评估后再用，避免随意使用 |
| 2 | 强制 | Redis 应是纯缓存服务，缓存数据可丢失；除特殊需求外需提供可行、可实施的方案 |
| 3 | 强制 | key 必须设置过期时间，根据业务场景评估合理有效期 |
| 4 | 推荐 | 冷热数据分离，不常使用且无关紧要的信息放 MySQL 或日志文件，Redis 内存成本高 |
| 5 | 推荐 | 程序要考虑数据丢失后的重新加载过程 |
| 6 | 强制 | 禁止大 key |
| 7 | 强制 | 禁止使用 KEYS 正则匹配操作 |
| 8 | 推荐 | 根据业务场景选择合适的数据类型 |
| 9 | 推荐 | 集合类操作要评估元素规模，避免 O(N) 全量操作 |
过期时间说明
- 不设置过期时间，key 会一直占用内存，直到达到服务器内存上限，可能导致宕机；
- 超时时长应按业务场景评估后设置；
- 确实需要长期有效的 key，可在即将到期时重新设置有效期，避免热点 key 问题。
为什么禁止大 key
- 大 key 除占用大量内存外，高并发时极易占满网卡流量，导致服务器上所有服务不可用。假设 1MB 的 string 大 key 每秒重复写入 10 次，写入网络 IO 就达 10MB；
- 读写大 key 会导致超时严重、网卡打满、阻塞服务，甚至宕机；
- 删除大 key 时
DEL可能阻塞 Redis 进程数十秒； - 每个 key 不要超过 10KB。
数据类型选型
Redis 支持 String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Geospatial 等：
- String：普通 K-V、简单数据；
- Hash：对象（如居民、医生）等属性较多的信息；
- List：队列、关注列表；
- Set：推荐、去重；
- Sorted Set：排行榜。
不能确定复杂结构一定优于 String 时，避免使用复杂数据结构；综合评估性能、存储、网络后再做选择。
集合类操作
集合类 O(N) 操作是超时问题的主要来源：
- 使用
Set、Zset、List、Hash的 O(N) 操作前，要评估当前与将来的元素规模； - 避免全量操作，改用
HSCAN、SSCAN、ZSCAN渐进式遍历； Hash元素个数建议不超过 100，集合类、链表类数据不超过 10k；- 元素过多时考虑拆分成多个 key。