Redis key命名规范

Redis 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 进行处理。