redis key 命名规范的设计

Redis key 命名需具有可读性以及可管理性，不该使用含义不清的 key 以及特别长的 key 名；

一、实现目标

简洁，高效，可维护

二、键值设计规约

1 、 Redis key 命名风格

【推荐】Redis key 命名需具有可读性以及可管理性，不该使用含义不清的 key 以及特别长的 key 名；

【强制】以英文字母开头，命名中只能出现小写字母、数字、英文点号 (.) 和英文半角冒号(:)；

【强制】不要包含特殊字符，如下划线、空格、换行、单双引号以及其他转义字符；

2 、命名规范

【强制】命名规范：业务模块名: 业务逻辑含义: 其他: value 类型

1 ）业务模块名：具体的功能模块

2）逻辑含义段：

【强制】不同业务逻辑含义使用英文半角冒号 (:) 分割，

【强制】同一业务逻辑含义段的单词之间使用英文半角点号 (.) 分割，用来表示一个完整的语义

3）value 类型：

【强制】Redis key 命名以 key 所代表的 value 类型结尾，以提高可读性；

示例：user:basic.info:{userid}:string

3 、 value 设计

【强制】：拒绝 bigkey(防止网卡流量、慢查询)。

String 类型控制在 10KB 以内，Hash、List、Set、ZSet 元素个数不要超过 5000。

三、业务规范

1、【强制】使用 Redis 进行缓存时，必须进行申请。申请之前，需要拿出使用的合理方案，然后进行评估，避免随意使用。

2、【强制】Redis 应用场景应该是纯缓存服务，功能主要是缓存数据，缓存数据可丢失，除特殊需求外，需提供可行性、可实施的方案。

3、【强制】关于过期时间

Redis key 一定要设置过期时间。要跟自己的业务场景，需要对 key 设置合理的过期时间。可以在写入 key 时，就要追加过期时间；也可以在需要写入另一个 key 时，删除上一个 key。

说明：

(1) 若不设置的话，这些 key 会一直占用内存不释放，随着时间的推移会越来越大，直到达到服务器的内存上限，导致服务器宕机等重大事故；

(2) 对于 key 的超时时长设置，可根据业务场景进行评估，设置合理有效期；

(3) 某些业务的确需要长期有效，可以判断即将到期时，重新设置有效期，避免引起热点 key 问题。

4、【推荐】Redis 的使用，应该考虑冷热数据分离，不该将所有数据全部放到 Redis 中，对于使用不频繁，且无关紧要的信息存入 MySQL，或日志文件中，Redis 的数据存储全部都是在内存中的，成本昂贵。

5、【推荐】Redis 有数据丢失风险，程序处理数据时，应该考虑丢失后的重新加载过程。

6、【强制】禁止大 key

大 key 数据存⼊ Redis，除了带来极大的内存占用外，在并发高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用。虽然 Redis 支持 512MB 大小的 string，但是假设 1mb 的 string 大 key，每秒重复写入 10 次，就会导致写入网络 IO 达 10MB;

(1) 读写大 key 会导致超时严重，网卡流量占满, 甚至阻塞服务, 更甚者导致宕机风险。

(2) 如果删除大 key，DEL 命令可能阻塞 Redis 进程数十秒，使得其他请求阻塞，对应用程序和 Redis 集群可用性造成严重的影响。

(3) 每个 key 不要超过 10Kb。

7、【强制】Redis 一定不可使用 Keys 正则匹配操作。

8、【推荐】选择合适的数据类型。

目前 Redis 支持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog 和地理空间索引（geospatial）等, 需要根据业务场景选择合适的类型。

在不能确定其它复杂数据结构⼀定优于 String 类型时，避免使用 Redis 的复杂数据结构。每种数据结构都有相应的使⽤场景，String 类型是 Redis 中最简单的数据类型，建议使用 String 类型。但是考虑到具体的业务场景，综合评估性能、存储网络等方面之后使用适当的数据结构。需要根据业务场景选择合适的类型，常见的如：String 可以用作普通的 K-V、简单数据类类型等；Hash 可以用作对象如居民、医生等，包含较多属性的信息；List 可以用作息队列、医生同行 / 关注列表等；Set 可以用于推荐；Sorted Set 可以用于排行等。

9、【推荐】关于集合类操作

出现问题最多的就是超时问题，因为使用了 O(N) 的操作，导致服务超时，甚至服务不可用。

使用 Set，Zset，List，Hash 等集合类的 O(N) 操作时要评估当前元素个数的规模以及将来的增长规模，对于短期就可能变为大集合的 key，要预估 O(N) 操作的元素数量，避免全量操作，可以使用 HSCAN，SSCAN，ZSCAN 进行渐进操作。集合元素数量过大在使用过程中会影响 Redis 的实际性能，Hash 类元素个数建议尽量不要超过 100，集合类、链表类数据尽量不要超过 10k。元素数量过大可考虑拆分成多个 key 进行处理。

写到最后：

如果您有好的建议和想法，欢迎留言，我会继续完善文档，提高文档输出质量。